OSPFv2 Extensions for Bit Index Explicit Replication (BIER)
draft-ietf-bier-ospf-bier-extensions-18

I have a few questions and some nits.
1: The shepherd report says that the AD has noted a large number of authors - was there discussion to change this?

2: Related: The shepherd writeup says: "Didn’t see IPR disclosures on the alias archive. Emailed the authors, got responses from 2." -- this means that 5 hadn't responded. Trusting AD to have checked this.

3: Nit: " Neither does BIER require an explicit tree-building protocol for its operation" -- I think that "neither" can be removed.

4: Nit: Section 1:    "BIER architecture requires routers" -> "The BIER architecture requires routers"

5: Section 2.1: "advertised in the BIER sub-TLV by other BFRs is in conflict with the association locally configured on the receiving router, the BIER Sub-TLV MUST be ignored." -- must be ignored and reported, or just ignored?

6: Section 3.  Security Considerations
"Implementations must assure that malformed TLV and Sub-TLV permutations do not result in errors which cause hard OSPF failures."
  -- I am not a security AD, nor do I play one on TV, but I'm predicting a DISCUSS on this -- it seems inadequate...

>      BAR: Single octet BIER Algorithm. 0 is the only supported value
>      defined in this document and represents Shortest Path First (SPF)
>      algorithm based on IGP link metric.  This is the standard shortest
>      path algorithm as computed by the OSPF protocol.  Other values may
>      be defined in the future.

I have the same comment regarding BAR as I made for draft-ietf-bier-isis-extensions: I expected to find a registry for BAR in the IANA section. Does some other document establish this registry? If so, is 0 already registered? If "no" and "no", then this document needs to do both. If "yes" and "no", then this document need to register "0". If "yes" and "yes", then the phrase "in this document" needs to be replaced by "in [RFCxxxx]".

----------

Typically, for reserved fields, specifications ensure the future ability to use the fields in a backwards-compatible way by requiring such fields to be a known value (typically zero) on transmission, and requiring them to be ignored on reception. Please consider doing this.

----------

Please update your example text in section 2.3 to use IPv6 addresses instead of (or in addition to) IPv4 addresses. See https://www.iab.org/2016/11/07/iab-statement-on-ipv6/ for guidance.

----------

Section 4:

>   The document requests three new allocations from the OSPF Extended
>   Prefix sub-TLV registry as defined in [RFC7684].

I see only two requests rather than three.

----------

I also have a small, general cosmetic nit: the bit numbers in the diagrams appear to be shifted to the left by one space; e.g.:

   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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Typically, these types of diagrams number the "-" segments (which represent bits) rather than the "+" segments (which represent the divisions between bits).

4.  IANA Considerations

   The document requests three new allocations from the OSPF Extended

I only see 2 allocations, not 3:

   Prefix sub-TLV registry as defined in [RFC7684].

      BIER Sub-TLV: 9

      BIER MPLS Encapsulation Sub-TLV: 10

Thanks for addressing the Gen-ART reviewer's comments.

I support Ekr's DISCUSS

§1: The document has a few lowercase instances of "must" and "should". Please consider using the boilerplate from RFC 8174.

Thank you for addressing my DISCUSS

Since this adds an extension to OSPF, I think the security considerations may be adequate.  I see why the BIER specific RFC references were not added, but it may be helpful with framing in the security considerations section when this OSPF extension is used.

1) From the shepherd write-up „The main comment I have on the document is that it should be renamed to "OSPFv2 Extensions for BIER”. -> I agree.

2) Also from the shepherd write-up: „Didn’t see IPR disclosures on the alias archive. Emailed the authors, got responses from 2.“ -> Did the others confirm by now?

3) Please use rfc8174 boilerplate.

4) Editorial nit (that will also be cought by the RFC editor): the reference to RFC2328 should be removed from the abstract and added in the Intro.

5) Editorial comment: in section 2.2: Wouldn’t it makes sense to also display the 4 reserved bits at the end of the Label in the diagram? Also wondering why those bits have not been used for the Bit String Length but that’s not important…

6) maybe: s/specified in section 2 of [RFC8296]/specified in section 2.1.2 of [RFC8296]/

7) The document should maybe provide further guidance on how the stated goal in the security considerations section could be achieved.

Thanks for addressing my DISCUSS and COMMENT points.