Subject: RE: [NSIS] Alternatives for supporting domain-local admission con troloperation in NSLP/QSPEC

From: "Roy, Radhika R." <[email-masked]>
Date: Mon, 27 Nov 2006 10:23:59 -0500

John:

Thanks with a great relief that it is good that this is an Informational
RFC. If it is so, why does this not mentioned in the draft as it was the
case in the beginning? Did I miss it?

The next questions that are relevant for this "Informational" RFC are as
follows as this draft has been taken as the WG item:

*	Is this informational RFC supposed to create "Interworking" problems
between IETF "standard-based" QOS models (RSVP, IntServ, and DiffServ) and
so-called "non-standards" QOS models (Y.1541, DSTE, and 3GPP/Y.1541) through
mixing between "apples" and "oranges" in the same draft?
*	Why QOS models and QOS SLAs need to be treated in the same level
just because of the "informational" RFC?
*	If there are separate individual QOSM drafts, why this QSPEC draft
needs to deal with all those things of all QOS models and QOS SLAs that are
"incomplete" and create problems of technical problems including
"non-interoperability?"
*	Why is it too late to clean the draft as Ronald mentioned just
because it is an "Informational" RFC?
*	As you have already pointed out to all NSIS WG members that there is
no WG consensus to include Y.1451 (i.e., QOS SLAs) in this draft despite it
is an "Informational" RFC?

Best regards,

Radhika

PS: 

1.	If QOS SLAs are removed from this draft, why can this draft be a
"standard-track" RFC as NSIS QOS signaling messages will almost be blind or
unworkable to carry the requisite information of the QOS parameters?
2.	Even the "guidelines" for "encoding" of QSPEC by different QOS
Models and QOS SLAs in this QSPEC draft will be "incomplete" and will create
more problems than solving this because the individual QOSM drafts are
better place to do so as they will be complete for each QOS model and each
QOS SLA. However, the "generic" encoding "guidelines" without mentioning any
particular QOS models or QOS SLAs will be OK in this draft.

  _____  

From: [email-masked] [mailto:[email-masked]] 
Sent: Monday, November 27, 2006 3:03 AM
To: [email-masked]
Cc: [email-masked]
Subject: RE: [NSIS] Alternatives for supporting domain-local admission
controloperation in NSLP/QSPEC

The QSPEC document is an Informational RFC, so your comment about this is
really not very relevant to the discussion.  

thanks,
John

  _____  

From: ext Roy, Radhika R. [mailto:[email-masked]] 
Sent: 26 November, 2006 23:50
To: Roland Bless; Georgios Karagiannis
Cc: Loughney John (Nokia-NRC/Helsinki); Morton, Alfred C, JR (Al), ALABS;
[email-masked]; [email-masked]
Subject: RE: [NSIS] Alternatives for supporting domain-local admission
controloperation in NSLP/QSPEC

Ronald and Georgios:

Why is it too late to clean out the document as Ronald has explained?

NSIS WG in particular and IETF in general have waited almost two years to
root out these "technically" inconsistencies. It is better NOT to publish a
standard track RFC like this.

If needed, NSIS WG Chair needs to appoint a "single" EDITOR who can clean
out this document.

Why does the NSIS WG Chair need to appoint 3 (Three) editors?  Is it not the
problems of appointing 3 editors for the same simple RFC? Is it not because
of 3 editors who have put those things defying a "simple" common sense that
to keep the document is the most important thing from the IETF point of
view?

Is it not that people still trying to force so-called QOS SLAs like Y.1541,
DSTE, and 3GPP/Y.1541 in this draft as "standard" QOS models?

A question to Georgios: Would you please provide any technical
justifications why so called "non-standard" QOS SLAs like Y.1541, DSTE, and
3GPP/Y.1541 in this "standard" track RFC in the same level of IETF
"standard-based" RSVP, IntServ, and DiffServ QOS Model? Is it not mixing
between "apples" and "oranges?"

If Georgios cannot justify the above, references of so called "non-standard"
QOS SLAs like Y.1541, DSTE, and 3GPP/Y.1541 as even examples for encoding of
QSPEC parameters must NOT be included.

If it is done despite objections, we would think that this QSPEC RFC must
NOT be a "standard" track RFC because a standard track RFC must NOT contain
"non-standard" QOS models. This will also be brought to the notice of the
NSIS WG Chairs and IESG.

Best regards,

Radhika

  _____  

From: [email-masked] on behalf of Ash, Gerald R (Jerry), ALABS
Sent: Sat 11/25/2006 7:44 AM
To: Roland Bless; Georgios Karagiannis
Cc: [email-masked]; Ash, Gerald R (Jerry), ALABS; Morton, Alfred C,
JR (Al), ALABS; [email-masked]; [email-masked]
Subject: RE: [NSIS] Alternatives for supporting domain-local admission
controloperation in NSLP/QSPEC

Hi Roland, Georgios,

See below.

> -----Original Message-----
> From: Roland Bless [mailto:[email-masked] <mailto:[email-masked]> ]
> Sent: Friday, November 24, 2006 11:30 AM
> To: Georgios Karagiannis
> Cc: Ash, Gerald R (Jerry), ALABS; [email-masked];
> Morton, Alfred C, JR (Al), ALABS; [email-masked]
> Subject: Re: [NSIS] Alternatives for
> supportingdomain-localadmissioncontroloperation in NSLP/QSPEC
>
> Hi Georgios,
>
> see comments inline.
>
> Georgios Karagiannis wrote:
> > What about my proposal, sent in a previous e-mail!
> >
> > "But the QSPEC template draft is not a generic QSPEC draft.
> > The Token Bucket and the constraints can be seen as
> something that can be
> > common and can be used for the interoperability and the rest of the
> > encoded parameters can just be used as guidelines on how the QoS
> > models can encode their parameters.
> >
> > Thus maybe Jerry could separate the QSPEC template draft into:
> > A section/part that describes the Token Bucket + constraints.
> > This part could then emphasize that the described parameters
> > can be used for interoperability purposes.
> >
> > Another part of the QSPEC template draft will describe
> > the other parameters.
> > The goal of this part is to provide guidelines to QoS models
> > on how to encode the different parameters, with the currently
> > available parameters used as examples."
>
> As I said at the meeting:
> the current QSPEC template draft actually contains both aspects
> since we started with the template idea first and then added the
> interoperability aspects. An even cleaner separation would be
> a split into two separate documents:
> - one (template focus) explaining the general idea and layout
> of QSPECs,
>   which could be used by other QoS models as guidance to create their
>   own QSPECs, and
> - one (interoperability aspects) proposing a generic QSPEC as
>   an example of a QSPEC instance
> However, it's also ok for me to describe both aspects in one document
> as it is probably now too late and too disturbing to make this
> separation.

OK, Georgios' proposal sounds like a good compromise.

Thanks,
Regards,
Jerry

> Regards,
>  Roland

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

---

From: <[email-masked]>
Date: Thu, 30 Nov 2006 09:15:27 +0200

If you read the charter, it says:

Jun 2006	  	Submit 'NSIS QoS Specification Template' to IESG
for publication as an Informational RFC

John 

>Sent: 27 November, 2006 17:24
>To: Loughney John (Nokia-NRC/Helsinki)
>Cc: [email-masked]
>Subject: RE: [NSIS] Alternatives for supporting domain-local 
>admission controloperation in NSLP/QSPEC
>
>John:
>
> 
>
>Thanks with a great relief that it is good that this is an 
>Informational RFC. If it is so, why does this not mentioned in 
>the draft as it was the case in the beginning? Did I miss it?
>
> 
>
>The next questions that are relevant for this "Informational" 
>RFC are as follows as this draft has been taken as the WG item:
>
>between IETF "standard-based" QOS models (RSVP, IntServ, and 
>DiffServ) and so-called "non-standards" QOS models (Y.1541, 
>DSTE, and 3GPP/Y.1541) through mixing between "apples" and 
>"oranges" in the same draft?
>needs to deal with all those things of all QOS models and QOS 
>SLAs that are "incomplete" and create problems of technical 
>problems including "non-interoperability?"
>no WG consensus to include Y.1451 (i.e., QOS SLAs) in this 
>draft despite it is an "Informational" RFC?
>
> 
>
>Best regards,
>
>Radhika
>
> 
>
>PS: 
>
> 
>
>"standard-track" RFC as NSIS QOS signaling messages will 
>almost be blind or unworkable to carry the requisite 
>information of the QOS parameters?
>Models and QOS SLAs in this QSPEC draft will be "incomplete" 
>and will create more problems than solving this because the 
>individual QOSM drafts are better place to do so as they will 
>be complete for each QOS model and each QOS SLA. However, the 
>"generic" encoding "guidelines" without mentioning any 
>Subject: RE: [NSIS] Alternatives for supporting domain-local 
>admission controloperation in NSLP/QSPEC
>
> 
>
>The QSPEC document is an Informational RFC, so your comment 
>about this is really not very relevant to the discussion.  
>
> 
>
>thanks,
>John
>
> 
>
>
>  _____  
>
>
>Cc: Loughney John (Nokia-NRC/Helsinki); Morton, Alfred C, JR 
>(Al), ALABS; [email-masked]; [email-masked]
>Subject: RE: [NSIS] Alternatives for supporting domain-local 
>admission controloperation in NSLP/QSPEC
>
>Ronald and Georgios:
>
> 
>
>NSIS WG in particular and IETF in general have waited almost 
>two years to root out these "technically" inconsistencies. It 
>is better NOT to publish a standard track RFC like this.
>
> 
>
>If needed, NSIS WG Chair needs to appoint a "single" EDITOR 
>who can clean out this document.
>
> 
>
>Why does the NSIS WG Chair need to appoint 3 (Three) editors?  
>Is it not the problems of appointing 3 editors for the same 
>simple RFC? Is it not because of 3 editors who have put those 
>things defying a "simple" common sense that to keep the 
>document is the most important thing from the IETF point of view?
>
> 
>
>Is it not that people still trying to force so-called QOS SLAs 
>like Y.1541, DSTE, and 3GPP/Y.1541 in this draft as "standard" 
>QOS models?
>
> 
>
>3GPP/Y.1541 in this "standard" track RFC in the same level of 
>IETF "standard-based" RSVP, IntServ, and DiffServ QOS Model? 
>Is it not mixing between "apples" and "oranges?"
>
> 
>
>QOS SLAs like Y.1541, DSTE, and 3GPP/Y.1541 as even examples 
>for encoding of QSPEC parameters must NOT be included.
>
> 
>
>If it is done despite objections, we would think that this 
>QSPEC RFC must NOT be a "standard" track RFC because a 
>standard track RFC must NOT contain "non-standard" QOS models. 
>This will also be brought to the notice of the NSIS WG Chairs and IESG.
>
> 
>
>Best regards,
>
>Radhika
>
> 
>
>
>  _____  
>
>
>Cc: [email-masked]; Ash, Gerald R (Jerry), ALABS; 
>Morton, Alfred C, JR (Al), ALABS; [email-masked]; 
>[email-masked]
>Subject: RE: [NSIS] Alternatives for supporting domain-local 
>admission controloperation in NSLP/QSPEC
>
>Hi Roland, Georgios,
>
>See below.
>
>> Cc: Ash, Gerald R (Jerry), ALABS; [email-masked]; Morton, 
>> Alfred C, JR (Al), ALABS; [email-masked]
>> > This part could then emphasize that the described 
>parameters can be 
>> > used for interoperability purposes.
>> >
>> > Another part of the QSPEC template draft will describe the other 
>> > parameters.
>> > The goal of this part is to provide guidelines to QoS 
>models on how 
>> > to encode the different parameters, with the currently available 
>> > parameters used as examples."
>>
>> the current QSPEC template draft actually contains both 
>aspects since 
>> we started with the template idea first and then added the 
>> interoperability aspects. An even cleaner separation would 
>be a split 
>> into two separate documents:
>> - one (template focus) explaining the general idea and layout of 
>> QSPECs,