Early Review of draft-ietf-pce-pcep-flowspec-05
review-ietf-pce-pcep-flowspec-05-rtgdir-early-lindem-2019-10-22-00

Hi Adrian,

On 10/22/19, 2:06 PM, "Adrian Farrel" <adrian@olddog.co.uk> wrote:

    Hi Acee,

    Thanks for the review and the kind words.
    I believe this document is in WG last call at the moment, so this is not
    quite so early as an “Early Review” might normally be.

    >  I have a question and a few suggestions:
    >
    >    1. For the multicast flow filter TLVs, is there some reason why
    >       the S-bit and G-bit respectively indicate that the fields are
    >       NOT used? In most protocol encodings, a Set bit indicates that
    >       a field is used and a Clear bit indicates that it is not used.
    >       Also, all zeros has also been used a wildcard specification
    >       but I guess you preferred something explicit.

    No particular reason for the bit settings that I can remember. It makes the
    bits fit nicely with the "Reserved" field, but that is not a very telling
    point. We could change this if there is a good reason to do so.

    IIRC the setting of all zeros has a specific meaning in this case and so a
    different wildcard value was needed.

I'm fine with it - especially if the document is already in Working Group Last
Call (WGLC) and the WG is used to this encoding. I wouldn't have put it in the
Nits if I really thought it were important.

    >    2. For IGPs, we always hyphenate Bit definitions. However, in this
    >       specification, the Bit definitions are not hyphenated other
    >       than in the IANA section. Being the LSR chair, I'd prefer
    >       consistency with the IGP specifications.

    I just checked back with RFC 5440 (the PCEP base specification) and there
    hyphenation is not used.

    I have no strong opinion and will let the PCE chairs tell me what to do.

It is probably more important to be aligned with the base specification. There
was one instance of R-bit in the IANA specifications that could be changed to
be consistent.

    >    3. In most IETF specifications, "headend" is a single compound
    >       word.

    Oooh, I hate that 😊
    Can we leave it to the RPC to fix as a matter of house style?

I don't have that strong an opinion. At least "head end" is used consistently.

    >    4. In section 9, could you indicate that the only change is adding
    >       the <flowspec-list>? This seems to be the case but it would be
    >       good to state it explicitly.

    In my working copy.

    >   5. I have attached an RFCDIFF of suggested editorial changes.

    That was unusually thorough of you. Thanks! All of those nits were spot on
    and are in my working copy (modulo one s/am/an/).

Thanks - this was an unusually easy Routing Directorate review!
Acee

    Best,
    Adrian