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

Thanks,

The new version addresses my comments. I will start an IETF last call
and then hand over this document to Lars Eggert.

Cheers

Magnus

Magnus Westerlund skrev 2010-01-25 11:06:
> 
> 
> 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]
> ----------------------------------------------------------------------
> _______________________________________________
> nsis mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/nsis
> 


-- 

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]
----------------------------------------------------------------------