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 <[email protected]> On Behalf Of Joel M. Halpern Sent: Tuesday, October 23, 2018 9:30 AM To: [email protected]; [email protected] 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 On 10/23/18 3:37 AM, [email protected] wrote: > 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 > > > > _______________________________________________ > lisp mailing list > [email protected] > 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= > _______________________________________________ lisp mailing list [email protected] https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_lisp&d=DwIF-g&c=LFYZ-o9_HUMeMTSQicvjIg&r=6UhGpW9lwi9dM7jYlxXD8w&m=6KakRalNM3ilcAkwrGoHtCyhO5cgvdhVTxMRYVsTQCc&s=11EjTtLye81bqqqzCe9FEoqbYNABObgViOOajHoXdE4&e= _______________________________________________ lisp mailing list [email protected] https://www.ietf.org/mailman/listinfo/lisp
