Subject: RE: AW: [NSIS] Any resolution to the QSPEC mandatory parameter list?

From: "Hancock, Robert" <[email-masked]>
Date: Wed, 19 Jul 2006 09:48:32 +0100

hi jerry, all,

a list of 3 does not seem too bad to me; possibly the actual 
number of mandatory parameters hasn't been too obvious to 
everyone up to now. (and i was surprised to be including the
ctot etc. parameters, but i couldn't find where it said they
were optional ... i guess it's clear how to fix that.)

i would make one tweak to the text (not sure where), which
might have some interactions with some of the other comments
on the list recently: since the class/priority parameters are 
at least in principle extensible, and parameter support is
mandatory, should one consider an extension to one of these 
parameters be considered as having a similar impact to
defining a new mandatory parameter? the effect on existing
implementations is the same, i think. and hence there is some
value in getting all the variants of the mandatory parameters
in the base spec.

also, i think this underlines that some ABNF for the Qspec
contents would be a big help.

cheers,

r.

> -----Original Message-----
> From: Ash, Gerald R (Jerry), ALABS [mailto:[email-masked]] 
> Sent: 18 July 2006 22:10
> To: Hancock, Robert
> Cc: Ash, Gerald R (Jerry), ALABS; [email-masked]
> Subject: RE: AW: [NSIS] Any resolution to the QSPEC mandatory 
> parameter list?
> 
> 
> Hi Robert,
> 
> See below. 
> 
> > -----Original Message-----
> > From: Hancock, Robert [mailto:[email-masked]] 
> > Sent: Tuesday, July 18, 2006 11:13 AM
> > To: Ash, Gerald R (Jerry), ALABS
> > Cc: [email-masked]
> > Subject: RE: AW: [NSIS] Any resolution to the QSPEC mandatory 
> > parameter list?
> > 
> > hi all,
> > 
> > just to check I understand the draft correctly: the
> > *current* list of mandatory parameters (that can occur
> > in a QoS description object) is:
> > 
> >           7.2.3 <Bandwidth>
> >           7.2.5 <Token Bucket> Parameters (1st instance only)
> >           7.2.6 <QoS Class> Parameters (3 subtypes)
> >           7.2.7 Priority Parameters (3 subtypes)
> >           7.2.12 <Ctot> <Dtot> <Csum> <Dsum> Parameters
> > 
> > is this correct?
> 
> Yes to the first 3 QSPEC parameters (<Bandwidth> <Token 
> Bucket> <QoS Class>), however <Ctot> <Dtot> <Csum> <Dsum> are 
> optional QSPEC parameters.
> 
> Also, I agree with the above characterization.  We can group 
> into only 3 mandatory QSPEC QoS Description parameters 
> (containers), as follows:
> 
> 1. <Traffic>: <bandwidth>; <token bucket (first instance)>  
> (populate only one)
> 2. <QoS class>: <PHB class>; <y.1541 class>; <DSTE class 
> type> (populate only one)
> 3. <Priority>: <preemption/defending>; <admission/RPH> 
> (populate only one pair)
> 
> These plus one mandatory QSPEC control information parameter 
> (<Excess treatment>) makes only 4 mandatory QSPEC parameters 
> in total, which seems minimal, and is consistent with the 
> original concept.
> 
> Thanks,
> Jerry
> 
> > 
> > r.
> > 
> > > -----Original Message-----
> > > From: Georgios Karagiannis [mailto:[email-masked]] 
> > > Sent: 17 July 2006 14:08
> > > To: [email-masked]; 
> > > [email-masked]; [email-masked]
> > > Cc: Ash, Gerald R (Jerry), ALABS; [email-masked]
> > > Subject: Re: AW: [NSIS] Any resolution to the QSPEC mandatory 
> > > parameter list?
> > > 
> > > 
> > > Hi Cornelia
> > > 
> > > >From my point of view the only mandatory parameters are 
> the Traffic
> > > specification parameters i.e., <Token Bucket>, <Bandwidth> 
> > > and the "Non
> > > QoSM Hop", assuming that the QoS-NSLP will include the 
> "non QoS-NSLP
> > > Hop" parameter, see my previous e-mail on this!
> > > 
> > > Best regards,
> > > Georgios
> > > 
> > > On 7/17/2006, "Kappler, Cornelia" 
> > > <[email-masked]> wrote:
> > > 
> > > >Dear all,
> > > >
> > > >I've been off-list for the last 10 days and may have 
> > > >difficulties grasping the real point of the debate.
> > > >
> > > >I'd prefer some concrete suggestions to which parameters 
> > > >should not be mandatory. Rather than blanket statements "List 
> > > >is too long" or "List is too short" or "we should have N 
> > > >parameters".
> > > >
> > > >The question is not really whether it should be 2 or 8 or 20 
> > > >mandatory parameters. It is _which_ parameters are necessary 
> > > >to _just_ accomodate the key ideas of typical QOSMs.
> > > >
> > > >Cornelia
> > > >
> > > >> -----Ursprüngliche Nachricht-----
> > > >> Von: Georgios Karagiannis [mailto:[email-masked]]
> > > >> Gesendet: Samstag, 15. Juli 2006 19:58
> > > >> An: 'Bernd Schloer'; 'Jukka MJ Manner'
> > > >> Cc: 'Ash, Gerald R \(Jerry\), ALABS'; [email-masked]
> > > >> Betreff: RE: [NSIS] Any resolution to the QSPEC mandatory
> > > >> parameter list?
> > > >>
> > > >> Hi
> > > >>
> > > >> Okay, but how many mandatory parameters should the central
> > > >> draft contain?
> > > >>
> > > >> Best Regards,
> > > >> Georgios
> > > >>
> > > >> -----Original Message-----
> > > >> From: Bernd Schloer [mailto:[email-masked]]
> > > >> Sent: zaterdag 15 juli 2006 19:32
> > > >> To: Jukka MJ Manner
> > > >> Cc: Ash, Gerald R \(Jerry\), ALABS; [email-masked]
> > > >> Subject: Re: [NSIS] Any resolution to the QSPEC mandatory
> > > >> parameter list?
> > > >>
> > > >> Hi,
> > > >>
> > > >> it would be easier to define new QOSMs, when the mapping 
> > > >> of mandatory
> > > >> parameters is listed in a central draft. This would also ensure
> > > >> interoperability.
> > > >>
> > > >> Bernd
> > > >>
> > > >>
> > > >> Jukka MJ Manner wrote:
> > > >> > Hi,
> > > >> >
> > > >> > I think the problem is that setting too many mandatory 
> > > >> > parameters
> > > >> > effectively limits people to define new QOSMs (even the
> > > >> > current ones)
> > > >> > - all QOSMs must be based on IntServ or DiffServ.
> > > >> > Interworking is an
> > > >> > important issue, I fully agree. That is why I'm not sure
> > > >> > which way we
> > > >> > should actually go: more or less mandatory parameters. 
> > > >> > (I think I'm
> > > >> > inclined towards more flexibility)
> > > >> >
> > > >> > About the need for a change, I haven't seen any comment 
> > > >> > so far for
> > > >> > keeping the longish list of mandatory parameters. All 
> > > >> > messages have
> > > >> > been about introducing more flexibility. We should have had
> > > >> > a hummm at
> > > >> > the meeting to see what people would want.
> > > >> >
> > > >> > Maybe people could speak up about what they want?
> > > >> >
> > > >> > Jukka
> > > >> >
> > > >> > On Thu, 13 Jul 2006, Ash, Gerald R \(Jerry\), ALABS wrote:
> > > >> >
> > > >> >
> > > >> >>Hi Jukka,
> > > >> >>
> > > >> >>See below.
> > > >> >>
> > > >> >>
> > > >> >>>-----Original Message-----
> > > >> >>>From: Jukka MJ Manner [mailto:[email-masked]]
> > > >> >>>Sent: Thursday, July 13, 2006 10:19 AM
> > > >> >>>To: [email-masked]
> > > >> >>>Subject: [NSIS] Any resolution to the QSPEC mandatory
> > > >> >>>parameter list?
> > > >> >>>
> > > >> >>>
> > > >> >>>I think the discussion on the mandatory and optional
> > > >> >>>parameters ended
> > > >> >>>without a clear resolution. I think there were good notes
> > > >> >>>on making
> > > >> >>>the list of mandatory parameters shorter and/or allow 
> > > >> >>>an "ignore"
> > > >> >>>interpretation of a mandatory parameter, and other ways to
> > > >> >>>make the
> > > >> >>>template less strict. I also support these comments.
> > > >> >>>
> > > >> >>>Any views from the QSPEC people on how to resolve these 
> > > >> >>>comments?
> > > >> >>
> > > >> >>I'm not in favor of fundamentally changing the definition
> > > >> >>of mandatory
> > > >> >>and optional QSPEC parameters, as I think is being 
> > > >> >>proposed.  In
> > > >> >>effect, to allow a mandatory parameter to be ignored would
> > > >> >>eliminate
> > > >> >>the distinction between mandatory parameters (MUST 
> interpret if
> > > >> >>populated) and optional parameters (SHOULD interpret if
> > > >> >>populated).
> > > >> >>The original idea of the QSPEC template is to provide a
> > > >> >>common set of
> > > >> >>mandatory parameters that would be interpreted (if 
> > > >> >>populated by the
> > > >> >>QNI) by all QOSMs.  This would allow a degree of 
> > > >> >>interoperability.
> > > >> >>The set of mandatory parameters is based in part on 
> > > >> >>parameters from
> > > >> >>the INTSERV and DIFFSERV models that should be commonly
> > > >> >>interpreted by
> > > >> >>all QOSMs (that was the original charge to the QSPEC 
> > > >> >>template draft
> > > >> >>approach).
> > > >> >>
> > > >> >>The other alternative (i.e., to be able to 'ignore' mandatory
> > > >> >>parameters) is essentially to make all parameters optional
> > > >> >>parameters
> > > >> >>(SHOULD interpret if populated).  Optional parameters allow
> > > >> >>the N-flag
> > > >> >>(not supported flag) to be set if a QOSM wishes to 
> > > >> >>'ignore' (not
> > > >> >>interpret) a parameter.
> > > >> >>
> > > >> >>I'm not clear on the motivation for this other alternative.
> > > >> >> Perhaps
> > > >> >>some particular QOSM wants to introduce the possibility of
> > > >> >>'ignoring'
> > > >> >>mandatory parameters.  Y.1541-QOSM doesn't require this nor
> > > >> >>does the
> > > >> >>CL-QOSM (AFAIK).  Perhaps the RMD-QOSM for some reason
> > > >> >>requires this
> > > >> >>-- if so, I'm not clear what is the justification?
> > > >> >>
> > > >> >>I haven't seen that much support for a major change in 
> > > >> >>the QSPEC
> > > >> >>template approach to be able to 'ignore' mandatory 
> parameters.
> > > >> >>
> > > >> >>Thanks,
> > > >> >>Jerry
> > > >> >>
> > > >> >>
> > > >> >>>Regards,
> > > >> >>>Jukka
> 

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

---

From: "Ash, Gerald R \(Jerry\), ALABS" <[email-masked]>
Date: Wed, 19 Jul 2006 10:43:32 -0500

Hi Robert,

See below. 

> Sent: Wednesday, July 19, 2006 4:49 AM

Definitely.  We'll group and clearly identify the mandatory and optional QSPEC parameters.
 
> value in getting all the variants of the mandatory parameters

Agree that an extension to one of the mandatory parameters would be the same as defining a new mandatory parameter.
 
> contents would be a big help.

OK, we'll pursue ABNF notation in the QSPEC document.

Thanks,
Jerry