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