Bidirectional Protocol Independent Multicast (BIDIR-PIM)
draft-ietf-pim-bidir-09

[Ballot comment]
I am look at format definitions such as these:

>  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| Rsvd  |          Checksum            |
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> |                  Encoded-Unicast-RP-Address
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...
> |                  Sender Metric Preference                    |
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> |                        Sender Metric                          |
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
> ...
>
>
> RP-Address
>    The bidir RPA for which the election is taking place (note that the
>    length of this field will be different than 32 bits depending on
>    the family and encoding of the address).
>
> Sender Metric Preference
>    Preference value assigned to the unicast routing protocol that the
>    message sender used to obtain the route to the RPA.
>
> Sender Metric
>    The unicast routing table metric used by the message sender to
>    reach the RPA. The metric is in units applicable to the unicast
>    routing protocol used.

I worry that this does not, on its own, define enough to make
sure that people understand what the sizes of the fields are.
For instance, where is the address family carried? What families
and encodings are allowed? Is the Preference field always
of length 32 or not? The graphics do not really tell me that.
Presumably Metric is 32 bits, but it would be good to make that
clear, too.

But perhaps this is defined elsewhere in the document
or in some of the references?

IANA Additional Comments:

Upon approval of this document, the IANA will make
the following changes in "PIM-HELLO-OPTIONS -
Per [RFC4601]" registry located at

http://www.iana.org/assignments/pim-hello-options
[sub-registry "yyy"]

OLD:
Value Length Description Reference
----- ------- ---------
22 0 Bidirectional Capable (renew 8/01) [Kouvelas]

NEW:
Value Length Description Reference
----- ------- ---------
22 0 Bidirectional Capable [RFC-pim-bidir-08]


We understand the above to be the only IANA Action
for this document.

[Ballot discuss]
I am look at format definitions such as these:

>  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| Rsvd  |          Checksum            |
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> |                  Encoded-Unicast-RP-Address
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...
> |                  Sender Metric Preference                    |
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> |                        Sender Metric                          |
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
> ...
>
>
> RP-Address
>    The bidir RPA for which the election is taking place (note that the
>    length of this field will be different than 32 bits depending on
>    the family and encoding of the address).
>
> Sender Metric Preference
>    Preference value assigned to the unicast routing protocol that the
>    message sender used to obtain the route to the RPA.
>
> Sender Metric
>    The unicast routing table metric used by the message sender to
>    reach the RPA. The metric is in units applicable to the unicast
>    routing protocol used.

I worry that this does not, on its own, define enough to make
sure that people understand what the sizes of the fields are.
For instance, where is the address family carried? What families
and encodings are allowed? Is the Preference field always
of length 32 or not? The graphics do not really tell me that.
Presumably Metric is 32 bits, but it would be good to make that
clear, too.

But perhaps this is defined elsewhere in the document
or in some of the references?

[Ballot discuss]
I am look at format definitions such as these:

>  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| Rsvd  |          Checksum            |
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> |                  Encoded-Unicast-RP-Address
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...
> |                  Sender Metric Preference                    |
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> |                        Sender Metric                          |
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
> ...
>
>
> RP-Address
>    The bidir RPA for which the election is taking place (note that the
>    length of this field will be different than 32 bits depending on
>    the family and encoding of the address).
>
> Sender Metric Preference
>    Preference value assigned to the unicast routing protocol that the
>    message sender used to obtain the route to the RPA.
>
> Sender Metric
>    The unicast routing table metric used by the message sender to
>    reach the RPA. The metric is in units applicable to the unicast
>    routing protocol used.

I worry that this does not, on its own, define enough to make
sure that people understand what the sizes of the fields are.
For instance, where is the address family carried? What families
and encodings are allowed? Is the Preference field always
of length 32 or not? The graphics do not really tell me that.
Presumably Metric is 32 bits, but it would be good to make that
clear, too.

[Ballot comment]
1. The document should list 'Intended Status: Proposed Standard' in the header

2. Reference problems (according to the experimental tool):

- Unused Reference: '1' is defined on line 1784, but not referenced
    '[1] S.E. Deering, "Host extensions for IP multicasting", RFC 1112, Aug...'

  - Unused Reference: '6' is defined on line 1803, but not referenced
    '[6] T. Bates , R. Chandra , D. Katz , Y. Rekhter, "Multiprotocol Exten...'

  - Possible downref: Non-RFC Normative Reference: ref. '4'
  * Obsolete Normative Reference: RFC 2401 (ref. '5')
  - Obsolete Informational Reference (is this intentional?): RFC 2283 (ref.
    '6')
  - Obsolete Informational Reference (is this intentional?): RFC 2362 (ref.
    '8')

In general the references sections are in need of a serious update.

3. In general it is good to check idnits with the latest version of the tools. Other complaints from the tool are related to boilerplate format, usage of keywords without an appropriate RFC 2119 section and many instances of too long lines

4. Is Section 6 (change history) supposed to be taken out at publication? If so an appropriate editor note should be included

5. Section 11 - Index seems to be mixed with the Intellectual Property section.

(note that I made all these comments at IETF LC, but they were not addressed)

[Ballot discuss]
The document lacks an IANA consideration section. Moreover the allocation of OptionType 22 in section 3.7.4 contradicts section 4.9.2 in RFC 4601 which states:

'OptionTypes 17 through 65000 are assigned by the IANA.'

[Ballot comment]
1. The document should list 'Intended Status: Proposed Standard' in the header

2. Reference problems (according to the experimental tool):

- Unused Reference: '1' is defined on line 1784, but not referenced
    '[1] S.E. Deering, "Host extensions for IP multicasting", RFC 1112, Aug...'

  - Unused Reference: '6' is defined on line 1803, but not referenced
    '[6] T. Bates , R. Chandra , D. Katz , Y. Rekhter, "Multiprotocol Exten...'

  - Possible downref: Non-RFC Normative Reference: ref. '4'
  * Obsolete Normative Reference: RFC 2401 (ref. '5')
  - Obsolete Informational Reference (is this intentional?): RFC 2283 (ref.
    '6')
  - Obsolete Informational Reference (is this intentional?): RFC 2362 (ref.
    '8')

In general the references sections are in need of a serious update.

3. In general it is good to check idnits with the latest version of the tools. Other complaints from the tool are related to boilerplate format, usage of keywords without an appropriate RFC 2119 section and many instances of too long lines

4. Is Section 6 (change history) supposed to be taken out at publication? If so an appropriate editor note should be included

5. Section 11 - Index seems to be mixed with the Intellectual Property section.

[Ballot comment]
COMMENT:

1. The document should list 'Intended Status: Proposed Standard' in the header

2. Reference problems (according to the experimental tool):

- Unused Reference: '1' is defined on line 1784, but not referenced
    '[1] S.E. Deering, "Host extensions for IP multicasting", RFC 1112, Aug...'

  - Unused Reference: '6' is defined on line 1803, but not referenced
    '[6] T. Bates , R. Chandra , D. Katz , Y. Rekhter, "Multiprotocol Exten...'

  - Possible downref: Non-RFC Normative Reference: ref. '4'
  * Obsolete Normative Reference: RFC 2401 (ref. '5')
  - Obsolete Informational Reference (is this intentional?): RFC 2283 (ref.
    '6')
  - Obsolete Informational Reference (is this intentional?): RFC 2362 (ref.
    '8')

In general the references sections are in need of a serious update.

3. In general it is good to check idnits with the latest version of the tools. Other complaints from the tool are related to boilerplate format, usage of keywords without an appropriate RFC 2119 section and many instances of too long lines

4. Is Section 6 (change history) supposed to be taken out at publication? If so an appropriate editor note should be included

5. Section 11 - Index seems to be mixed with the Intellectual Property section.

[Ballot discuss]
DISCUSS:

The document lacks an IANA consideration section. Moreover the allocation of OptionType 22 in section 3.7.4 contradicts section 4.9.2 in RFC 4601 which states:

'OptionTypes 17 through 65000 are assigned by the IANA.'

[Ballot discuss]
draft-ietf-pim-bidir-08.ps is not available in the I-D repository.
  Therefore, the following is unacceptable:
  >
  >                +-----------------------------------+
  >                | Figures omitted from text version |
  >                +-----------------------------------+
  >
  >                Figure 2: Upstream group state-machine

This work progressed simultaneously with the PIM-SM document that was recently published as RFC 4601.  (In fact, the WG was done with it before it was done with PIM-SM, but given the dependency we wanted to get PIM-SM published first).  Because it was a simultaneous effort, and the protocol has the same kind of exchanges on a LAN, it has the same security considerations.

Sam said in http://www1.ietf.org/mail-archive/web/ietf/current/msg38475.html that just because we allowed PIM-SM to go through with its security considerations that wasn't a precedent for others, so this document may indeed hit security-related roadblocks.  However, it's appropriate for those issues to come up at Last Call so I've issued the Last Call.