Subject: RE: [NSIS] Alternatives for supporting domain-localadmissioncontr oloperation in NSLP/QSPEC

From: "Roy, Radhika R." <[email-masked]>
Date: Mon, 13 Nov 2006 11:07:34 -0500

Georgios and all:

The fact is that all QOS model-specific extensions, explanations, and
references MUST be DROPPED per consensus of this IETF meeting.  

In this way, the problems of all NON-interoperability among the
standard-based IETF QOS models (RSVP, IntServ, and DiffServ) and
so-called "private" non-IETF, non-standard QOS models (Y.1541 and
3GPP/Y.1541) will be avoided in this standard-track "generic" QSPEC RFC.

If anyone wants to avoid this consensus of the IETF meeting, they MUST
come up with the technical proposal how to solve the
NON-interoperability problems among the standard-based IETF QOS models
(RSVP, IntServ, and DiffServ) and so-called "private" non-IETF,
non-standard QOS models (Y.1541 and 3GPP/Y.1541). If brute forces are
used to add any references of QOS model-specific things as the present
draft stands, the consensus of the IETF will be broken and the draft
will NOT move for IESG approval as we will be again going to the circle
of interoperability issues.

Best regards,
Radhika

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Georgios Karagiannis
Sent: Monday, November 13, 2006 6:57 AM
To: 'Ash, Gerald R (Jerry), ALABS'; 'Roland Bless'; 'David R Oran'
Cc: 'NSIS Group'
Subject: RE: [NSIS] Alternatives for supporting
domain-localadmissioncontroloperation in NSLP/QSPEC

Hi Jerry

I agree with you!
I think that we now have reached a consensus on all open issues and we
can 
proceed on finalizing all NSIS base drafts!

Best Regards,
Georgios 

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

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Mon, 13 Nov 2006 17:32:54 +0100

Hi Roy

There are nomore interoperability issues since the only parameter 
that can be considered as mandatory is the Token Bucket parameter, 
which is used as the traffic source description.

Best regards,
Georgios

> From: [email-masked] [mailto:[email-masked]] 
> Sent: maandag 13 november 2006 17:08
> To: Georgios Karagiannis; Ash, Gerald R (Jerry), ALABS; 
> Roland Bless; David R Oran
> Cc: NSIS Group
> The fact is that all QOS model-specific extensions, 
> explanations, and references MUST be DROPPED per consensus of 
> this IETF meeting.  
> 
> In this way, the problems of all NON-interoperability among 
> the standard-based IETF QOS models (RSVP, IntServ, and 
> DiffServ) and so-called "private" non-IETF, non-standard QOS 
> models (Y.1541 and
> If anyone wants to avoid this consensus of the IETF meeting, 
> they MUST come up with the technical proposal how to solve 
> the NON-interoperability problems among the standard-based 
> IETF QOS models (RSVP, IntServ, and DiffServ) and so-called 
> "private" non-IETF, non-standard QOS models (Y.1541 and 
> 3GPP/Y.1541). If brute forces are used to add any references 
> of QOS model-specific things as the present draft stands, the 
> consensus of the IETF will be broken and the draft will NOT 
> move for IESG approval as we will be again going to the 
> circle of interoperability issues.
> 
> Best regards,
> Radhika
> 
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Georgios Karagiannis
> I think that we now have reached a consensus on all open 
> issues and we can proceed on finalizing all NSIS base drafts!
> 
> Best Regards,
> Georgios 
>

---

From: Roland Bless <[email-masked]>
Date: Tue, 14 Nov 2006 14:47:40 +0100

Hi Georgios,

> which is used as the traffic source description.

Yep. But as also already discussed, specifying a TMOD/TSPEC only is
pretty useless, i.e. you'll need to specify constraints. Otherwise,
best effort is sufficient and you can save your QoS signaling
completely.

Regards,
 Roland

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Tue, 14 Nov 2006 16:11:08 +0100

Hi Roland

Agreed!

Best Regards,
Georgios 

> From: Roland Bless [mailto:[email-masked]] 
> Sent: dinsdag 14 november 2006 14:48
> To: Georgios Karagiannis
> Cc: [email-masked]; 'Ash, Gerald R (Jerry), ALABS'; 
> 'David R Oran'; 'NSIS Group'
> Subject: Re: [NSIS] Alternatives for supporting 
> > There are nomore interoperability issues since the only 
> parameter that 
> > can be considered as mandatory is the Token Bucket 
> parameter, which is 
> > used as the traffic source description.
> 
> Yep. But as also already discussed, specifying a TMOD/TSPEC 
> only is pretty useless, i.e. you'll need to specify 
> constraints. Otherwise, best effort is sufficient and you can 
> save your QoS signaling completely.
> 
> Regards,
>  Roland
>