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

From: <[email-masked]>
Date: Tue, 23 Oct 2018 07:37:57 +0000

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

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 23 Oct 2018 09:30:26 -0400

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-masked] 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:
> 
> 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).
> 
> _______________________________________________
> lisp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/lisp
>

---

From: "BRUNGARD, DEBORAH A" <[email-masked]>
Date: Tue, 23 Oct 2018 17:09:53 +0000

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-masked]> On Behalf Of Joel M. Halpern
Sent: Tuesday, October 23, 2018 9:30 AM
To: [email-masked]; [email-masked]
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-masked] wrote:
> discussed whether an "Update RFC6833bis" header is needed to be added 
> to the draft.
> 
> 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).
> 
> 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-masked]
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=