[pim] [IANA #1446138] Early review: draft-ietf-pim-rfc 8059-9798bis-00 (IETF 125)
"Amanda Baber via RT" <[email protected]> Sat, 14 Mar 2026 15:30:31 +0000
| Newsgroups | gmane.ietf.pim |
|---|---|
| Message-ID | <[email protected]> |
Hi Prasad, Looks good, thanks! Amanda On Sat Mar 14 15:19:55 2026, [email protected] wrote: > Hello Amanda/ IANA, > First my thanks for your detailed note, please see inline responses > with GVP1>. I have attached the diff for your review. Please let me > know if further changes are required > Thanks > Prasad > > > ________________________________ > From: Amanda Baber via RT <[email protected]> > Sent: Thursday, March 12, 2026 6:42 AM > Cc: [email protected] <draft-ietf-pim- > [email protected]>; [email protected] <[email protected]> > Subject: [pim] [IANA #1446138] Early review: draft-ietf-pim-rfc8059- > 9798bis-00 (IETF 125) > > Dear Authors, > > Before the IETF meeting, we check working group agendas for documents > with IANA-related issues. We have notes about this document: > > https://datatracker.ietf.org/doc/html/draft-ietf-pim-rfc8059-9798bis- > 00 > > I see that the IANA Considerations section from RFC 8059 has been > carried over here. I just want to confirm that it’s correct for this > document to serve as the new reference for the RFC 8059 registry and > registrations. From what we’ve seen, this generally happens when a > document is obsoleted, but not necessarily when it’s just being > updated. I have no insight into this case, though. > GVP1> Since the bis document is in Standards track and the two prior > GVP1> documents (RFC8059 & 9798 were experimental) I think the bis > GVP1> should obsolete the old ones. I will change the headers of the > GVP1> bis to reflect this. Thanks for pointing this out. Hence as a > GVP1> corollary, the IANA code points should be now owned by the bis > GVP1> (new RFC). > > What I would say is that it’s confusing to read that “IANA is asked to > assign” values that we’ve already assigned. It would be better to say > that IANA is asked to update the references for the following > registrations and registry created by RFC 8059 to point to this > document, and update the language in the next two paragraphs to > indicate that these actions are complete. > GVP1> I will change the language to note that IANA is requested to > GVP1> update the reference of the code points. > > There's a discussion of "bis" document language in draft-ietf-ianabis- > rfc8126bis-01, Section 8 that might be useful here. > > The reference to “Two new PIM Join/Prune attribute types” (carried > over from RFC 8059) is also a little confusing in that the registry > the assignments come from is called “PIM Join Attribute Types,” not > “PIM Join/Prune Attribute Types.” The fact that the next paragraph > creates a “PIM Join/Prune Transport Types” registry makes it sound > like the “Prune” in “Join/Prune attribute types” could have been a > copy/paste error. This is something we should've caught before 8059 > was published. > GVP1> I will do s/PIM Join/ Prune Attribute types/ PIM Join attribute > GVP1> types. > > If you have any questions, just let us know. If you'd like to talk in > person, you can find us next to the RFC Editor's table from Monday > through Thursday. You can also request another review at any time by > contacting us at [email protected]. > > For more information about IANA Considerations section requirements, > please see > > https://www.iana.org/help/protocol-registration > > Best regards, > > Amanda Baber > IANA > > _______________________________________________ > pim mailing list -- [email protected] > To unsubscribe send an email to [email protected] _______________________________________________ pim mailing list -- [email protected] To unsubscribe send an email to [email protected]