Hello, I have been selected as the Routing Directorate reviewer for this draft. The Routing Directorate seeks to review all routing or routing-related drafts as they pass through IETF last call and IESG review, and sometimes on special request. The purpose of the review is to provide assistance to the Routing ADs. For more information about the Routing Directorate, please see ​http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir Although these comments are primarily for the use of the Routing ADs, it would be helpful if you could consider them along with any other IETF Last Call comments that you receive, and strive to resolve them through discussion or by updating the draft. Document: draft-ietf-teas-gmpls-scsi-02 Reviewer: Thomas Clausen Review Date: 17/05/11 IETF LC End Date: Unknown Intended Status: Proposed Standard Summary: I have significant concerns about this document and recommend that the Routing ADs discuss these issues further with the authors. Comments: The document is short, to the point of honestly being entirely unreadable for a non-expert in the very narrow domain of gmpls. This is frankly not helped by the document employing what I can only assume to be a clever pun (SCSI ... ) which initially made me go look at the STORM wg and RFC3720 (iSCSI). Unless there's a really good reason, could the WG not chose a non-intentionally-misleading acronym? Another illustration of this is, that the document uses terminology that I assume has a very specific interpretation (to those, actually experts in the very narrow domain of gmpls) - but which is incomprehensible outside. For example, the document talks (already from the Abstract) about "any specific technology", and in general "technology" - I can think of many things that falls under that term (in general) but which I doubt have anything to do with what this document is about. So I went to read the introduction, hoping to understand what this document was about. As far as I can gather, it has to do with defining a TLV format, for use by GMPLS extensions for OSPF and IS-IS. Reading through the introduction, and (quickly) skimming through RFC4202, 4203 and 5307 didn't help a great deal in my understanding of what the purpose of these TLVs are (nor, for that matter, what "technology" is supposed to mean). It is not clear to me that the document does not violate "rules" in the protocol that it is setting out to extend. See below. I also feel that there are several places where the document is too vague. Major Issues: Fundamentally, the document needs an introduction written for engineers who have not been part in the development of the document: what is this? Why is it needed? How does it fit into the architecture. I must admit that I have never before felt so lost as to what a document was trying to accomplish, after having actually read the document, twice. The document also needs, I suspect, a terminology section that contains more than 2119-language -- for example, what's meant by "Technology" ... I went to read the Shepherd write-up (so, they serve an actual purpose), which indicates that this document was the result of a GEN-ART review of some other document through the WG. I would assume that a synthesis of that review, plus the resulting WG discussion, would make for excellent fodder for an introduction here. Section 3 specifies a Type field, stating "the lower range is used ..." and "...while the higher range is reserved .." -- I see nowhere a definition of "lower range" or "higher range", not in this section, nor in the IANA section. What does "formatted according to the value of the Type field" in the ultimate bullet of section 3 mean? Essentially, that "the interpretation and format of the Type field MUST be specified when making the IANA registration" (or something of the sort), which must to be included as advice to the Designated Expert Section 4 calls out a set of rules for inclusion of the defined TLVs - specifically calling for preservation of ordering both when processing and when re-originating. Is this enabled or prohibited by the protocols into which these TLVs are to be inserted? If explicitly enabled, I would appreciate specific pointers to where this is enabled? -- if this is not explicitly enabled, may there be potential interoperability problems here? For having in a different space written TLV-based protocols, and seen (locally highly optimized) parsers/processors/forwarders implementing different ordering priorities, this merits clarification. The IANA section tells IANA to create "either XXX, or YYY" (2nd paragraph) -- but which is it? I doubt that it is IANA's role to make this arbitration. The WG should make a clear recommendation. Minor Issues: Section 4 calls out "Sub-TLV parsing (format) errors, such as an underrun or overrun, MUST be treated as a malformed ISCD". This seems either overreaching or underachieving: are we strictly talking about "there's not the promised amount of octets in the value field" (overrun/underrun)? In which case, perhaps state just that. However the "Sub-TLV parsing" indicates that also an error in parsing of the Value field should be treated the same way? Could you clarify this. I would be surprised, but leave to the SEC-DIR/SEC-AD, if the security considerations section is strong enough. The first half of the security considerations states "This document does not introduce any security issues beyond those discussed in ...." -- but then goes on, saying "Tampering with .... may have an effect...mechanisms such as ... are suggested". While I am by no means a security expert, it would seem that yes, indeed, this document does introduce new security issues -- for which I would expect a MTI security mechanism (Or, a convincing explanation as to why these already are covered). Nits: The errata to RFC2119 is not reflected in the terminology section (missing "NOT RECOMMENDED") The abstract has an "modify an existing technology specific formats" - which, presumably, should be "modify any existing..." or "...specific format" ? 2nd paragraph of the introduction, any good reason why the HTML version doesn't have a hyperlink to RFC7138 (XML snafu, I gather)? -- Thomas Heide Clausen • @thclausen • thomasclausen.org www.arkko.com/tools/allstats/thomasheideclausen.html