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

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)

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?

  Section 6 needs to be deleted prior to publication as an RFC.