Re: [RTG-DIR] Rtgdir early review of draft-ietf-pim-null-register-packing-10

[Yingzhen Qu <[e-mail]>]

Hi Ananya,

Thank you for addressing my comments. Your reply looks good to me, look
forward to the next version.

Thanks,
Yingzhen

On Fri, Oct 29, 2021 at 2:26 PM Ananya Gopal (ananygop) <[e-mail]>
wrote:

> Hi Yingzhen Qu,
>
>
>
> Thank you for the detailed comments.. I have made the changes, but will
> only be able to submit on 2021-11-06 23:59 UTC (IETF-meeting local time).
>
> Please find my comments inline.
>
>
>
> C1:
>
> The IESG state of this draft is “Dead”. This might be a system error, but
>
> should be fixed.
>
> *[AG]* Stig/Mike, could you help with this?
>
> I see https://datatracker.ietf.org/help/state/draft/iesg. I think the
> committee will have to change this.
>
>
>
> C2:
>
> ** Downref: Normative reference to an Informational RFC: RFC 3446
>
> *[AG]:* I understand that RFC 3446 is not a normative reference, rather
> an informative reference. Changed.
>
> C3:
>
> The line numbers are from idnits output.
>
> Question:
>
> 251        *  When a Register-Stop message with the P-bit set is received,
>
> 252           the DR MAY send PIM Packed Null-Register messages (Section 3)
>
> 253           to the RP instead of multiple Register messages with the
> N-bit
>
> 254           set ([[RFC7761]]).
>
>
>
> 256        *  The RP, after receiving a PIM Packed Null-Register message
> MAY
>
> 257           start sending PIM Packed Register-Stop messages (Section 4)
> to
>
> 258           the corresponding DR instead of individual Register-Stop
>
> 259           messages.
>
> Why is "MAY" used here instead of "SHOULD"?
>
>
>
> *[AG]* I have changed it to SHOULD, It is clearly mentioned that both the
> RP and DR support this capability in this scenario.
>
>
>
> C4:
>
> Section 6
>
> 288    the router should not advertise the capability.  However, an
>
> 289    implementation MAY choose to still parse any packed registers if
> they
>
> 290    are received.
>
> For this case, which format of register-stop message the RP should send?
>
>
>
> *[AG]* Once the network manager disables the capability, the RP should
> only send unpacked Register-Stops.
>
>
>
> C5:
>
> Section 8:
>
> For this case, it is suggested that the DR can send an unpacked PIM
>
> Null-Register. How can the DR know that the packed Null-Register message
>
> is not lost?
>
> *[AG] *
>
> If it is lost then we may send unpacked register, we do not expect this to
> be a common occurrence.
>
> I think when we implement it would be preferred to not revert immediately,
> since as you say there could be a single drop. The period here is until the
> FHR reverts to unpacked registers. But it is left to the implementation how
> quickly to revert.
>
>
>
> C6:
>
> Nits:
>
> * Warning from idnits because reference to RFC 8174 is missing.
>
>   == The document seems to lack the recommended RFC 2119 boilerplate, even
> if
>
>      it appears to use RFC 2119 keywords -- however, there's a paragraph
> with
>
>      a matching beginning. Boilerplate error?
>
>
>
>      RFC 8174, paragraph 11:
>
>         The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
>
>         "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY",
>
>         and "OPTIONAL" in this document are to be interpreted as
>
>         described in BCP 14 [RFC2119] [RFC8174] when, and only when, they
>
>         appear in all capitals, as shown here.
>
>
>
>      ... text found in draft:
>
>         The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
>
>         "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY",
>
>         and "OPTIONAL" in this document are to be interpreted as
>
>         described in BCP 14 [RFC2119] when, and only when, they appear in
>
> ......................................^
>
>         all capitals, as shown here.
>
> *[AG]* Fixed as suggested.
>
>
>
> * There are several places in the draft that an extra "[]" is used. For
> example:
>
> 298      MSDP [[RFC3446]] as well.
>
> s/[[RFC3446]]/[RFC3446]
>
> Please fix them all.
>
> *[AG]* Fixed as suggested.
>
>
>
> 25     This document defines a standard to send multiple multicast source
>
> 26     and group information in a single PIM Null-Register message, in a
>
> 27     packed format.  We will refer to this packed format as the PIM
> Packed
>
> 28     Null-Register format throughout the document.
>
> "in a single PIM Null-Register message, in a packed format." This is a bit
>
> confusing, as it should be a new message called "the PIM Packed
> Null-Register".
>
>
>
> *[AG]* Fixed as suggested.
>
> Changed it to:
>
> This document defines a standard to send multiple multicast source and
> group information in a single PIM Packed Null-Register message.
>
> We will refer to this new packed format as the PIM Packed Null-Register
> format throughout the document.
>
>
>
> 28     Null-Register format throughout the document.  This document also
>
> 29     discusses the interoperability between the PIM routers which do not
>
> 30     understand the packed message format with multiple multicast source
>
> 31     and group details.
>
> It should be interoperability between the PIM routers which do not
> understand
>
> the packet message format and routers which do understand it.
>
> *[AG]* Changed as suggested.
>
>
>
> For section 5, case 2 and 3, it should be added that after receiving
>
> DR's PIM Null-Register message, it sends Register-Stop message.
>
> *[AG]* Changed as suggested.
>
>
>
> Thanks,
>
> Ananya
>
> *From: *Yingzhen Qu via Datatracker <[e-mail]>
> *Date: *Monday, October 4, 2021 at 7:46 PM
> *To: *[e-mail] <[e-mail]>
> *Cc: *[e-mail] <
> [e-mail]>, [e-mail] <
> [e-mail]>
> *Subject: *Rtgdir early review of draft-ietf-pim-null-register-packing-10
>
> Reviewer: Yingzhen Qu
> Review result: Has Nits
>
> Hello
>
> I have been selected to do a routing directorate “early” review of this
> draft.
> https://datatracker.ietf.org/doc/draft-ietf-pim-null-register-packing/
>
> The routing directorate will, on request from the working group chair,
> perform
> an “early” review of a draft before it is submitted for publication to the
> IESG. The early review can be performed at any time during the draft’s
> lifetime
> as a working group document. The purpose of the early review depends on the
> stage that the document has reached.
>
> As this document has gone through two working group last calls, my focus
> for
> the review was to determine whether the document is ready to be published.
> Please consider my comments along with the other working group last call
> comments.
>
> For more information about the Routing Directorate, please see
> ​http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir
>
> Document: draft-ietf-pim-null-register-packing
> Reviewer: Yingzhen Qu
> Review Date: 10/04/2021
> Intended Status: standards track
>
> Summary:
>
> This document is basically ready for publication, but has nits that should
> be
> considered prior to being submitted to the IESG.
>
> Comments:
>
> The IESG state of this draft is “Dead”. This might be a system error, but
> should be fixed.
>
> ** Downref: Normative reference to an Informational RFC: RFC 3446
>
> The line numbers are from idnits output.
> Question:
> 251        *  When a Register-Stop message with the P-bit set is received,
> 252           the DR MAY send PIM Packed Null-Register messages (Section 3)
> 253           to the RP instead of multiple Register messages with the
> N-bit
> 254           set ([[RFC7761]]).
>
> 256        *  The RP, after receiving a PIM Packed Null-Register message
> MAY
> 257           start sending PIM Packed Register-Stop messages (Section 4)
> to
> 258           the corresponding DR instead of individual Register-Stop
> 259           messages.
> Why is "MAY" used here instead of "SHOULD"?
>
> Section 6
> 288    the router should not advertise the capability.  However, an
> 289    implementation MAY choose to still parse any packed registers if
> they
> 290    are received.
> For this case, which format of register-stop message the RP should send?
>
> Section 8:
> For this case, it is suggested that the DR can send an unpacked PIM
> Null-Register. How can the DR know that the packed Null-Register message
> is not lost?
>
> Nits:
>
> * Warning from idnits because reference to RFC 8174 is missing.
>   == The document seems to lack the recommended RFC 2119 boilerplate, even
> if
>      it appears to use RFC 2119 keywords -- however, there's a paragraph
> with
>      a matching beginning. Boilerplate error?
>
>      RFC 8174, paragraph 11:
>         The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
>         "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY",
>         and "OPTIONAL" in this document are to be interpreted as
>         described in BCP 14 [RFC2119] [RFC8174] when, and only when, they
>         appear in all capitals, as shown here.
>
>      ... text found in draft:
>         The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
>         "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY",
>         and "OPTIONAL" in this document are to be interpreted as
>         described in BCP 14 [RFC2119] when, and only when, they appear in
> ......................................^
>         all capitals, as shown here.
>
> * There are several places in the draft that an extra "[]" is used. For
> example:
> 298      MSDP [[RFC3446]] as well.
> s/[[RFC3446]]/[RFC3446]
> Please fix them all.
>
> 25     This document defines a standard to send multiple multicast source
> 26     and group information in a single PIM Null-Register message, in a
> 27     packed format.  We will refer to this packed format as the PIM
> Packed
> 28     Null-Register format throughout the document.
> "in a single PIM Null-Register message, in a packed format." This is a bit
> confusing, as it should be a new message called "the PIM Packed
> Null-Register".
>
> 28     Null-Register format throughout the document.  This document also
> 29     discusses the interoperability between the PIM routers which do not
> 30     understand the packed message format with multiple multicast source
> 31     and group details.
> It should be interoperability between the PIM routers which do not
> understand
> the packet message format and routers which do understand it.
>
> For section 5, case 2 and 3, it should be added that after receiving
> DR's PIM Null-Register message, it sends Register-Stop message.
>
>