Subject: Re: [manet] #35 (aodvv2): A constant is constant

From: "Charles E. Perkins" <[email-masked]>
Date: Wed, 28 May 2014 11:51:10 -0700

Hello folks,

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).

Regards,
Charlie P.

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?
>

-- 
Regards,
Charlie P.

---

From: John Mullen <[email-masked]>
Date: Fri, 30 May 2014 03:06:55 +0000

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.

Back to lurking,
John Mullen
________________________________________
From: manet [[email-masked]] on behalf of Charles E. Perkins [[email-masked]]
Sent: Wednesday, May 28, 2014 12:51 PM
To: [email-masked]; [email-masked]
Subject: Re: [manet] #35 (aodvv2): A constant is constant

Hello folks,

Regards,
Charlie P.

--
Regards,
Charlie P.

_______________________________________________
manet mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/manet

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Fri, 30 May 2014 08:48:27 +0000

The approach we took in NHDP and OLSRv2 is, I think, consistent with how you see it. A constant is the same across the MANET, and (a necessary consequence of that) not dynamically changing. For out of the box compatibility we had a fixed value that we would expect most, maybe even all, MANETs to use, but you could deploy a specialised MANET with a different value.

I haven't checked the AODVv2 language to see if consistent with that. I think more variable than that would be confusing to use the word constant. As a practical matter, a strongly recommended (at least) default value is a good idea. More constant than that (fixed value, never changes, same in all MANETs) is of course a special case.

-- 
Christopher Dearlove
Senior Principal Engineer, Communications Group
Communications, Networks and Image Analysis Capability
BAE Systems Advanced Technology Centre
West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK
Tel: +44 1245 242194 |  Fax: +44 1245 242124
[email-masked] | http://www.baesystems.com

BAE Systems (Operations) Limited
Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, Farnborough, Hants, GU14 6YU, UK
Registered in England & Wales No: 1996687

-----Original Message-----
From: manet [mailto:[email-masked]] On Behalf Of John Mullen
Sent: 30 May 2014 04:07
To: [email-masked]; [email-masked]
Subject: Re: [manet] #35 (aodvv2): A constant is constant

----------------------! WARNING ! ---------------------- This message originates from outside our organisation, either from an external partner or from the internet.
Consider carefully whether you should click on any links, open any attachments or reply.
Follow the 'Report Suspicious Emails' link on IT matters for instructions on reporting suspicious email messages.
--------------------------------------------------------

Hi All,

Back to lurking,
John Mullen

Hello folks,

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).

Regards,
Charlie P.

--
Regards,
Charlie P.

********************************************************************
This email and any attachments are confidential to the intended
recipient and may also be privileged. If you are not the intended
recipient please delete it from your system and notify the sender.
You should not copy it or use it for any purpose nor disclose or
distribute its contents to any other person.
********************************************************************

---

From: Abdussalam Baryun <[email-masked]>
Date: Fri, 30 May 2014 18:43:21 +0200

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,

AB

On 5/30/14, John Mullen <[email-masked]> 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.
>
> Back to lurking,
> John Mullen