Re: [Lsr] Benjamin Kaduk's No Objection on draft-ietf-isis-segment-routing-msd-17: (with COMMENT)

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

Benjamin -

Responses inline.

> -----Original Message-----
> From: Benjamin Kaduk <[e-mail]>
> Sent: Wednesday, September 26, 2018 2:46 PM
> To: The IESG <[e-mail]>
> Cc: [e-mail]; Christian Hopps
> <[e-mail]>; [e-mail]; [e-mail];
> [e-mail]; [e-mail]
> Subject: Benjamin Kaduk's No Objection on draft-ietf-isis-segment-routing-
> msd-17: (with COMMENT)
> 
> Benjamin Kaduk has entered the following ballot position for
> draft-ietf-isis-segment-routing-msd-17: 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:
> ----------------------------------------------------------------------
> 
> The shepherd writeup is silent about the WG's discussion of the IPR
> disclosure (but the corresponding ospf draft says this sort of thing is typical
> for LSR drafts).
> 
> Section 3
> 
>    The link MSD sub-TLV is defined for TLVs 22, 23, 25, 141, 222, and
>    223 to carry the MSD of the interface associated with the link.  MSD
> 
> Please add the appropriate qualifier (IS-IS?) before the list of TLV numbers.
> 
[Les:] The document is an IS-IS document. Such a statement is therefore unnecessary.

>    MSD-Value is a number in the range of 0-255.  For all MSD-Types, 0
>    represents lack of the ability to support SID stack of any depth; any
>    other value represents that of the link.
> 
> It's unclear that there's a referent for "that of the link" to attach to.
> That is, is it better to say "represents the maximum SID depth supported by
> the link" (or similar)?
> 
[Les:] Would you be satisfied with the corresponding text in the OSPF document?

" any other value represents that of the particular link when used as an outgoing
   interface."

> Section 6
> 
> As discussed in the secdir review, this section needs to include guidance to
> the Experts to check that the meaning of the absence of an MSD type is
> specified.  Given the text in draft-ietf-ospf-segment-routing-msd that
> attempts to place a similar requirement on future MSD types (but for OSPF
> vs. IS-IS usage thereof), hopefully this guidance can be phrased in an
> appropriately general fashion so as to apply to all places where the registered
> MSD value would be used.
> 
[Les:] I have answered this twice already. :-)

> Section 7
> 
>    Advertisement of the additional information defined in this document
>    that is false, e.g., an MSD that is incorrect, may result in a path
>    computation failing, having a service unavailable, or calculation of
>    a path that cannot be supported by the head-end (the node performing
>    the imposition).
> 
> In the analogous OSPF document we split out the case of a value that is too
> small and a value that is too large, to describe the different consequences.
> 
> I would also suggest rewording to something like "calculation by the head-
> end of a path that cannot be supported" to avoid the mis-parsing
> "(calculation of a path) (that cannot be supported by the head-end)".
> 

[Les:] I will align w the equivalent OSPF text in the next revision.

   Les