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

[Yingzhen Qu via Datatracker <[e-mail]>]

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.