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

From: Warren Kumari <[email-masked]>
Date: Sun, 23 Sep 2018 16:51:37 -0700

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

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

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

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Mon, 24 Sep 2018 06:12:11 +0000

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 <[email-masked]>
> Sent: Sunday, September 23, 2018 4:52 PM
> To: The IESG <[email-masked]>
> Cc: [email-masked]; Christian Hopps
> <[email-masked]>; [email-masked]; [email-masked];
> [email-masked]; [email-masked]; [email-masked]
> Subject: Warren Kumari's No Objection on draft-ietf-isis-segment-routing-
> msd-15: (with COMMENT)
> 
> 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.)
> 
> 
> 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:
[Les:] I removed the text and simply let the reference be used as the identifier for the document.

> makes it much easier on the reviewer than flipping to the back of the
> document to check, flipping forward, etc.!
> 

[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".

> 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

---

From: Warren Kumari <[email-masked]>
Date: Tue, 25 Sep 2018 08:49:19 -0700

On Sun, Sep 23, 2018 at 11:12 PM Les Ginsberg (ginsberg) <[email-masked]>
wrote:

> email
> > Please refer to
> https://www.ietf.org/iesg/statement/discuss-criteria.html

Thanks.

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

Ah, much better! Thanks!

> [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
Ah, I figured it might be something like that, and meant to check, but
wrote this on a plane and then forgot to do so.
(obviously) it's good like that then :-)

Thanks,
W

-- 
I don't think the execution is relevant when it was obviously a bad idea in
the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair of
pants.
   ---maf