AW: [NSIS] QSPEC Comments

["Tschofenig, Hannes" <[e-mail]>]

Hi Jerry, 

thanks for your response. 

> Hi Hannes,
> 
> Thanks for the comments. 
> 
> > -----Original Message-----
> > From: Tschofenig, Hannes [mailto:[e-mail]] 
> > Sent: Friday, May 12, 2006 5:09 AM
> > To: nsis
> > Subject: [NSIS] QSPEC Comments
> > 
> > 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. 
> 
> Agree with all the above comments.
> 
> > - You shouldn't request IANA to allocate value for QOSMs in 
> the QSPEC
> > template document.
> 
> 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.

I think that this should be done in QOSMs. 
That's the right place. 

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

But you have this information already in the QoS NSLP and it would be
trivial to indicate this info when the QoS NSLP interacts with the RMF.
I think it is duplicate info. 


> 
> > - Is the idea of the tunneled parameter flag inline with 
> the QoS NSLP
> > 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?

The tunneled QSPEC is never interpreted in the way how the QoS NSLP
works and hence interior QoS nodes will never see the flag. 

> 
> > - 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). 
> 
> Haven't heard further from Andrew RE error-codes discussion, 
> so I think
> we're ready now to update the QSPEC I-D.

Ok. 


Ciao
Hannes


> 
> Thanks,
> Jerry
> 
> > 
> > Ciao
> > Hannes
> > 
> > _______________________________________________
> > nsis mailing list
> > [e-mail]
> > https://www1.ietf.org/mailman/listinfo/nsis
> > 
> 
> _______________________________________________
> nsis mailing list
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/nsis
> 

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