Re: [pim] pim Digest, Vol 210, Issue 3- regarding draft-ietf-pim-null-register-packing-10

[saeed sami <[e-mail]>]

Hello.
Isn't the Idea proposed in this draft regarding PIM NULL-Register packing
the same idea proposed in Draft-sami-pim-ng?
https://datatracker.ietf.org/doc/html/draft-sami-pim-ng-14

Sincerely
sami

On Tue, Oct 5, 2021 at 7:08 PM <[e-mail]> wrote:

> Send pim mailing list submissions to
>         [e-mail]
>
> To subscribe or unsubscribe via the World Wide Web, visit
>         https://www.ietf.org/mailman/listinfo/pim
> or, via email, send a message with subject or body 'help' to
>         [e-mail]
>
> You can reach the person managing the list at
>         [e-mail]
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of pim digest..."
>
>
> Today's Topics:
>
>    1. Rtgdir early review of
>       draft-ietf-pim-null-register-packing-10 (Yingzhen Qu via Datatracker)
>    2. Re: Yangdoctors last call review of
>       draft-ietf-pim-igmp-mld-snooping-yang-19 (Hongji Zhao)
>    3. Re: Rtgdir early review of
>       draft-ietf-pim-null-register-packing-10 (Ananya Gopal (ananygop))
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Mon, 04 Oct 2021 19:45:54 -0700
> From: Yingzhen Qu via Datatracker <[e-mail]>
> To: <[e-mail]>
> Cc: [e-mail], [e-mail]
> Subject: [pim] Rtgdir early review of
>         draft-ietf-pim-null-register-packing-10
> Message-ID: <[e-mail]>
> Content-Type: text/plain; charset="utf-8"
>
> 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.
>
>
>
>
> ------------------------------
>
> Message: 2
> Date: Tue, 5 Oct 2021 09:58:16 +0000
> From: Hongji Zhao <[e-mail]>
> To: Reshad Rahman <[e-mail]>, "[e-mail]"
>         <[e-mail]>
> Cc: "[e-mail]"
>         <[e-mail]>,
>         "[e-mail]" <[e-mail]>, "[e-mail]"
>         <[e-mail]>
> Subject: Re: [pim] Yangdoctors last call review of
>         draft-ietf-pim-igmp-mld-snooping-yang-19
> Message-ID:
>         <
> [e-mail]
> >
>
> Content-Type: text/plain; charset="utf-8"
>
> Hi Reshad,
>
> Please check inline. Thanks a lot.
>
> BR/Hongji
>
>
> -----Original Message-----
> From: Reshad Rahman via Datatracker <[e-mail]>
> Sent: 2021?9?30? 11:09
> To: [e-mail]
> Cc: [e-mail]; [e-mail];
> [e-mail]
> Subject: Yangdoctors last call review of
> draft-ietf-pim-igmp-mld-snooping-yang-19
>
> Reviewer: Reshad Rahman
> Review result: Ready with Nits
>
> This is my 3rd review of the document. While I have focused on changes
> done since my last review, some comments apply to parts of the YANG model
> which hasn't changed recently.
>
> Main comments
> =============
>
> - Feature immediate-leave mentions ?fast leave? in the description.
> RFC3376 mentions fast leave but not immediate leave. Should the feature,
> and the leaf node which depends on it, be renamed to fast-leave?
> [Authors] Accepted
>
> - Leaf send-query, description says that it cooperates with parameter
> querier-source. I believe there should be enforcement that send-query can
> only be set if querier-source is also set (must statement)? Also
> querier-source in IGMP mentions VLAN, no such mention in MLD, is that
> correct?
> [Authors] The description of leaf send-query is not clear and easily
> causes confusion. It will be updated.
>                    The description of querier-source in both IGMP and MLD
> part are not proper, and will be updated.
>
> Questions
> ========
>
> - Feature static-l2-multicast-group. The description mentions L2 multicast
> static-group. Is it a static multicast group or a multicast static group? I
> believe it?s the former and the description should be changed?
> [Authors] It is static multicast group, and the description will be
> updated.
>
> - igmp-version and mld-version are both uint8 with a range (1..3 and
> 1..2). If we get a new version someday, the range will have to be changed.
> I don?t recall if this was brought up before. Another option is to use an
> identity. I realize we don?t spin out a new version frequently so this may
> not be an issue. And probably with a new version other changes would be
> needed anyway?
> [Authors] Your last statement is what we considered. When new protocol
> version is introduced, we need a lot of changes.
>
> - Last-reporter is present under the group and also under each source
> entry. Is the one under the group the last host from all sources?
> [Authors] Yes
>
> - Leaf node require-router-alert. What happens if it?s set to true and the
> IP hdr does not contain RA? Consider updating description and/or adding a
> reference.
> [Authors] In that case, the report messages will be ignored. We will
> adding a reference.
>
> Minor
> =====
>
> - Typo in bridge-router-interface: dynamicly.
> [Authors] Accepted
>
> - No need to mention the leaf name in description, e.g. in l2-service-type
> [Authors] Accepted
>
> - Leaf ?host-address?, rename to ?address? since the list is called host
> (no need to duplicate host).
> [Authors] Accepted
>
> Regards,
> Reshad.
>
>
> ------------------------------
>
> Message: 3
> Date: Tue, 5 Oct 2021 15:37:37 +0000
> From: "Ananya Gopal (ananygop)" <[e-mail]>
> To: Yingzhen Qu <[e-mail]>, "[e-mail]"
>         <[e-mail]>
> Cc: "[e-mail]"
>         <[e-mail]>, "[e-mail]
> "
>         <[e-mail]>
> Subject: Re: [pim] Rtgdir early review of
>         draft-ietf-pim-null-register-packing-10
> Message-ID:
>         <
> [e-mail]
> >
>
> Content-Type: text/plain; charset="utf-8"
>
> Hi Yingzhen Qu,
>
> Thanks for the detailed review, I will fix these and update the draft.
>
> 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.
>
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> https://mailarchive.ietf.org/arch/browse/pim/attachments/20211005/8e100af7/attachment.htm
> >
>
> ------------------------------
>
> Subject: Digest Footer
>
> _______________________________________________
> pim mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/pim
>
>
> ------------------------------
>
> End of pim Digest, Vol 210, Issue 3
> ***********************************
>


-- 
sincerely
Saeed Sami