Re: Review of draft-ietf-nsis-qos-nslp-15.txt

Thanks Martin!

I'll update the draft, and resubmit it as soon as possible.

Jukka

On Tue, 8 Jan 2008, Martin Stiemerling wrote:

> Hi all,
> 
> Here is my chair's review of draft-ietf-nsis-qos-nslp-15.txt.
> 
> I have reviewed the whole draft and do not see any issue with it. It is
> written in an excellent way and seems to be just fine. Thanks to all who
> contributed and especially to the editors.
> 
> The comments are just editorial or minor clarifications. Please fix them if
> possible and submit a new version.
> 
> Editorial issues:
> 
> - ID nits throws some output (see attached at bottom of this mail). The only
> relevant is an editorial nit; 2nd under "miscellaneous warnings".
> 
> - page 6, definition of session: " A session defines an association between a
> QNI and QNR related to a data flow." Just for my understanding: This sounds
> such as the involved QNEs on the path are not part of the session? The
> definition is a bit unclear in this respect, IMHO.
> 
> - page 9, first para has some strange line break, between "...network" and
> "management..."
> 
> - page 9: para starting with "Policy control..." refers to qos-auth which is a
> I-D. Do we still need to point to this draft and if yes, why it is happening
> here in the introduction and not in the appropriate section?
> 
> - page 11, first para (cont'd from previous page): s/source of the each/source
> of each
> 
> - page 11, section 3.1.2, third para, refers to the QSPEC as "ongoing effort"
> which is hopefully not true anymore. Rephrasing would be good.
> 
> - page 12, the para before the last para, "QoS models..." again refers to the
> QSPEC draft, seems to superfluous in this section.
> 
> - page 14, third para refers to nslp-auth draft. As we won't have this draft
> as WG item, it is appropriate to remove the reference here and also from  the
> reference section
> 
> - page 16, last para, s/a unidirectional/an unidirectional
> 
> - page 20, the para before the last para refers to "middle of session". What
> is "middle of session"?
> 
> - page 21, para before section 3.2.12.1 seems to belong in section 3.2.12.1
> 
> - page 24, section 3.2.12 it would be nice to refer to 5.2.5.2 here, so that
> people can jump there to see the solution, if desired, and the more exhaustive
> explanation
> 
> - page 34, last para of section 4.5 has a self-reference to section 4.5 but
> claiming that it is different.
> 
> - page 42, middle of page says three flags, but there are four of them.
> 
> - page 45, second para says "Retransmissions SHOULD be disabled." If haven't
> understood on which level the retransmission should be disabled (GIST or NSLP
> level?).
> 
> - page 70, section 5.3.7, first para, last sentence: at locationg i refer.
> Needs to be fixed somehow.
> 
> - page 74, section 5.4.1, list end of the page: s/The SCOPING/the SCOPING.
> also for following bullets. Also for the list on  page 75.
> 
> - Section 5.4.1 and 5.4.2 say
> ..."monitored.   If they differ then the BREAK flag of new generated messages
> (e.g.,  QUERY, RESERVE or RESPONSE) SHOULD be set.  In situations ..."
> Would RECOMMENDED be more appropriate here? (of course considering also the
> case described after ("...BREAK flag MUST not be set...").
> 
> - page 76, last para: "Note that QUERY messages with the RESERVE-INIT flag set
> MUST be answered by the QNI." Shouldn't it read "...answered by the QNR."?
> 
> - page 79, section 6 (but not going in 6.1 and subsequent): The lists are
> broken (formatting issue)
> 
> - page 90: Appendix A. It would be good to add something along "This appendix
> is informational only."
> 
> - page 95: Heading has two times "Appendix B".
> 
> 
> That's it.
> 
> Thanks!
> 
>  Martin
> 
> *********
> ID  Nits:
> 
> idnits 2.05.03
> 
> tmp/draft-ietf-nsis-qos-nslp-15.txt:
> 
>  Checking boilerplate required by RFC 3978 and 3979, updated by RFC 4748:
>  ----------------------------------------------------------------------------
> 
>     No issues found here.
> 
>  Checking nits according to http://www.ietf.org/ietf/1id-guidelines.txt:
>  ----------------------------------------------------------------------------
> 
>     No issues found here.
> 
>  Checking nits according to http://www.ietf.org/ID-Checklist.html:
>  ----------------------------------------------------------------------------
> 
>     No issues found here.
> 
>  Miscellaneous warnings:
>  ----------------------------------------------------------------------------
> 
>  == The copyright year in the IETF Trust Copyright Line does not match the
>     current year
> 
>  == Using lowercase 'not' together with uppercase 'MUST' is not an accepted
>     usage according to RFC 2119.  Please use 'MUST NOT' (if that is what you
>     mean).
> 
>     Found 'MUST not' in this paragraph:
> 
>     If a stateful QoS NSLP QNE receives a QUERY message with the
>     RESERVE-INIT flag and BREAK flag set then the BREAK flag of new generated
>     messages (e.g., QUERY, RESERVE or RESPONSE) MUST be set.  When a stateful
>     QoS NSLP QNE receives a QUERY message with the the RESERVE-INIT flag set
>     and BREAK flag not set then then the IP-TTL and Original-TTL values in
>     GIST RecvMessage primitive MUST be monitored. If they differ then the
>     BREAK flag of new generated messages (e.g., QUERY, RESERVE or RESPONSE)
>     SHOULD be set.  In situations where a QNE or a domain is able to provide
>     QoS using other means, see Section 3.3.5, then the BREAK flag MUST not be
>     set.
> 
> 
>  Checking references for intended status: Proposed Standard
>  ----------------------------------------------------------------------------
> 
>     (See RFC 3967 for information about using normative references to
>     lower-maturity documents in RFCs)
> 
>  == Outdated reference: A later version (-18) exists of
>     draft-ietf-nsis-qspec-17
> 
>  == Outdated reference: A later version (-08) exists of
>     draft-ietf-nsis-applicability-mobility-signaling-07
> 
>  == Outdated reference: A later version (-12) exists of
>     draft-ietf-nsis-rmd-10
> 
> 
>     Summary: 0 errors (**), 5 warnings (==), 0 comments (--).
> --------------------------------------------------------------------------------
> 
> [email protected]
> 
> NEC Laboratories Europe - Network Research Division
> 
> NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London W3
> 6BL | Registered in England 2832014
>