Re: [Lsr] Warren Kumari's No Objection on draft-ietf-isis-segment-routing-msd-15: (with COMMENT)

["Les Ginsberg (ginsberg)" <[e-mail]>]

Warren -

Thanx for the review, your kind words, and your sense of humor. 

I have published V16 of the draft which addresses your comments except as noted below.



> -----Original Message-----
> From: Warren Kumari <[e-mail]>
> Sent: Sunday, September 23, 2018 4:52 PM
> To: The IESG <[e-mail]>
> Cc: [e-mail]; Christian Hopps
> <[e-mail]>; [e-mail]; [e-mail];
> [e-mail]; [e-mail]; [e-mail]
> Subject: Warren Kumari's No Objection on draft-ietf-isis-segment-routing-
> msd-15: (with COMMENT)
> 
> Warren Kumari has entered the following ballot position for
> draft-ietf-isis-segment-routing-msd-15: 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-isis-segment-routing-msd/
> 
> 
> 
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> Thank you for a well written, clear and easy to understand document.
> Also thanks to Zitao Wang for the OpsDir review (
> https://mailarchive.ietf.org/arch/msg/ops-
> dir/GT5r_8_OukxlqMb1NFdsbNysJIw )
> 
> While reviewing it I found some minor nits - these are not blocking
> comments, but please consider addressing them to make the document
> even better:
> 
> 1: Section 1:
> " Path Computation Element Protocol (PCEP) SR extensions"
> I think this would read better as "The Path Computation ..." (Hey! I did say
> they were nits :-))
> 
[Les:] I removed the text and simply let the reference be used as the identifier for the document.

> 2: Section 2.  Node MSD Advertisement
> "Type: 23 (allocated by IANA via the early assignment process)"
> Comment:  Thank you for mentioning here that this is an early allocation - it
> makes it much easier on the reviewer than flipping to the back of the
> document to check, flipping forward, etc.!
> 
> 3: Section 3.  Link MSD Advertisement
> "MSD values may be learned via a hardware API or may be provisioned."
> I don't quite get what a "hardware API" is -- perhaps "an API which talks
> directly to the hardware"? Or just drop API (or hardware)?

[Les:] Some merchant silicon may provide APIs to report the info used to derive link MSD. We wanted to indicate that the value may be derived from such APIs or simply be provisioned.
I modified the text to say " signaled by the forwarding plane".

> 
> 4: Section 6.  IANA Considerations
> "Per TLV information where Link MSD sub-TLV can be part of:
>    TLV  22 23 25 141 222 223
>    ---  --------------------
> yyyyyy
>         Figure 5: TLVs where LINK MSD Sub-TLV can be present"
> 
> I understand what this is trying to say, but I don't think it does a very good
> job of doing so. Perhaps remove the figure and just say "The LINK MSD Sub-
> TLV can be in TLVs 22, 23, 25,141, 222 or 223" or similar....
> 

[Les:] This text mimics the format of the registry which will be updated:  https://www.iana.org/assignments/isis-tlv-codepoints/isis-tlv-codepoints.xhtml#isis-tlv-codepoints-22-23-25-141-222-223 
So it needs to be in this format.

   Les