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." > 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 _______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr
