Subject: [Bier] Adam Roach's No Objection on draft-ietf-bier-ospf-bier-extensions-13: (with COMMENT)

From: Adam Roach <[email-masked]>
Date: Wed, 21 Feb 2018 21:18:56 -0800

Adam Roach has entered the following ballot position for
draft-ietf-bier-ospf-bier-extensions-13: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-bier-ospf-bier-extensions/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

>      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).