Re: Updating RFC2119

[Abdussalam Baryun <[e-mail]>]

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