Re: Updating RFC2119

[Stephen Farrell <[e-mail]>]

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.

S.

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.
> 
> ------------------------------------------------------------------------------------------------------
> RFC4861>page36> 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.
> ------------------------------------------------------------------------------------------------------
> RFC4861>page 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.
> ----------------------------------------------------------------------------------
> RFC5715>page 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
>> <[e-mail]> 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.
>>
> 
>