Hi John, Thanks for those details. I agree that there shouldn't be an issue with your bare-bones proposal. An update with this text change and [1] has just been posted:
https://datatracker.ietf.org/doc/html/draft-ietf-bess-srv6-services-14 Please let us know if this addresses your concerns. Thanks, Ketan [1] This is the clarification requested by Joel as discussed on the WG mailer : https://mailarchive.ietf.org/arch/msg/bess/smMPKgPXxnOQ1rzWRf0IoKhSTfU/ On Wed, Mar 23, 2022 at 1:47 AM John Scudder <j...@juniper.net> wrote: > 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
