[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [NSIS] QSPEC document
Hi Jerry
Well, this is not the way of how a WG should work.
I have expressed my concerns in a clear way and I am not getting any useful
and constructive remarks.
What you actually say is:
"Well only RMD-QOSM requires this functionality and therefore I decide
that we will not use this functionality anymore."
The functionality that I am talking about has been decided 4/5 years
ago and you cannot just change it.
Furthermore, please explain to me how someone will be able to
define the QOS model that should translate the RSVP aggregation
concept (RFC 3175) into NSIS when the changes and limitations that you are
now proposing will be included in NSIS.
Or are you also saying to me that it is not possibe to translate and use
the RSVP aggregation concept (RFC3175) into NSIS!
Best regards,
Georgios
> -----Original Message-----
> From: Ash, Gerald R (Jerry), ALABS [mailto:gash at att.com]
> Sent: maandag 22 januari 2007 16:47
> To: Georgios Karagiannis
> Cc: Ash, Gerald R (Jerry), ALABS; nsis at ietf.org
> Subject: RE: [NSIS] QSPEC document
>
> Georgios,
>
> See below.
>
> > -----Original Message-----
> > From: Georgios Karagiannis [mailto:karagian at cs.utwente.nl]
> > Sent: Monday, January 22, 2007 7:15 AM
> > To: Ash, Gerald R (Jerry), ALABS
> > Cc: nsis at ietf.org
> > Subject: RE: [NSIS] QSPEC document
> >
> > Hi Jerry
> >
> > Please see my updated comments on v. 13 of the QSPEC template draft
> > that I have sent this morning.
> > The below paragraph is in contradiction with the agreed
> NSIS concepts.
> > Please note that RMF functions are defined by QOS models and not by
> > the QOS-NSLP signaling framework.
> >
> > "Note that QOSM specifications SHOULD NOT define new RMF functions
> > required by a QOSM UNLESS such NSIS signaling functionality
> is defined
> > in QoS NSLP [QoS-SIG]. That is, a QOSM is not allowed to
> extend QoS
> > NSLP signaling functionality; new RMF functions are specified only
> > within a QoS NSLP signaling framework."
>
> Please see the responses to Attila and Magnus on this text.
> I agree that RMF functions are defined by QOSM specifications
> and not by the QoS-NSLP signaling document. The above
> statement does not contradict that fact.
>
> > Regarding other issues please check my e-mail that I have sent this
> > morning.
>
> I have read your email and it re-raises most of the below
> points that have been agreed by consensus and modified
> accordingly in the -14 QSPEC document. It would be best IMO
> to discuss any new comments during the WGLC on the -14 QSPEC
> document (should be published by the I-D Editor soon, perhaps today).
>
> As John stated, it seems that only the RMD authors have a
> problem with this, but it is quite unclear what the
> problem(s) might be for RMD implementation in regard to the
> current QSPEC document. If additional QoS-NSLP functionality
> is needed to support RMD, then the proper place is to propose
> extensions to the QoS-NSLP document, as you seem to have
> alluded to in your postings at
> http://www1.ietf.org/mail-archive/web/nsis/current/msg07455.html
> http://www1.ietf.org/mail-archive/web/nsis/current/msg07457.html
>
> Going on endlessly with word-smithing the QSPEC document does
> not seem the way to resolve whatever RMD issues you perceive IMO.
>
> Jerry
>
> >
> > Best Regards,
> > Georgios
> >
> >
> > > -----Original Message-----
> > > From: Ash, Gerald R (Jerry), ALABS [mailto:gash at att.com]
> > > Sent: vrijdag 19 januari 2007 22:31
> > > To: john.loughney at nokia.com; nsis at ietf.org
> > > Cc: Ash, Gerald R (Jerry), ALABS
> > > Subject: RE: [NSIS] QSPEC document
> > >
> > > Hi John,
> > >
> > > Per your request, I provide below a summary of the agreed-to
> > > changes/updates to the QSPEC draft
> > > http://ietf.org/internet-drafts/draft-ietf-nsis-qspec-13.txt,
> > > based on the list discussion over the last few weeks.
> > >
> > > I plan to update the draft according to these changes and
> submit in
> > > the next day or two. Hopefully then we'll be ready to go
> to WGLC on
> > > the document?
> > >
> > > Thanks,
> > > Regards,
> > > Jerry
> > >
> > > There were 3 issues being debated at length on the list,
> summarized
> > > here by Georgios:
> > > http://www1.ietf.org/mail-archive/web/nsis/current/msg07374.html
> > >
> > > Editor responses to these 3 issues are here:
> > > http://www1.ietf.org/mail-archive/web/nsis/current/msg07402.html
> > >
> > > to which you responded:
> > > http://www1.ietf.org/mail-archive/web/nsis/current/msg07407.html
> > >
> > > and further declared consensus on these 3 issues as follows:
> > > 1.
> http://www1.ietf.org/mail-archive/web/nsis/current/msg07408.html
> > > 2.
> http://www1.ietf.org/mail-archive/web/nsis/current/msg07409.html
> > > 3.
> http://www1.ietf.org/mail-archive/web/nsis/current/msg07410.html
> > >
> > > Based on the declared consensus in 1, 2, and 3 above the
> following
> > > changes are agreed to:
> > >
> > > 1. Add the following text to Section 4.3.3 (Traffic Handling
> > > Directives):
> > >
> > > "Note that QOSM specifications SHOULD NOT define new RMF
> functions
> > > required by a QOSM UNLESS such NSIS signaling functionality is
> > > defined in QoS NSLP [QoS-SIG]. That is, a QOSM is not allowed to
> > > extend QoS NSLP signaling functionality; new RMF functions are
> > > specified only within a QoS NSLP signaling framework."
> > >
> > > 2. Add the following text to Section 5.1 (Local QSPEC Definition &
> > > Processing):
> > >
> > > "Note that it is possible to use, at the same time, both a)
> > > tunneling a QSPEC through a local domain by initiating a
> new RESERVE
> > > at the domain edge, and b) defining a local QSPEC and
> encapsulating
> > > the initiator QSPEC, as defined above."
> > >
> > > 3. Add the following text to Section 4.1 (QoS Models):
> > >
> > > "Signaling functionality is only defined by the QoS NSLP document
> > > [QoS-SIG] and not by this document."
> > >
> > > Also based on list discussion, these changes have been agreed to:
> > >
> > > 4. Add the following text to Section 4.1 (QoS Models), and also
> > > reference specifically in Section 4.3.3 (Traffic Handling
> > > Directives):
> > >
> > > "QOSMs are free, subject to IANA registration and review
> rules, to
> > > extend QSPECs by adding parameters of any of the kinds
> supported by
> > > the standard QSPEC. This includes traffic description
> parameters,
> > > constraint parameters and traffic handling directives.
> QOSMs are not
> > > permitted, however, to reinterpret or redefine the standard QSPEC
> > > parameters specified in this document."
> > >
> > > 5. In Section 5.1 (Local QSPEC Definition & Processing), last
> > > paragraph:
> > >
> > > Change:
> > > "For example, RMD can define a local QSPEC that contains TMOD =
> > > bandwidth (sets r=p, b/m to large)."
> > >
> > > Into:
> > > "For example, in RMD the TMOD parameters contained in the
> original
> > > initiator QSPEC are mapped into the equivalent TMOD parameter
> > > representing only the peak bandwidth in the local QSPEC."
> > >
> > > 6. In Section 6.1 (General QSPEC Formats):
> > > Remove the sentence
> > > "N Flag: Not-supported QSPEC parameter flag (see Section 5.2.2).
> > > For QSPEC parameters the value of this flag is
> > always zero."
> > >
> > > ________________________________
> > >
> > > From: john.loughney at nokia.com [mailto:john.loughney at nokia.com]
> > > Sent: Friday, January 19, 2007 7:16 AM
> > > To: nsis at ietf.org
> > > Subject: [NSIS] QSPEC document
> > >
> > > Jerry,
> > >
> > > Could you send an update on the current status on the QSPEC?
> > > I think we were wrapping up most of the open issues, but
> it might be
> > > good to have a summary of where we stand on this.
> > > When do you think that you can update the document?
> > >
> > > thanks,
> > > John
>
> _______________________________________________
> nsis mailing list
> nsis at ietf.org
> https://www1.ietf.org/mailman/listinfo/nsis
>
_______________________________________________
nsis mailing list
nsis at ietf.org
https://www1.ietf.org/mailman/listinfo/nsis