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