[lisp] "Update RFC6833bis" header when a meaning is associated with a reserved bit

[m***@orange.com]

Hi all,

In a discussion among the authors of draft-ietf-lisp-pubsub, we discussed whether an "Update RFC6833bis" header is needed to be added to the draft.

The rationale is the -bis document states, for example, the following:

R: This reserved bit MUST be set to 0 on transmit and MUST be ignored
on receipt.

So, obviously this behavior is to be updated each time a meaning is associated with an unassigned/reserved bit, otherwise an extension will be broken if that part of the -bis spec is not touched on.

An update header is therefore more than appropriate....nevertheless, it seems that some old RFCs didn't follow this approach (e.g., RFC8061).

The question we have for the WG is which option do we need to follow: update or no update?

FWIW, a similar action is needed for other documents, e.g., draft-ietf-lisp-mn.

Thank you.

Cheers,
Med

[Joel M. Halpern]

For everyone's context, this is a topic on which the IETF as a whole and
the IESG do not have anything like rough consensus. Some folks think
this sort of change should be an "updates", and other folks argue that
the point of a registry is that we do not need to "update" the base
document.
There are many valid arguments on both sides.

Yours,
Joel

Post by m***@orange.com
Hi all,
In a discussion among the authors of draft-ietf-lisp-pubsub, we
discussed whether an "Update RFC6833bis" header is needed to be added to
the draft.
   R: This reserved bit MUST be set to 0 on transmit and MUST be ignored
      on receipt.
So, obviously this behavior is to be updated each time a meaning is
associated with an unassigned/reserved bit, otherwise an extension will
be broken if that part of the –bis spec is not touched on.
An update header is therefore more than appropriate….nevertheless, it
seems that some old RFCs didn’t follow this approach (e.g., RFC8061).
The question we have for the WG is which option do we need to follow: update or no update?
FWIW, a similar action is needed for other documents, e.g.,
draft-ietf-lisp-mn.
Thank you.
Cheers,
Med
_______________________________________________
lisp mailing list
https://www.ietf.org/mailman/listinfo/lisp

[BRUNGARD, DEBORAH A]

As Joel says, there has been no specific definition as each working group has different views (which is ok, as each technology is different). Important is the working group does consistently. Now as LISP goes PS, it is good to have a common understanding.

My personal interpretation is to be conservative with the label, as it does augment the original document on datatracker, so the reader of the original document will feel they need to read all the associated updates. Whereas for the new document, it will already have the previous document as normative reference, so the "update" label doesn't necessarily add more information. An example which I often use, though it may seem obvious, it did have quite some discussion: a new protection capability is added to MPLS. My preference was to say it was not an update of the base MPLS documents. The advocates of the new capability wanted it to be an update. We decided to say it was not an update. If say, the protection switching capability used a reserved bit (below example), then if one is not implementing protection switching, it would follow the base spec. If one is implementing protection switching, then it would use the reserved bit assigned to it.

And there are many examples not so obvious.

Deborah


-----Original Message-----
From: lisp <lisp-***@ietf.org> On Behalf Of Joel M. Halpern
Sent: Tuesday, October 23, 2018 9:30 AM
To: ***@orange.com; ***@ietf.org
Subject: Re: [lisp] "Update RFC6833bis" header when a meaning is associated with a reserved bit

For everyone's context, this is a topic on which the IETF as a whole and the IESG do not have anything like rough consensus. Some folks think this sort of change should be an "updates", and other folks argue that the point of a registry is that we do not need to "update" the base document.
There are many valid arguments on both sides.

Yours,
Joel

Post by m***@orange.com
Hi all,
In a discussion among the authors of draft-ietf-lisp-pubsub, we
discussed whether an "Update RFC6833bis" header is needed to be added
to the draft.
   R: This reserved bit MUST be set to 0 on transmit and MUST be ignored
      on receipt.
So, obviously this behavior is to be updated each time a meaning is
associated with an unassigned/reserved bit, otherwise an extension
will be broken if that part of the -bis spec is not touched on.
An update header is therefore more than appropriate..nevertheless, it
seems that some old RFCs didn't follow this approach (e.g., RFC8061).
The question we have for the WG is which option do we need to follow: update or no update?
FWIW, a similar action is needed for other documents, e.g.,
draft-ietf-lisp-mn.
Thank you.
Cheers,
Med
_______________________________________________
lisp mailing list
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mail
man_listinfo_lisp&d=DwIF-g&c=LFYZ-o9_HUMeMTSQicvjIg&r=6UhGpW9lwi9dM7jY
lxXD8w&m=6KakRalNM3ilcAkwrGoHtCyhO5cgvdhVTxMRYVsTQCc&s=11EjTtLye81bqqq
zCe9FEoqbYNABObgViOOajHoXdE4&e=