Re: [auth48] AUTH48: RFC-to-be 9436 <draft-ietf-pim-rfc8736bis-04> for your review

["Stig Venaas (svenaas)" <[e-mail]>]

Hi Sarah

The latest version looks good to me.

Thanks,
Stig

> -----Original Message-----
> From: Sarah Tarrant <[e-mail]>
> Sent: Tuesday, August 22, 2023 2:25 PM
> To: Alvaro Retana <[e-mail]>
> Cc: [e-mail]; RFC Editor <[e-mail]>; [e-mail];
> [e-mail]; [e-mail]; [e-mail]; James
> Guichard <[e-mail]>
> Subject: Re: AUTH48: RFC-to-be 9436 <draft-ietf-pim-rfc8736bis-04> for your
> review
> 
> Hello Alvaro,
> 
> Thank you for your reply. We have updated the document accordingly. All of our
> questions have been addressed.
> 
> Please review the document carefully to ensure satisfaction as we do not make
> changes once it has been published as an RFC. Contact us with any further
> updates or with your approval of the document in its current form.  We will await
> approvals from each author prior to moving forward in the publication process.
> 
> Updated XML file:
> http://www.rfc-editor.org/authors/rfc9436.xml
> 
> Updated output files:
> https://www.rfc-editor.org/authors/rfc9436.html
> https://www.rfc-editor.org/authors/rfc9436.txt
> https://www.rfc-editor.org/authors/rfc9436.pdf
> 
> Diff file showing all changes made during AUTH48:
> https://www.rfc-editor.org/authors/rfc9436-auth48diff.html
> 
> Diff files showing all changes:
> https://www.rfc-editor.org/authors/rfc9436-diff.html
> https://www.rfc-editor.org/authors/rfc9436-rfcdiff.html (side-by-side diff)
> 
> Note that it may be necessary for you to refresh your browser to view the most
> recent version.
> 
> For the AUTH48 status of this document, please see:
> https://www.rfc-editor.org/auth48/rfc9436
> 
> Thank you,
> 
> RFC Editor/st
> 
> > On Aug 21, 2023, at 3:29 PM, Alvaro Retana <[e-mail]>
> wrote:
> >
> > On August 18, 2023 at 12:32:15 PM, [e-mail] (rfc-editor@rfc-
> editor.org) wrote:
> >
> > Hi!
> >
> > Thanks for the help in editing this document!
> >
> >> Authors,
> >>
> >> While reviewing this document during AUTH48, please resolve (as necessary)
> the following questions, which are also in the XML file.
> >>
> >> 1) <!-- [rfced] We have some specific questions about the IANA text
> >> in the
> >> document:
> >>
> >> a) IANA noted the following about Table 1:
> >>
> >> Because we typically leave unassigned values unreferenced, we didn't
> >> include Table 1's the reference to this document for values
> >> 13.0-15.14.
> >>
> >> We have thus removed the reference to this document for types
> >> 13.0-15.14
> >> (Unassigned) to match the "PIM Message Types" registry at
> >> https://www.iana.org/assignments/pim-parameters/pim-
> parameters.xhtml#message-types.
> >>
> >>
> >
> > Yes, that’s fine.
> >
> >
> >> b) The "PIM Message Types" registry at
> >> https://www.iana.org/assignments/pim-parameters/pim-parameters.xhtml#
> >> message-types includes assignments for the following types/bits.
> >> Should these be included in Table 1?
> > No, they should not.
> >
> >>
> >>
> >> Note that draft-ietf-pim-null-register-packing-16 and
> >> draft-ietf-pim-assert-packing-12 will move to AUTH48 in the next week
> >> or two.
> >>
> >> type 2 (Register Stop), bit 0 (Packing Capability" -
> >> [RFC-ietf-pim-null-register-packing-16]
> >>
> >> type 5 (Assert), bit 0 (Packed) - [RFC-ietf-pim-assert-packing-12]
> >>
> >> type 5 (Assert), bit 1 (Aggregated) -
> >> [RFC-ietf-pim-assert-packing-12]
> >>
> >> type 13.0 (PIM Packed Null-Register) -
> >> [RFC-ietf-pim-null-register-packing-16]
> >>
> >> type 13.1 (PIM Packed Register-Stop) -
> >> [RFC-ietf-pim-null-register-packing-16]
> >>
> >>
> >> c) Should this text mention the bits that are already assigned (i.e.,
> >> the bits described in Sections 4.1-4.3)?
> >>
> >> Original:
> >> This document updates the "PIM Message Types" registry to indicate
> >> which flag bits are defined for use by each of the PIM message types,
> >> and changes their registration status to Unassigned, as shown in
> >> Table 1.
> >>
> >> Perhaps:
> >> This document updates the "PIM Message Types" registry to indicate
> >> which flag bits are defined for use by each of the PIM message types
> >> and changes their registration status to Unassigned except where the
> >> bits have already been specified, as shown in Table 1.
> >> -->
> > Yes, that looks good.
> >
> >>
> >>
> >>
> >> 2) <!-- [rfced] While we understand the original document (RFC 8736)
> >> was published with some of the text we are questioning below, the
> >> questions are aimed at making the text as correct as possible. Please
> >> let us know if these updates are incorrect or undesirable.
> >>
> >> a) May we update this sentence to either change "currently" to
> >> "current" or to remove "currently" altogether? Note that this
> >> sentence appears in both the abstract and the introduction.
> >>
> >> Original:
> >> This document updates RFC7761 and RFC3973 by defining the use of the
> >> currently Reserved field in the PIM common header.
> >>
> >> Perhaps:
> >> This document updates RFC 7761 and RFC 3973 by defining the use of
> >> the current Reserved field in the PIM common header.
> >>
> >> Or:
> >> This document updates RFC 7761 and RFC 3973 by defining the use of
> >> the Reserved field in the PIM common header.
> > Removing “currently” sounds better to me.
> >>
> >>
> >>
> >>
> >>
> >> b) Please review "currently reserved bits" in this sentence. Is this
> >> correct now as the bits are not reserved but either assigned (per
> >> Sections 4.1-4.4) or unassigned? Note that this sentence appears in
> >> both the abstract and the introduction.
> >>
> >> Original:
> >> This document
> >> further updates RFC7761 and RFC3973, along with RFC5015, RFC5059,
> >> RFC6754, and RFC8364, by specifying the use of the currently reserved
> >> bits for each PIM message.
> >>
> >> Perhaps:
> >> This document
> >> further updates RFCs 7761 and 3973, along with RFCs 5015, 5059, 6754,
> >> and 8364, by specifying the use of the bits for each PIM message.
> > Changing it makes sense to me.
> >
> >>
> >>
> >>
> >> c) May we update this title to use "PIM Flooding Mechanism" rather than
> "PFM"?
> >> PRM is not used elsewhere in the document, and "PIM Flooding
> >> Mechanism" is the name used in the "PIM Message Types" registry for type
> 12.
> >>
> >> Original:
> >> 4.3. Flag Bits for Type 12 (PFM)
> >>
> >> Perhaps:
> >> 4.3. Flag Bits for Type 12 (PIM Flooding Mechanism)
> > Yes, that’s fine.
> >
> >>
> >>
> >>
> >> d) In this document, it seems that the capped "Flag Bits" is used for
> >> the name of the field and the lowercase "flag bits" is used in
> >> general text. Please review "Flag Bits" in this sentence. Should this
> >> read "Flag Bits field" or "flag bits"? Or is the current okay?
> >>
> >> Original:
> >> In Section 5, this document specifies the use of the Flag Bits for
> >> message types 13, 14, and 15 in order to extend the PIM type space.
> >> -->
> > Well….
> > A couple of paragraphs above (second paragraph in the Introduction) we
> > wrote this:  "This document refers to the bits in the Reserved field of the
> common PIM header [RFC7761] as "PIM message type Flag Bits" or, simply, "Flag
> Bits”…”  But we also wrote (in Section 3): "This document updates the definition
> of the Reserved field and refers to that field as "PIM message type Flag Bits" or,
> simply, "Flag Bits”.”  :-( We didn't use "PIM message type Flag Bits” anywhere
> else.
> > The text in Section 3 should be used in the Introduction as “Flag Bits” refers to
> the field (not the bits).
> >
> > To your question.  In the sentence above please use “Flag Bits field”.
> >
> >
> >
> >>
> >>
> >>
> >> 3) <!-- [rfced] Please review the "Inclusive Language" portion of the
> >> online Style Guide
> >> <https://www.rfc-editor.org/styleguide/part2/#inclusive_language>
> >> and let us know if any changes are needed.
> >>
> >> Note that our script did not flag any words in particular, but this
> >> should still be reviewed as a best practice.
> >> -->
> > I didn’t find anything else to be considered.
> >
> > Thanks!!
> >
> > Alvaro.
>