On Wed, Sep 26, 2018 at 11:09:10PM +0000, Les Ginsberg (ginsberg) wrote: > Benjamin - > > Responses inline. > > > -----Original Message----- > > From: Benjamin Kaduk <[email protected]> > > Sent: Wednesday, September 26, 2018 2:46 PM > > To: The IESG <[email protected]> > > Cc: [email protected]; Christian Hopps > > <[email protected]>; [email protected]; [email protected]; > > [email protected]; [email protected] > > 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."
That's better text (IMHO), but on a different axis. I was thinking more like "represents the MSD of the link". However, my opinion doesn't have to count for much here, so feel free to leave it as-is. > > 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. :-) And I have agreed to leave it to Alvaro :) > > 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. Thanks! -Benjamin _______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr
