Subject: [NSIS] QSPEC Comments

From: "Tschofenig, Hannes" <[email-masked]>
Date: Fri, 12 May 2006 11:09:07 +0200

Hi all

I have a few minor comments for the QSPEC draft:

- Use either 'QoS NSLP' or 'QoS-NSLP' terminology. The QoS NSLP draft
uses 'QoS NSLP'
- Don't use RFC 2119 language in examples (e.g., Section 4.3). The same
is true for RFC 2119 language in the appendix. 
- Review RFC 2119 language in the text. Example: First sentence in
Section 4.6: MAY is inappropriate there. 
- Ability to define mandatory QoS parameters in QOSMs no clear
- Reference to [NSIS-EXTENSIBILITY] in the IANA consideration section is
not a good idea. It also needs to be removed from the normative
reference since otherwise this document will be blocked. 
- You shouldn't request IANA to allocate value for QOSMs in the QSPEC
template document.
- Why do you need information of the type of QoS signaling in the QSPEC
template (e.g., sender-initiated, receiver-oriented QoS signaling)?
- Is the idea of the tunneled parameter flag inline with the QoS NSLP
understanding of tunneling? 
- Use capitalized words in captions and headlines. The RFC editor will
thank you.  

Other comments have been posted by Andrew already (e.g., definition of
mandatory parameters). 

Ciao
Hannes

_______________________________________________
nsis mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/nsis

---

From: "Ash, Gerald R \(Jerry\), ALABS" <[email-masked]>
Date: Mon, 22 May 2006 07:46:46 -0500

Hi Hannes,

Thanks for the comments. 

> -----Original Message-----
> From: Tschofenig, Hannes [mailto:[email-masked]] 
> Sent: Friday, May 12, 2006 5:09 AM
> To: nsis
> Subject: [NSIS] QSPEC Comments
> 
> Hi all
> 
> - Don't use RFC 2119 language in examples (e.g., Section 
> 4.3). The same is true for RFC 2119 language in the appendix. 
> - Reference to [NSIS-EXTENSIBILITY] in the IANA consideration 
> section is not a good idea. It also needs to be removed from the
> normative reference since otherwise this document will be blocked. 

Agree with all the above comments.

> - You shouldn't request IANA to allocate value for QOSMs in the QSPEC

Then where should that be done, in the QoS-NSLP document perhaps?  IMO
it needs to be done either in the QSPEC document or QoS-NSLP document.

> - Why do you need information of the type of QoS signaling in 
> the QSPEC template (e.g., sender-initiated, receiver-oriented QoS
> signaling)?

Section 6 specifies procedures for using QSPEC in the RMF, for various
scenarios.  For example, the "RSVP-style" scenario specified in Section
6.2 was specifically requested at one of the Interim NSIS meetings.  It
ensures backward compatibility with RSVP.

> understanding of tunneling?

AFAIK it is consistent.  The flag is set as specified in Section 4.5.2:

"  Each QSPEC parameter has an associated 'tunneled-parameter flag'.
   When a RESERVE message is tunneled through a domain, QNEs inside the
   domain cannot update read-write parameters.  The egress QNE in a
   domain has two choices: either it is configured to have the knowledge
   to update the parameters correctly.  Or it cannot update the
   parameters.  In this case it MUST set the tunneled-parameter flag to
   tell the QNI (or QNR) that the information contained in the
   read-write parameter is most likely incorrect (or a lower bound)."

The egress QNE (end of tunnel) sets the flag accordingly.  Do you think
this is inconsistent?

> Other comments have been posted by Andrew already (e.g., definition of

Haven't heard further from Andrew RE error-codes discussion, so I think
we're ready now to update the QSPEC I-D.

Thanks,
Jerry