Subject: Updating RFC2119

From: Abdussalam Baryun <[email-masked]>
Date: Sun, 22 Jul 2012 13:17:27 +0200

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,

Regards

Abdussalam Baryun
University of Glamorgan, UK
+++++++++++++++++++++

---

From: Scott Brim <[email-masked]>
Date: Sun, 22 Jul 2012 11:50:26 -0400

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

---

From: Melinda Shore <[email-masked]>
Date: Sun, 22 Jul 2012 08:26:57 -0800

> Please send your comments or advise, thanking you,

Yes: you might try to explain what problem you think you're
solving.

Melinda

---

From: Stewart Bryant <[email-masked]>
Date: Mon, 23 Jul 2012 08:38:54 +0100

> Yes: you might try to explain what problem you think you're
Preferable with a list of RFC text snippets that would have been
more readable if these keywords had been used.

Stewart

---

From: Abdussalam Baryun <[email-masked]>
Date: Mon, 23 Jul 2012 13:08:07 +0200

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

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 23 Jul 2012 12:26:56 +0100

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.

---

From: Abdussalam Baryun <[email-masked]>
Date: Mon, 23 Jul 2012 14:14:13 +0200

comments in line
> I'd encourage you to not try change 2119.

thanks for your comment
> technical, and not process, topic.
I agree that I will need to add to the technical draft for now.

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

---

From: Dave Crocker <[email-masked]>
Date: Mon, 23 Jul 2012 07:15:15 -0700

> included in a 2119bis whenever that's done.

+1

d/
-- 
  Dave Crocker
  Brandenburg InternetWorking
  bbiw.net