[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]