PIM Null-Register Packing
draft-ietf-pim-null-register-packing-16

[Ballot comment]
Updated.  Discuss cleared - thanks for addressing my discuss issue.

Regards,
Rob

----------

Previous comments:

Minor level comments:

(2) p 2, sec 2.  Packed Null-Register Packing Capability

  0                  1                  2                  3
  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |PIM Ver| Type  |P|6 5 4 3 2 1 0|          Checksum            |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |            Group Address (Encoded-Group format)              |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |            Source Address (Encoded-Unicast format)            |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      Figure 1: PIM Register-Stop message with Packing Capability option

I found the description of the flag bits to be unclear:
- Are the "6 5 .. 1 0", the flag bits?
- Is 'P' the "Packed Capability" bit?  If so, this diagram implies that it takes the value 7, but the text indicates that it hasn't been permanently assigned yet.


(3) p 3, sec 3.  PIM Packed Null-Register message format


      0                  1                  2                  3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |PIM Ver| Type  |Subtype|  FB  |          Checksum            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |    Group Address[1]  (Encoded-Group format)                |
      |    Source Address[1]  (Encoded-Unicast format)              |
      .                                                              .
      .                                                              .
      .                                                              .
      .                                                              .
      .    Group Address[N]                                          .
      |    Source Address[N]                                        |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
              Figure 2: PIM Packed Null-Register message format

Unclear what FB means, "Flag Bits"?  Also in section 4.



Nit level comments:

(4) p 4, sec 5.  Protocol operation

                                                            However, it
      is RECOMMENDED to stick to the packed format as long as the RP and
      DR have the feature enabled.

As an editorial nit, I would suggest combining these two sentences together to make it clear what "the decision" is referring to.  The same comment also applies to the pragraph below.

Regards,
Rob

[Ballot comment]
# GEN AD review of draft-ietf-pim-null-register-packing-14

CC @larseggert

Thanks to Behcet Sarikaya for the General Area Review Team (Gen-ART) review
(https://mailarchive.ietf.org/arch/msg/gen-art/EyaOvVl155DHm7IhDZUBHOqRijY).

## Comments

### Section 2, paragraph 5
```
    Packing Capability bit (Flag Bit TBD1): When set, it indicates the
    ability of the RP to receive PIM Packed Null-Register messages, and
    send PIM Packed Register-Stop messages.
```
Is this the "P" bit in Figure 1? If yes, it seems like the position isn't TBD
anymore?

### Section 2, paragraph 4
```
  3.  PIM Packed Null-Register message format
        0                  1                  2                  3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |PIM Ver| Type  |Subtype|  FB  |          Checksum            |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
```
What is "FB"? (Also in Figure 3.)

## Nits

All comments below are about very minor potential issues that you may choose to
address in some way - or ignore - as you see fit. Some were flagged by
automated tools (via https://github.com/larseggert/ietf-reviewtool), so there
will likely be some false positives. There is no need to let me know what you
did with these suggestions.

### Typos

#### "Abstract", paragraph 1
```
-    In PIM-SM networks PIM Null-Register messages are sent by the
+    In PIM-SM networks, PIM Null-Register messages are sent by the
+                      +
```

### Grammar/style

#### Section 4, paragraph 7
```
gister-Stop message sent to the DR. Thus a DR will switch to the new packet f
                                    ^^^^
```
A comma may be missing after the conjunctive/linking adverb "Thus".

## Notes

This review is in the ["IETF Comments" Markdown format][ICMF], You can use the
[`ietf-comments` tool][ICT] to automatically convert this review into
individual GitHub issues. Review generated by the [`ietf-reviewtool`][IRT].

[ICMF]: https://github.com/mnot/ietf-comments/blob/main/format.md
[ICT]: https://github.com/mnot/ietf-comments
[IRT]: https://github.com/larseggert/ietf-reviewtool

[Ballot comment]

# Éric Vyncke, INT AD, comments for draft-ietf-pim-null-register-packing-15
CC @evyncke

Thank you for the work put into this document.

Please find below  some non-blocking COMMENT points (but replies would be appreciated even if only for my own education).

Special thanks to Mike McBride for the shepherd's detailed write-up including the WG consensus **and** the justification of the intended status.

Other thanks to Donald Eastlake, the Internet directorate reviewer (at my request), please consider this int-dir "not ready" review:
https://datatracker.ietf.org/doc/review-ietf-pim-null-register-packing-14-intdir-telechat-eastlake-2023-02-28/ (and I have read Alvaro's and Ananya's replies and the fix in -15)

I hope that this review helps to improve the document,

Regards,

-éric


## COMMENTS

### IP versions

Should there be some text in sections 3 and 4 that the IP layer is not only used to get the amount of addresses but also the IP version of the addresses ?

### Section 7 normative ?

Is there a reason why section 7 does not use normative MAY and SHOULD ?

## Notes

This review is in the ["IETF Comments" Markdown format][ICMF], You can use the
[`ietf-comments` tool][ICT] to automatically convert this review into
individual GitHub issues.

[ICMF]: https://github.com/mnot/ietf-comments/blob/main/format.md
[ICT]: https://github.com/mnot/ietf-comments

[Ballot comment]
## COMMENT

Thanks for taking care of my DISCUSS, and also comments other than the one I've left below (and may amount to nothing, I just don't know).

I support Rob’s DISCUSS, and also his comments.

### General, error conditions

A related question to my DISCUSS is whether there are any error conditions that can apply to the non-packed versions of these messages, that need to be considered here. In a skim of RFC 7761 I didn't see anything problematic, but I didn't review it in detail. Anyway, my concern is *if* there are any error conditions that might apply, presumably they should apply only to the specific (S,G) and not to any other non-erroneous (S,G) encoded in the packed message. Sometimes error handling is written in terms of messages, is what got me thinking about it.

IANA comment: the authors have told us how to fill in the registry's "Flag Bits" field, but they need to add that information to the document's IANA Considerations section.

[Ballot comment]
I support the DISCUSSes raised on the bit naming and confusion within the figures and on the Path MTU discovery.

Additionally, a comment:

    When a Register-Stop message with the P-bit set is received, the DR MAY send PIM Packed Null-Register messages

The following sentences then basically change this MAY to a RECOMMENDED, so a SHOULD would be more appropriate here.

    The RP, after receiving a PIM Packed Null-Register message, MAY start sending PIM Packed Register-Stop messages

Same here.

    In case the network manager disables the Packing Capability at the RP, or in other words, disables the feature from the RP, the router SHOULD NOT advertise the Packing Capability.

Why is this not a MUST NOT ?

[Ballot discuss]
Feel free to set me straight here if I'm wrong, but:

Section 2 says: "This section allocates a bit ..."

Doesn't this mean either (a) there should be a registry for these bits, and if there is, there should be one or more corresponding IANA actions; or (b) this document should update RFC 7761 so that the allocation of a previously reserved bit is discoverable somehow?

[Ballot discuss]
Thanks for working on this document.

I would like to discuss - what is the "P" bit in section 2 and what is "FB" in section 3? without proper description of those fields this specification will be confusing to be implemented. May be I have missed something in the referenced specifications, in that case I would prefer to have the references properly stated here.

I also support Lars's and Rob's discuss.

[Ballot discuss]
# GEN AD review of draft-ietf-pim-null-register-packing-14

CC @larseggert

Thanks to Behcet Sarikaya for the General Area Review Team (Gen-ART) review
(https://mailarchive.ietf.org/arch/msg/gen-art/EyaOvVl155DHm7IhDZUBHOqRijY).

## Discuss

### Section 7, paragraph 2
```
    For IPv6 PIM Packed Null-Register messages or PIM Packed Register-
    Stop messages, the DR MUST perform Path MTU Discovery.  For IPv4, the
    DR SHOULD perform Path MTU Discovery.  This allows the DR to fragment
    packets as needed.  However, in order to avoid fragmentation
    altogether, a DR sending packed registers SHOULD limit the number of
    records such that the message can fit within the Path MTU.  A record
    consists of a Group Address and Source Address pair.
```
*How* is the DR supposed to perform PMTUD? If this is defined in another PIM
doc, please normatively reference that. Otherwise, specify here. Also, isn't the
goal of PMTUD is to avoid fragments, not to allow "the DR to fragment packets as
needed"?

[Ballot comment]
## Comments

### Section 2, paragraph 5
```
    Packing Capability bit (Flag Bit TBD1): When set, it indicates the
    ability of the RP to receive PIM Packed Null-Register messages, and
    send PIM Packed Register-Stop messages.
```
Is this the "P" bit in Figure 1? If yes, it seems like the position isn't TBD
anymore?

### Section 2, paragraph 4
```
  3.  PIM Packed Null-Register message format
        0                  1                  2                  3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |PIM Ver| Type  |Subtype|  FB  |          Checksum            |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
```
What is "FB"? (Also in Figure 3.)

## Nits

All comments below are about very minor potential issues that you may choose to
address in some way - or ignore - as you see fit. Some were flagged by
automated tools (via https://github.com/larseggert/ietf-reviewtool), so there
will likely be some false positives. There is no need to let me know what you
did with these suggestions.

### Typos

#### "Abstract", paragraph 1
```
-    In PIM-SM networks PIM Null-Register messages are sent by the
+    In PIM-SM networks, PIM Null-Register messages are sent by the
+                      +
```

### Grammar/style

#### Section 4, paragraph 7
```
gister-Stop message sent to the DR. Thus a DR will switch to the new packet f
                                    ^^^^
```
A comma may be missing after the conjunctive/linking adverb "Thus".

## Notes

This review is in the ["IETF Comments" Markdown format][ICMF], You can use the
[`ietf-comments` tool][ICT] to automatically convert this review into
individual GitHub issues. Review generated by the [`ietf-reviewtool`][IRT].

[ICMF]: https://github.com/mnot/ietf-comments/blob/main/format.md
[ICT]: https://github.com/mnot/ietf-comments
[IRT]: https://github.com/larseggert/ietf-reviewtool

[Ballot discuss]
# John Scudder, RTG AD, comments for draft-ietf-pim-null-register-packing-14
CC @jgscudder

## DISCUSS

The document is quite terse. In some respects this is admirable and welcome (the low page count is nice). But it seems as though — even if it’s “obvious” — it would be worth  mentioning that the semantics of a packed message with N members are exactly the same as the semantics of the equivalent N non-packed messages. In particular, there seems to be quite a bit of machinery in RFC 7761 that's driven by transmission or receipt of these messages; it would be desirable to have specific, unambiguous language in the spec that makes it crystal clear that the packed equivalents of the messages apply everywhere the non-packed ones do, and everything that applies to the non-packed versions applies equally to the packed versions. For example, a timer for a given (S,G) that would be reset by receipt of a Register-Stop MUST also be reset by that (S,G) occurring within a Packed Register-Stop. (I guess this is true but maybe you should review 7761 to make sure!)

If you think this is already explicit, please help me see where.

One fix could be to add something like this to Sections 3 and 4:

  Sending or receiving a Packed  message is the equivalent, for all purposes, of sending or receiving an individual  message for each (S,G) represented in the packed message.

[Ballot discuss]
# John Scudder, RTG AD, comments for draft-ietf-pim-null-register-packing-14
CC @jgscudder

## DISCUSS

The document is quite terse. In some respects this is admirable and welcome (the low page count is nice). But it seems as though — even if it’s “obvious” — it would be worth  mentioning that the semantics of a packed message with N members are exactly the same as the semantics of the equivalent N non-packed messages. In particular, there seems to be quite a bit of machinery in RFC 7761 that's driven by transmission or receipt of these messages; it would be desirable to have specific, unambiguous language in the spec that makes it crystal clear that the packed equivalents of the messages apply everywhere the non-packed ones do, and everything that applies to the non-packed versions applies equally to the packed versions. For example, a timer for a given (S,G) that would be reset by receipt of a Register-Stop MUST also be reset by that (S,G) occurring within a Packed Register-Stop. (I guess this is true but maybe you should review 7761 to make sure!)

If you think this is already explicit, please help me see where.

One fix could be to add something like this to Sections 3 and 4:

```
Sending or receiving a Packed  message is the equivalent, for all purposes, of sending or receiving an individual  message for each (S,G) represented in the packed message.
```
x

[Ballot discuss]
# John Scudder, RTG AD, comments for draft-ietf-pim-null-register-packing-14
CC @jgscudder

## DISCUSS

The document is quite terse. In some respects this is admirable and welcome (the low page count is nice). But it seems as though — even if it’s “obvious” — it would be worth  mentioning that the semantics of a packed message with N members are exactly the same as the semantics of the equivalent N non-packed messages. In particular, there seems to be quite a bit of machinery in RFC 7761 that's driven by transmission or receipt of these messages; it would be desirable to have specific, unambiguous language in the spec that makes it crystal clear that the packed equivalents of the messages apply everywhere the non-packed ones do, and everything that applies to the non-packed versions applies equally to the packed versions. For example, a timer for a given (S,G) that would be reset by receipt of a Register-Stop MUST also be reset by that (S,G) occurring within a Packed Register-Stop. (I guess this is true but maybe you should review 7761 to make sure!)

If you think this is already explicit, please help me see where.

One fix could be to add something like this to Sections 3 and 4:

```
Sending or receiving a Packed  message is the equivalent, for all purposes, of sending or receiving an individual  message for each (S,G) represented in the packed message.
```

[Ballot discuss]
# John Scudder, RTG AD, comments for draft-ietf-pim-null-register-packing-14
CC @jgscudder

## DISCUSS

The document is quite terse. In some respects this is admirable and welcome (the low page count is nice). But it seems as though — even if it’s “obvious” — it would be worth  mentioning that the semantics of a packed message with N members are exactly the same as the semantics of the equivalent N non-packed messages. In particular, there seems to be quite a bit of machinery in RFC 7761 that's driven by transmission or receipt of these messages; it would be desirable to have specific, unambiguous language in the spec that makes it crystal clear that the packed equivalents of the messages apply everywhere the non-packed ones do, and everything that applies to the non-packed versions applies equally to the packed versions. For example, a timer for a given (S,G) that would be reset by receipt of a Register-Stop MUST also be reset by that (S,G) occurring within a Packed Register-Stop (I guess this is true but maybe you should review 7761 to make sure this is true!)

If you think this is already explicit, please help me see where.

One fix could be to add something like this to Sections 3 and 4:

```
Sending or receiving a Packed  message is the equivalent, for all purposes, of sending or receiving an individual  message for each (S,G) represented in the packed message.
```

[Ballot comment]
## COMMENT

I support Rob’s DISCUSS, and also his comments.

### General, error conditions

A related question to my DISCUSS is whether there are any error conditions that can apply to the non-packed versions of these messages, that need to be considered here. In a skim of RFC 7761 I didn't see anything problematic, but I didn't review it in detail. Anyway, my concern is *if* there are any error conditions that might apply, presumably they should apply only to the specific (S,G) and not to any other non-erroneous (S,G) encoded in the packed message. Sometimes error handling is written in terms of messages, is what got me thinking about it.

### Section 5

Does this really need to be a bulleted list? As far as I can tell, this would work just fine if each bullet point were a normal paragraph instead. I don't need a reply on this point, it's just a suggestion.

### Section 6.3, version downgrade

I think the discussion of software versioning is a little misplaced. ("When this router downgrades to a software version which does not support PIM Packed Null-Registers and PIM Packed Register-Stops...") AFAICT, the procedures discussed apply whenever the router doesn't want to support packed messages for whatever reason, the software downgrade is only an example, and indeed the last paragraph in the section proves this. Possibly retitle the section as "Withdrawing Packed Message Support" (or "Removing" instead of "Withdrawing"), and rewrite the quoted sentence like "If at some point this router no longer supports Packed Null-Registers and PIM Packed Register-Stops, for example because of a software downgrade..."

## Notes

This review is in the ["IETF Comments" Markdown format][ICMF], You can use the
[`ietf-comments` tool][ICT] to automatically convert this review into
individual GitHub issues.

[ICMF]: https://github.com/mnot/ietf-comments/blob/main/format.md
[ICT]: https://github.com/mnot/ietf-comments

[Ballot discuss]
Hi,

Thanks for this document.  I've flagged this as discuss because I found part of the spec to by unclear:

(1) p 3, sec 3.  PIM Packed Null-Register message format


      0                  1                  2                  3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |PIM Ver| Type  |Subtype|  FB  |          Checksum            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |    Group Address[1]  (Encoded-Group format)                |
      |    Source Address[1]  (Encoded-Unicast format)              |
      .                                                              .
      .                                                              .
      .                                                              .
      .                                                              .
      .    Group Address[N]                                          .
      |    Source Address[N]                                        |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
              Figure 2: PIM Packed Null-Register message format

I'm not familiar with PIM, but it wasn't clear to me how the receiver infers how many addresses are in the message.  E.g., I note that the Join/Prune Message Format contains a count "Num Groups", but conversely the "Hello Message Format" does not include a count of options.  Hence, I presume that the N, the address count, is inferred by the packet length?  If so, would that be worth stating here (and in section 4)?

[Ballot comment]
Minor level comments:

(2) p 2, sec 2.  Packed Null-Register Packing Capability

  0                  1                  2                  3
  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |PIM Ver| Type  |P|6 5 4 3 2 1 0|          Checksum            |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |            Group Address (Encoded-Group format)              |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |            Source Address (Encoded-Unicast format)            |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      Figure 1: PIM Register-Stop message with Packing Capability option

I found the description of the flag bits to be unclear:
- Are the "6 5 .. 1 0", the flag bits?
- Is 'P' the "Packed Capability" bit?  If so, this diagram implies that it takes the value 7, but the text indicates that it hasn't been permanently assigned yet.


(3) p 3, sec 3.  PIM Packed Null-Register message format


      0                  1                  2                  3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |PIM Ver| Type  |Subtype|  FB  |          Checksum            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |    Group Address[1]  (Encoded-Group format)                |
      |    Source Address[1]  (Encoded-Unicast format)              |
      .                                                              .
      .                                                              .
      .                                                              .
      .                                                              .
      .    Group Address[N]                                          .
      |    Source Address[N]                                        |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
              Figure 2: PIM Packed Null-Register message format

Unclear what FB means, "Flag Bits"?  Also in section 4.



Nit level comments:

(4) p 4, sec 5.  Protocol operation

                                                            However, it
      is RECOMMENDED to stick to the packed format as long as the RP and
      DR have the feature enabled.

As an editorial nit, I would suggest combining these two sentences together to make it clear what "the decision" is referring to.  The same comment also applies to the pragraph below.

Regards,
Rob

As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up. Changes are expected over time.

This version is dated 1 November 2019.

(1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header?

Proposed Standard, as indicated in the draft, since its specifying a new message format.

(2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections:

Technical Summary:

In PIM-SM networks PIM registers are sent from the first hop router
to the RP (Rendezvous Point) to signal the presence of Multicast
source in the network. There are periodic PIM Null registers sent
from first hop router to the RP to keep the state alive at the RP as
long as the source is active. The PIM Null register packet carries
information about a single Multicast source and group. This document
defines a standard to send multiple Multicast source and group
information in a single pim Null register packet and the
interoperability between the PIM routers which do not understand the
packet format with multiple Multicast source and group details.

Working Group Summary:

There were two wglc's. Comments were incorporated from the first wglc, a few months went by, and then a new wglc was issued with the result of wg consensus. Specific reviews have been performed by Sandy, Stig and Alvaro.

Document Quality:

Are there existing implementations of the protocol?

No.

Have a significant number of vendors indicated their plan to implement the specification?

VMware and Cisco.

Are there any reviewers that merit special mention as having done a thorough review, e.g., one that resulted in important changes or a conclusion that the document had no substantive issues?

Sandy Zheng, Stig Venaas, Alvaro Retana.

If there was a MIB Doctor, YANG Doctor, Media Type or other expert review, what was its course (briefly)? In the case of a Media Type review, on what date was the request posted?

N/A

Personnel:

Who is the Document Shepherd? Mike McBride
Who is the Responsible Area Director? Alvaro Retana

(3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG.

As wg chair, I've followed this draft from the start. It's been fully vetted, has had Gen-ART review and it's ready.

(4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed?

No

(5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place.

No.

(6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here.

No concerns.

(7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why?

Yes.

(8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures.

No IPR.

(9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it?

Strong consensus.

(10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.)

No.

(11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough.

No nits.

(12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

N/A.

(13) Have all references within this document been identified as either normative or informative?

Yes.

(14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion?

No.

(15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure.

No.

(16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary.

No.

(17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 8126).

IANA considerations section is consistent with the rest of the document.

(18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries.

This document requires the assignment of two new PIM message types for the packed pim register and pim register stop.  No new registries.

(19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, YANG modules, etc.

N/A.

(20) If the document contains a YANG module, has the module been checked with any of the recommended validation tools (https://trac.ietf.org/trac/ops/wiki/yang-review-tools) for syntax and formatting validation? If there are any resulting errors or warnings, what is the justification for not fixing them at this time? Does the YANG module comply with the Network Management Datastore Architecture (NMDA) as specified in RFC8342?

N/A.

(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has completed its review of draft-ietf-pim-null-register-packing-13. If any part of this review is inaccurate, please let us know.

The IANA Functions Operator has a question about one of the actions requested in the IANA Considerations section of this document.

The IANA Functions Operator understands that, upon approval of this document, there are two actions which we must complete.

First, in the PIM Message Types registry on the Protocol Independent Multicast (PIM) Parameters registry page located at:

https://www.iana.org/assignments/pim-parameters/

two new message types are to be registered as follows:

Type: [ TBD-at-Registration ]
Name: Packed Null-Register
Flag Bits:
Reference: [ RFC-to-be ]

Type: [ TBD-at-Registration ]
Name: Packed Register-Stop
Flag Bits:
Reference: [ RFC-to-be ]

IANA Question --> Should the Flag Bits for each of these message types be set to: "0-7: Reserved" ?

Second, also in the PIM Message Types registry on the Protocol Independent Multicast (PIM) Parameters registry page located at:

https://www.iana.org/assignments/pim-parameters/

Under Message Type 2: Register Stop, a new bit will be registered as follows:

Bit: [ TBD-at-Registration ] Name: Capability

The IANA Functions Operator understands that this is the only action required to be completed upon approval of this document.

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the list of actions that will be performed.

For definitions of IANA review states, please see:

https://datatracker.ietf.org/help/state/draft/iana-review

Thank you,

David Dong
IANA Services Specialist

The following Last Call announcement was sent out (ends 2023-02-22):

From: The IESG
To: IETF-Announce
CC: Mike McBride , aretana.ietf@gmail.com, draft-ietf-pim-null-register-packing@ietf.org, mmcbride7@gmail.com, pim-chairs@ietf.org, pim@ietf.org
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (PIM Null-Register packing) to Proposed Standard


The IESG has received a request from the Protocols for IP Multicast WG (pim)
to consider the following document: - 'PIM Null-Register packing'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
last-call@ietf.org mailing lists by 2023-02-22. Exceptionally, comments may
be sent to iesg@ietf.org instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

Abstract


  In PIM-SM networks PIM Null-Register messages are sent by the
  Designated Router (DR) to the Rendezvous Point (RP) to signal the
  presence of Multicast sources in the network.  There are periodic PIM
  Null-Registers sent from the DR to the RP to keep the state alive at
  the RP as long as the source is active.  The PIM Null-Register
  message carries information about a single Multicast source and
  group.

  This document defines a standard to send multiple Multicast source
  and group information in a single PIM message.  This document refers
  to the new messages as the PIM Packed Null-Register message and PIM
  Packed Register-Stop message.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-pim-null-register-packing/



No IPR declarations have been submitted directly on this I-D.

As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up. Changes are expected over time.

This version is dated 1 November 2019.

(1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header?

Proposed Standard, as indicated in the draft, since its specifying a new message format.

(2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections:

Technical Summary:

In PIM-SM networks PIM registers are sent from the first hop router
to the RP (Rendezvous Point) to signal the presence of Multicast
source in the network. There are periodic PIM Null registers sent
from first hop router to the RP to keep the state alive at the RP as
long as the source is active. The PIM Null register packet carries
information about a single Multicast source and group. This document
defines a standard to send multiple Multicast source and group
information in a single pim Null register packet and the
interoperability between the PIM routers which do not understand the
packet format with multiple Multicast source and group details.

Working Group Summary:

There were two wglc's. Comments were incorporated from the first wglc, a few months went by, and then a new wglc was issued with the result of wg consensus.

Document Quality:

Are there existing implementations of the protocol?

No.

Have a significant number of vendors indicated their plan to implement the specification?

VMware and Cisco.

Are there any reviewers that merit special mention as having done a thorough review, e.g., one that resulted in important changes or a conclusion that the document had no substantive issues?

No.

If there was a MIB Doctor, YANG Doctor, Media Type or other expert review, what was its course (briefly)? In the case of a Media Type review, on what date was the request posted?

N/A

Personnel:

Who is the Document Shepherd? Mike McBride
Who is the Responsible Area Director? Alvaro Retana

(3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG.

As wg chair, I've followed this draft from the start. It's been fully vetted and it's ready.

(4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed?

No

(5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place.

No.

(6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here.

No concerns.

(7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why?

Yes.

(8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures.

No IPR.

(9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it?

Strong consensus.

(10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.)

No.

(11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough.

No nits.

(12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

N/A.

(13) Have all references within this document been identified as either normative or informative?

Yes.

(14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion?

No.

(15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure.

No.

(16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary.

No.

(17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 8126).

IANA considerations section is consistent with the rest of the document.

(18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries.

This document requires the assignment of two new PIM message types for the packed pim register and pim register stop.  No new registries.

(19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, YANG modules, etc.

N/A.

(20) If the document contains a YANG module, has the module been checked with any of the recommended validation tools (https://trac.ietf.org/trac/ops/wiki/yang-review-tools) for syntax and formatting validation? If there are any resulting errors or warnings, what is the justification for not fixing them at this time? Does the YANG module comply with the Network Management Datastore Architecture (NMDA) as specified in RFC8342?

N/A.

As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up. Changes are expected over time.

This version is dated 1 November 2019.

(1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header?

Proposed Standard, as indicated in the draft, since its specifying a new message format.

(2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections:

Technical Summary:

In PIM-SM networks PIM registers are sent from the first hop router
to the RP (Rendezvous Point) to signal the presence of Multicast
source in the network. There are periodic PIM Null registers sent
from first hop router to the RP to keep the state alive at the RP as
long as the source is active. The PIM Null register packet carries
information about a single Multicast source and group. This document
defines a standard to send multiple Multicast source and group
information in a single pim Null register packet and the
interoperability between the PIM routers which do not understand the
packet format with multiple Multicast source and group details.

Working Group Summary:

There were two wglc's. Comments were incorporated from the first wglc, a few months went by, and then a new wglc was issued with the result of wg consensus.

Document Quality:

Are there existing implementations of the protocol?

No.

Have a significant number of vendors indicated their plan to implement the specification?

VMware and Cisco.

Are there any reviewers that merit special mention as having done a thorough review, e.g., one that resulted in important changes or a conclusion that the document had no substantive issues?

No.

If there was a MIB Doctor, YANG Doctor, Media Type or other expert review, what was its course (briefly)? In the case of a Media Type review, on what date was the request posted?

N/A

Personnel:

Who is the Document Shepherd? Mike McBride
Who is the Responsible Area Director? Alvaro Retana

(3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG.

As wg chair, I've followed this draft from the start. It's been fully vetted and it's ready.

(4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed?

No

(5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place.

No.

(6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here.

No concerns.

(7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why?

Yes.

(8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures.

No IPR.

(9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it?

Strong consensus.

(10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.)

No.

(11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough.

No nits.

(12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

N/A.

(13) Have all references within this document been identified as either normative or informative?

Yes.

(14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion?

No.

(15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure.

No.

(16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary.

No.

(17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 8126).

IANA considerations section is consistent with the rest of the document.

(18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries.

This document requires the assignment of two new PIM message types for the packed pim register and pim register stop.  No new registries.

(19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, YANG modules, etc.

N/A.

(20) If the document contains a YANG module, has the module been checked with any of the recommended validation tools (https://trac.ietf.org/trac/ops/wiki/yang-review-tools) for syntax and formatting validation? If there are any resulting errors or warnings, what is the justification for not fixing them at this time? Does the YANG module comply with the Network Management Datastore Architecture (NMDA) as specified in RFC8342?

N/A.

As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up. Changes are expected over time.

This version is dated 1 November 2019.

(1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header?

Proposed Standard, as indicated in the draft, since its specifying a new message format.

(2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections:

Technical Summary:

In PIM-SM networks PIM registers are sent from the first hop router
to the RP (Rendezvous Point) to signal the presence of Multicast
source in the network. There are periodic PIM Null registers sent
from first hop router to the RP to keep the state alive at the RP as
long as the source is active. The PIM Null register packet carries
information about a single Multicast source and group. This document
defines a standard to send multiple Multicast source and group
information in a single pim Null register packet and the
interoperability between the PIM routers which do not understand the
packet format with multiple Multicast source and group details.

Working Group Summary:

There were two wglc's. Comments were incorporated from the first wglc, a few months went by, and then a new wglc was issued with the result of wg consensus.

Document Quality:

Are there existing implementations of the protocol?

No.

Have a significant number of vendors indicated their plan to implement the specification?

VMware and Cisco.

Are there any reviewers that merit special mention as having done a thorough review, e.g., one that resulted in important changes or a conclusion that the document had no substantive issues?

No.

If there was a MIB Doctor, YANG Doctor, Media Type or other expert review, what was its course (briefly)? In the case of a Media Type review, on what date was the request posted?

N/A

Personnel:

Who is the Document Shepherd? Mike McBride
Who is the Responsible Area Director? Alvaro Retana

(3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG.

As wg chair, I've followed this draft from the start. It's been fully vetted and it's ready.

(4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed?

No

(5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place.

No.

(6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here.

No concerns.

(7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why?

Yes.

(8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures.

No IPR.

(9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it?

Strong consensus.

(10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.)

No.

(11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough.

No nits.

(12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

N/A.

(13) Have all references within this document been identified as either normative or informative?

Yes.

(14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion?

No.

(15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure.

No.

(16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary.

No.

(17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 8126).

IANA considerations section is consistent with the rest of the document.

(18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries.

This document requires the assignment of two new PIM message types for the packed pim register and pim register stop.  No new registries.

(19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, YANG modules, etc.

N/A.

(20) If the document contains a YANG module, has the module been checked with any of the recommended validation tools (https://trac.ietf.org/trac/ops/wiki/yang-review-tools) for syntax and formatting validation? If there are any resulting errors or warnings, what is the justification for not fixing them at this time? Does the YANG module comply with the Network Management Datastore Architecture (NMDA) as specified in RFC8342?

N/A.