Re: Updating RFC2119

[Abdussalam Baryun <[e-mail]>]

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