Last Call Review of draft-ietf-teas-gmpls-scsi-02
review-ietf-teas-gmpls-scsi-02-rtgdir-lc-clausen-2017-05-11-00

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