Hello Peter,

Thank you for your quick reply and addressing my non-blocking COMMENTs.

You may want to have a look at EV> below (again non blocking)

Regards

-éric


-----Original Message-----
From: Peter Psenak <[email protected]>
Date: Wednesday, 19 May 2021 at 13:39
To: Eric Vyncke <[email protected]>, The IESG <[email protected]>
Cc: "[email protected]" <[email protected]>, "[email protected]" 
<[email protected]>, "[email protected]" <[email protected]>, 
"[email protected]" 
<[email protected]>, "[email protected]" <[email protected]>
Subject: Re: [Lsr] Éric Vyncke's No Objection on 
draft-ietf-lsr-isis-srv6-extensions-14: (with COMMENT)

    Hi Eric,

    thanks for comments, please see inline (##PP):

    On 18/05/2021 18:05, Éric Vyncke via Datatracker wrote:
    > Éric Vyncke has entered the following ballot position for
    > draft-ietf-lsr-isis-srv6-extensions-14: 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 DISCUSS and COMMENT positions.
    > 
    > 
    > The document, along with other ballot positions, can be found here:
    > https://datatracker.ietf.org/doc/draft-ietf-lsr-isis-srv6-extensions/
    > 
    > 
    > 
    > ----------------------------------------------------------------------
    > COMMENT:
    > ----------------------------------------------------------------------
    > 
    > Thank you for the work put into this document.
    > 
    > Please find below some non-blocking COMMENT points (but replies would be
    > appreciated), and some nits.
    > 
    > Thank you to Christian Hopps for his shepherd's write-up (including the WG
    > consensus).
    > 
    > I hope that this helps to improve the document,
    > 
    > Regards,
    > 
    > -éric
    > 
    > == COMMENTS ==
    > 
    > -- Section 2 --
    > Any reason why the bits of the 'Flags' field are not reserved (except for 
the
    > O-bit) ?  

    ##PP
    sure, marked them as Reserved

    > or be in a to-be-created IANA registry? 

    ##PP
    there is a registry defined for these bits in section 11.7

EV> may I suggest to add a reference to the IANA registry already in this 
section ?

    > I would expect the default
    > value for sending them (usually 0) and what to do on the receiving 
side(s) when
    > the value is not 0 (usually ignore them). E.g., see the section 7.1

    ##PP
    yes, this has been commented by others and I have added the statement 
    similar to 7.1 already.


    > 
    > -- Section 3 --
    > Isn't it obvious that the "Segment Routing Algorithm" is also supported 
by SRv6
    > routers ? Consider removing this section ? If you prefer to keep it, then
    > please use the wording "Segment Routing Algorithm" exactly as in the IANA
    > registry.

    ##PP
    I prefer to keep it to make it clear that the SRv6 algo participation is 
    using the same signaling as SR MPLS. That may not be that obvious as it 
    may look like.

EV> you may want to state that SRv6 uses the same signaling as SR MPLS (even by 
one more sentence)

    Corrected the sub-TLV name to match IANA.

    > 
    > -- Section 7.1 (also 7.2 and possibly others) --
    > The header 'Length' should not be defined as 'variable' as it is probably 
a
    > fixed length of 1 octet. Specifying how it is measured and in which units
    > (octets, 32-bit word, ...) is probably welcome.

    ##PP
    with "variable" we refer to the value of the Length's field, not it's 
    length. We use this in many ISIS RFCs (e.g. RFC8667, section 2.2.2.)

EV> Honestly, history mistakes do not need to be repeated ;-)

    > 
    > -- Section 7.2 --
    > What is the default value of the "Flags" field?

    ##PP

    I added:

    "All bits are reserved for future use. They MUST be  set to zero on 
    transmission and MUST be ignored on receipt."

    > 
    > == NITS ==
    > 
    > -- title-
    > Should the plural form be used for 'extension' ?

    ##PP
    sure, changed to plural.


    > 
    > -- Section 1 --
    > s\topology/algorithm specific\topology/algorithm-specific\ ?

    ##PP
    done

    > 
    > -- Section 13 --
    > While there is a rather long contributors list, there is no 
acknowledgement
    > section. The latter is of course optional but usual. Should the doc       
 or
    > last call reviewers be acknowledged ?

    ##PP
    sure, added it.

    thanks,
    Peter


    > 
    > 
    > 
    > _______________________________________________
    > Lsr mailing list
    > [email protected]
    > https://www.ietf.org/mailman/listinfo/lsr
    > 
    > 


_______________________________________________
Lsr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/lsr

Reply via email to