[Bier] Francesca Palombini's Discuss on draft-ietf-bier-bar-ipa-11: (with DISCUSS and COMMENT)

[Francesca Palombini via Datatracker <[e-mail]>]

Francesca Palombini has entered the following ballot position for
draft-ietf-bier-bar-ipa-11: Discuss

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/about/groups/iesg/statements/handling-ballot-positions/ 
for more information about how to handle DISCUSS and COMMENT positions.


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



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

Thanks for the work on this document.

The DISCUSS comment is easy to fix (missing reference), but I also have a
couple of minor comments - for the first one I'd like to see a response but the
others are suggestions, please feel free to implement or disregard as you see
fit.

Francesca

1. -----

Missing Reference: 'RFC8665' is mentioned on line 123, but not defined


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

2. -----

   When a BAR value is defined, the corresponding BA and BC semantics
   SHOULD be specified.  For an IGP Algorithm to be used as a BIER IPA,
   its RA and RC semantics SHOULD be specified.

FP: While I think BA and RA are self-explanatory, I looked (and couldn't find
quickly) pointers to BC and RC semantics. Could you please add a pointer to the
RFCs and sections defining what qualifies as BCs and RCs? I also believe more
context around the use of SHOULD is warranted - in what cases are exceptions to
the SHOULD likely to arise and why is that ok? It seems to me that the "catch
all" following paragraph (see below) should not leave authors of new
registrations thinking "it's ok if I don't mention constraints" because they
don't understand what they are supposed to be.

   None of the components of the BAR or IPA can be unknown.  If any of
   the components is not specified, it is interpreted as "NULL"
   algorithm or constraint.

3. -----

Section 2

FP: I note that the "1 octet" or "single-octet" definition for both BAR and IPA
has disappeared. I think this is OK, given that the registry covers only values
in the 1 byte registry, but I want to make sure that is not an oversight.

4. -----

Section 2

FP: (weak) suggestion to add references to the IANA registries directly, rather
than to the RFCs defining them.