Yes, you’re right that 9012 is another possible ref. Regarding the option of doing it in the current spec —
- I hear you that you’re not certain you’d be capturing every relevant reference, however I think this is a case of “best is the enemy of good”. Listing the known references would be an improvement over the current state of affairs, likewise updating the description. - There is nothing preventing a later doc from updating the registry again, if that’s deemed necessary. Registries are updated all the time. So, we wouldn’t be foreclosing any options or doing anything irreversible. - Getting WG input (such as would come from a full last call) is certainly important for many things, but you’ve just pointed out yourself that this isn’t a functional change, so I think it’s unlikely that any harm would ensue from not invoking maximum process. I had a look at BCP 26/RFC 8216 and this approach seems consistent with the guidance there. Indeed, strictly speaking it would be inappropriate NOT to add [this document] as a reference in the registry, at minimum — so the only question then becomes, whether to update the description and add the other references at the same time. Bottom line, I continue to think it’s appropriate to do it in the current spec, and more expedient. Seems like all upside, no downside, very good bang-for-the-buck. Here’s what (per my reading of BCP 26 §7) the bare-bones update would look like: 9.X Subsequent Address Family Identifiers (SAFI) Parameters Registry IANA is requested to add this document as a reference for value 128 in the Subsequent Address Family Identifiers (SAFI) Parameters registry. That would then leave the other work for a later draft, as you suggest. I’m only providing the above for clarity, it’s not my recommendation, the earlier version is. —John > On Mar 22, 2022, at 3:27 PM, Ketan Talaulikar <ketant.i...@gmail.com> wrote: > > > Hi John, > > This point was discussed amongst some of the authors. We were not sure if we > had got all the references to the specs that do this kind of handling for > "embedded label". RFC9012 came up as another possible reference. > > I was wondering if we could go about this change in a separate (AD > sponsored?) draft so we don't miss anything and also get more inputs from the > WGs involved? It is not a functional but an IANA update. > > I can volunteer to put together a short draft for this with your guidance. > > Please let me know your thoughts. > > Thanks, > Ketan > > > On Wed, 23 Mar, 2022, 12:33 am John Scudder, <j...@juniper.net> wrote: >> Hi Authors, >> >> I’m not sure if this point was considered and rejected (in which case let’s >> close it out in email please), or (more likely) just dropped? >> >> > On Feb 18, 2022, at 4:48 PM, Robert Raszuk <rob...@raszuk.net> wrote: >> > >> > >> > Hi John, >> > >> >> Question: SAFI 128 is called “MPLS-labeled VPN address” in the IANA SAFI >> >> registry. Shouldn’t this be renamed? I mean, I guess it should have been >> >> renamed as of RFC 8365, but better late than never. I’m not sure quite >> >> what the name should become, but “MPLS-labeled” is manifestly wrong. Even >> >> “labeled” is wrong since the thing you’re stuffing in there isn’t a >> >> label. Since you’re the last one to touch it :-) if we can agree a better >> >> name for the SAFI I think it would be appropriate to add that to your >> >> IANA Considerations. >> >> >> > My suggestion would be: "VPN address & context" or "Context & VPN address" >> > >> > Thx, >> > R. >> >> I like either of Robert’s suggestions. This would go some small way towards >> addressing my concern #2. >> >> Suggested text for the IANA Considerations section: >> >> 9.X Subsequent Address Family Identifiers (SAFI) Parameters Registry >> >> IANA maintains a registry called Subsequent Address Family Identifiers >> (SAFI) Parameters. In that registry, value 128 has the description >> "MPLS-labeled VPN address”, references [RFC4364][RFC8277]. This >> specification, as well as [RFC 8365] before it, changes the semantics of >> SAFI 128 such that it can carry values other than an MPLS label. Therefore, >> IANA is requested to update the description of value 128 to be "VPN address >> & context” and to add [RFC 8365] and [this document] as references. >> >> Regards, >> >> —John > _______________________________________________ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
