AD comments on draft-ietf-nsis-ext-05

1. Section 2, second paragraph: "Two NSLP protocols are currently
   standardized:"

As they are going to experimental specifications, maybe better to say
specified, rather than standardized.

2. Section 2, second paragraph: "one concerning Quality of Service
signaling and one to enable NAT/Firewall traversal."
Please add references.

3. Section 3, Figure 1,
TLS over UDP or DCCP is not really workable. DTLS would be the suitable
choice here. The question here is if the figure should show what can be
or what is specified? I think it needs to make this clear.

4. Section 8.2, first paragraph: "The bullet points at
   the end of each subsection specify the formal administrative actions
   that would need to carried out when a new extension was standardised."

Isn't "was" the wrong tempus here. And secondly, isn't better to replace
standardised with specified?


5. Section 8.2.2: "Sream Control Transport Protocol
   (SCTP) [I-D.ietf-nsis-ntlp-sctp]"
s/Sream/Stream

6. Section 8.2: There is a generic issue here from the reclassification
of NTLP spec. The NTLP spec says Standards action on a number of places.
Wouldn't it be better in general to change that to "IETF Review" and
also fix that in this document? Because currently there are a number of
code-points that are completely impossible to assign as there will be
impossible until you have managed to publish NSIS on the standards track
to publish extensions.

7. Section 8.2.7: "
 o  New objects require allocation of a new Object Type ID either by
      standards action or provision of another type of specification
      [I-D.ietf-nsis-ntlp]."

What does "provision of another type of specification" mean?

8. Section 8.4:
"Introduction of
   new QoS models requires IETF action, with the published document
   defining the specific elements within the QSpec used in the new
   model.  See [I-D.ietf-nsis-qspec] for details."

What is meant with IETF action here?

9. Section 8.4:
"If changes are made to the QSPEC that are not
   backwards compatible, a new QSPEC version number has to be assigned.
   Note that a new QSPEC version number is not needed just because new
   additional QSPEC parameters are specified; new versions will be
   needed only if the existing functionality is modified.  It is
   required that later QSPEC versions be backward compatible with
   earlier QSPEC versions. "

Once more this confusion around backwards compatibility is presented.
Can you please clarify this so it doesn't read like contradicting
statements.

10. Section 8.4:

   o  Additional QSPEC procedures can be defined requiring allocation of
      a new QSPEC procedure number by standards action or through a
      another specification document.  Values are also available for
      local or experimental use during development.  See
      [I-D.ietf-nsis-qspec].

"by standards action or through a another specification document" seem
to be a fuzzy way to say that the policy is Specification Required.

11. Section 8.6

Why no discussion of security related issues?

12. Section 9.

I think the section needs to state something in this document. Both
utilization and the availability of security functions are important for
extensions. For example the extensions of using a new transport protocol
clearly must ensure that there is a security layer that fulfills the
requirements, like using DTLS instead of TLS.



Cheers

Magnus Westerlund

IETF Transport Area Director
----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone  +46 10 7148287
Färögatan 6                | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden| mailto: [email protected]
----------------------------------------------------------------------