Opened 5 years ago

Last modified 5 years ago

#35 new defect

A constant is constant

Reported by: charliep@… Owned by: charliep@…
Priority: minor Milestone:
Component: aodvv2 Version:
Severity: Active WG Document Keywords:
Cc:

Description

(Thomas Clausen) Section 14.2 "Protocol Constants" contains a semantically null sentence AODVv2 protocol constants typically do not require changes

A constant is constant, therefore it doesn't change. Even for very loose definitions of constant. With that being said, the interesting part here is actually not that bit...but rather, what happens *if* these are not set to the values that are indicated? Or, if different implementations use different values for these? The same holds for 14.2, btw: is a network able to operate with different routers setting different values? Will it break? Degrade gracefully? Just work?

Change History (3)

comment:1 Changed 5 years ago by charliep@…

  • Owner changed from draft-ietf-manet-aodvv2@… to charliep@…

comment:2 Changed 5 years ago by charliep@…

On 5/29/2014 8:06 PM, John Mullen wrote:

Hi All, I've been a lurker for some time, but as a mathematician and engineer, I've always interpreted "constant" as a value that is unchanging in the current analysis, not necessarily a constant in the sense of Euler's constant. So my interpretation is that these are values that are not to be modified dynamically, but may be modified in certain situations and possibly due to some yet-unknown technology by the people setting up the network. It is also my experience that people who do this use the default values unless something comes up that warrants adjustment. So, I think the language is clear enough.


From: ... Charles E. Perkins [charliep@…] Sent: Wednesday, May 28, 2014 12:51 PM

I'm not quite sure what to do about this. Contrary to the assertion, the term "Protocol Constant" is pretty well understood and has been used with the same meaning in numerous existing RFCs. I think that it would be interesting to explore the results of using different constants, but the intention is clearly that implementations should use the numbers as provided.

If desired, I can try to fashion some text to suggest the results of using different numbers (e.g., for use in atypical situations).

On 4/3/2014 2:34 PM, manet issue tracker wrote:

#35: A constant is constant

(Thomas Clausen) Section 14.2 "Protocol Constants" contains a semantically null sentence AODVv2 protocol constants typically do not require changes

A constant is constant, therefore it doesn't change. Even for very loose definitions of constant. With that being said, the interesting part here is actually not that bit...but rather, what happens *if* these are not set to the values that are indicated? Or, if different implementations use different values for these? The same holds for 14.2, btw: is a network able to operate with different routers setting different values? Will it break? Degrade gracefully? Just work?

comment:3 Changed 5 years ago by charliep@…

On 5/30/2014 9:43 AM, Abdussalam Baryun wrote:

This draft purpose is implementation, so the understandning target should be targeting implementers (which they not needed to be engineers or mathematics). IMHO, within any protocol specification/program-language, its constants are not variable and its variables are not constant.

IMHO, this ticket #35 mostly points to a sentence, therefore it

means: Remove the sentence "AODVv2 protocol constants typically do not require changes". or Replace to: " AODVv2 protocol constants' values are typically default values".

I do not disagree with the ticket (i.e. it maybe did not recommend edit sentence), because that sentence may cause confusion to the implementers that know that constants cannot change. If editors don't want to remove/replace then we may add more words to clarify in a better way for all understandings. Please advise,

Note: See TracTickets for help on using tickets.