Re: Updating RFC2119
On 22/07/2012 17:26, Melinda Shore wrote: On 7/22/12 3:17 AM, Abdussalam Baryun wrote: IF x, THEN y: ELSE: ELSE IF: Please send your comments or advise, thanking you, Yes: you might try to explain what problem you think you're solving. Melinda Preferable with a list of RFC text snippets that would have been more readable if these keywords had been used. Stewart
Re: Updating RFC2119
Hi Stewart, Usually the (IF x, THEN y) means if x happens then y is a MUST, so I don't see the important reflection of a MUST in many documentation when using *if*. That is why I prefer to find requirements more easily while skimming any IETF document, the MUST, SHOULD, and IF, these are important requirement words in specifications. Please see below as examples per your requested. -- RFC4861page36 IMO suggest to use IF, THEN If no entry exists, the sender creates one, sets its state to INCOMPLETE, initiates Address Resolution, and then queues the data packet pending completion of address resolution. -- RFC4861page 49 IMO suggest to use IF and ELSE IF If the router already has a Neighbor Cache entry for the solicitation’s sender, the solicitation contains a Source Link-Layer Address option, and the received link-layer address differs from that already in the cache, then the link-layer address SHOULD be updated in the appropriate Neighbor Cache entry, and its reachability state MUST also be set to STALE. If there is no existing Neighbor Cache entry for the solicitation’s sender, the router creates one, installs the link- layer address and sets its reachability state to STALE as specified in Section 7.3.3. If there is no existing Neighbor Cache entry and no Source Link-Layer Address option was present in the solicitation, the router may respond with either a multicast or a unicast router advertisement. Whether or not a Source Link-Layer Address option is provided, if a Neighbor Cache entry for the solicitation’s sender exists (or is created) the entry’s IsRouter flag MUST be set to FALSE. -- RFC5715page 19 If R changes before T, then a loop will form around R, T, and S. --- RFC6052 page 10 suggest delete *will* and to add as IF, THEN If a packet bound to 192.0.2.33 reaches the translator, the destination address will be translated to 2001:db8:122:344:c0:2:2100::, and the packet will be routed towards R and then to A. --- There are many examples that ignore the use of IF , THEN requirements, which I suggest to be in the I-D update of RFC2119 that I working on and will submit in 30 July, Regards Abdussalam Baryun University of Glamorgan, UK == Preferable with a list of RFC text snippets that would have been more readable if these keywords had been used. Stewart On Sun, Jul 22, 2012 at 7:17 AM, Abdussalam Baryun abdussalambar...@gmail.com wrote: Hi All, I am working on an I-D which is intended as proposed standard but need some addition requirement language. Therefore, I want to propose to write a draft to update RFC2119 to add some other language requirement as below: IF x, THEN y: ELSE: ELSE IF: Please send your comments or advise, thanking you, That doesn't have to be in 2119. Lots of RFCs have pseudocode at various levels of rigor. Just look around at some protocol specs for examples.
Re: Updating RFC2119
comments in line I'd encourage you to not try change 2119. thanks for your comment Instead, add whatever new definitions you feel you need to your own draft that addresses some technical, and not process, topic. I agree that I will need to add to the technical draft for now. If people find your new definitions useful they'll say and if enough of that happens they'll be included in a 2119bis whenever that's done. this is the reason for this thread to see the feedback of the community including me (at this time and the comings) and IMO the submission of the I-D to update RFC2119 that includes new definition may help the discussion, in the end the community will decide AB === On 07/23/2012 12:08 PM, Abdussalam Baryun wrote: Hi Stewart, Usually the (IF x, THEN y) means if x happens then y is a MUST, so I don't see the important reflection of a MUST in many documentation when using *if*. That is why I prefer to find requirements more easily while skimming any IETF document, the MUST, SHOULD, and IF, these are important requirement words in specifications. Please see below as examples per your requested. -- RFC4861page36 IMO suggest to use IF, THEN If no entry exists, the sender creates one, sets its state to INCOMPLETE, initiates Address Resolution, and then queues the data packet pending completion of address resolution. -- RFC4861page 49 IMO suggest to use IF and ELSE IF If the router already has a Neighbor Cache entry for the solicitation’s sender, the solicitation contains a Source Link-Layer Address option, and the received link-layer address differs from that already in the cache, then the link-layer address SHOULD be updated in the appropriate Neighbor Cache entry, and its reachability state MUST also be set to STALE. If there is no existing Neighbor Cache entry for the solicitation’s sender, the router creates one, installs the link- layer address and sets its reachability state to STALE as specified in Section 7.3.3. If there is no existing Neighbor Cache entry and no Source Link-Layer Address option was present in the solicitation, the router may respond with either a multicast or a unicast router advertisement. Whether or not a Source Link-Layer Address option is provided, if a Neighbor Cache entry for the solicitation’s sender exists (or is created) the entry’s IsRouter flag MUST be set to FALSE. -- RFC5715page 19 If R changes before T, then a loop will form around R, T, and S. --- RFC6052 page 10 suggest delete *will* and to add as IF, THEN If a packet bound to 192.0.2.33 reaches the translator, the destination address will be translated to 2001:db8:122:344:c0:2:2100::, and the packet will be routed towards R and then to A. --- There are many examples that ignore the use of IF , THEN requirements, which I suggest to be in the I-D update of RFC2119 that I working on and will submit in 30 July, Regards Abdussalam Baryun University of Glamorgan, UK == Preferable with a list of RFC text snippets that would have been more readable if these keywords had been used. Stewart On Sun, Jul 22, 2012 at 7:17 AM, Abdussalam Baryun abdussalambar...@gmail.com wrote: Hi All, I am working on an I-D which is intended as proposed standard but need some addition requirement language. Therefore, I want to propose to write a draft to update RFC2119 to add some other language requirement as below: IF x, THEN y: ELSE: ELSE IF: Please send your comments or advise, thanking you, That doesn't have to be in 2119. Lots of RFCs have pseudocode at various levels of rigor. Just look around at some protocol specs for examples.
Re: Updating RFC2119
On 7/23/2012 4:26 AM, Stephen Farrell wrote: I'd encourage you to not try change 2119. Instead, add whatever new definitions you feel you need to your own draft that addresses some technical, and not process, topic. If people find your new definitions useful they'll say and if enough of that happens they'll be included in a 2119bis whenever that's done. +1 d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net
Re: Updating RFC2119
On Sun, Jul 22, 2012 at 7:17 AM, Abdussalam Baryun abdussalambar...@gmail.com wrote: Hi All, I am working on an I-D which is intended as proposed standard but need some addition requirement language. Therefore, I want to propose to write a draft to update RFC2119 to add some other language requirement as below: IF x, THEN y: ELSE: ELSE IF: Please send your comments or advise, thanking you, That doesn't have to be in 2119. Lots of RFCs have pseudocode at various levels of rigor. Just look around at some protocol specs for examples.
Re: Updating RFC2119
On 7/22/12 3:17 AM, Abdussalam Baryun wrote: IF x, THEN y: ELSE: ELSE IF: Please send your comments or advise, thanking you, Yes: you might try to explain what problem you think you're solving. Melinda
