Subject: [Tsvwg] Comments on draft-ietf-tsvwg-admitted-realtime-dscp-04

From: Francois Le Faucheur IMAP <[email-masked]>
Date: Mon, 19 May 2008 12:17:24 +0200

Hello Fred, James, Martin,

A few questions:
============

* since the document is defining a single new DSCP value, it might  
avoid confusion if you update the title from "DSCPs for Capacity- 
Admitted Traffic" to "DSCP for Capacity-Admitted Traffic". No?

* section 3 says: " ... are sufficient to provide the services  
required for an Admitted Telephony service class and an Admitted  
Multimedia Conferencing Service Class."
Since the document does not recommend the use of an Admitted DSCP for  
any class other than Telephony, shouldn't "Admitted Multimedia  
Conferencing" be removed from section 3?

* Relationship to RFC4594:
So, regarding Telephony, RFC4594 defines one Telephony class that  
maps to EF.
My understanding is that this document effectively:
	* breaks down the telephony class into two subclasses:
		- the Non Capacity-Admitted Telephony subclass
		- the Capacity-Admitted Telephony subclass
	* proposes that Non Capacity-Admitted Telephony subclass would keep  
using EF
	* proposes that Capacity-Admitted Telephony subclass would use VOICE- 
ADMIT
Do we agree on this?
If yes, then I think this should be said more explicitely. In fact, I  
would propose you add a section specifically discussion relationship  
with RFC4594.
(also a nb of statements need to be corrected eg. section 4 says " It  
implements the Telephony Service Class described in [RFC4594]".
If no, could you correct me?

A few editorial suggestions:
====================

* Introduction:
s/It also recommends that certain classes of video/This document also  
recommends that certain classes of video/

* Introduction:
[at first read of " The video classes addressed include the ..." I  
misread this as "The video classes addressed by the new DSCP include  
the ...". You clarify underneath that the new DSCP does not apply to  
Video classes. But for readability I suggest]:
s/The video classes addressed include the .../The video classes  
discussed in [RFC4594] include the .../

*Introduction/Last paragraph:
s/ Other video classes are not believed to be required by the  
targeted services and to not have the current problem of confusion  
with unadmitted traffic/
Other video classes are believed to not have the current problem of  
confusion with unadmitted traffic and therefore would not benefit  
from the notion of a separate DSCP for admitted traffic/

* section 2.2.5
[To reflect the fact that IETF is working both on NSIS and RSVP]:
s/the IETF has been working on/the IETF has also been working on/

* section 2.2.5:
s/the use of RSVP Aggregation/the use of RSVP Aggregation ([RFC3175]  
[RFC4860][RFC4804])/

* section 2.3:
s/If capacity admission as described in Section 2.2.5 is in use,  
thresholds can be applied/If capacity admission as described in  
Section 2.2.5 is in use, thresholds can be applied (e.g. using draft- 
ietf-tsvwg-emergency-rsvp)/

* IANA Considerations:
s/value for the code point 101100/value for the code point is 101100/

Francois

---

From: Fred Baker <[email-masked]>
Date: Tue, 20 May 2008 16:08:15 -0700

I just replied privately. Thanks for readig the document; it confirms  
my belief that if I waited to update the document I would get another  
review.

There is one point you appear to have missed - the document  
recommends the use of admission with three video classes as well as  
voice. It just doesn't ask for a new code point for those.

I am picking up your other comments in this note.

On May 19, 2008, at 3:17 AM, Francois Le Faucheur IMAP wrote:

> Since the document does not recommend the use of an Admitted DSCP  
> for any class other than Telephony, shouldn't "Admitted Multimedia  
> 	* proposes that Non Capacity-Admitted Telephony subclass would  
> keep using EF
> 	* proposes that Capacity-Admitted Telephony subclass would use  
> VOICE-ADMIT
> Do we agree on this?
> If yes, then I think this should be said more explicitely. In fact,  
> I would propose you add a section specifically discussion  
> relationship with RFC4594.
> (also a nb of statements need to be corrected eg. section 4 says "  
> It implements the Telephony Service Class described in [RFC4594]".
> s/It also recommends that certain classes of video/This document  
> also recommends that certain classes of video/
>
> * Introduction:
> misread this as "The video classes addressed by the new DSCP  
> include the ...". You clarify underneath that the new DSCP does not  
> apply to Video classes. But for readability I suggest]:
> s/the use of RSVP Aggregation/the use of RSVP Aggregation  
> ([RFC3175] [RFC4860][RFC4804])/
>
> * section 2.3:
> Section 2.2.5 is in use, thresholds can be applied (e.g. using  
> draft-ietf-tsvwg-emergency-rsvp)/
>
> * IANA Considerations:

---

From: Francois Le Faucheur IMAP <[email-masked]>
Date: Wed, 21 May 2008 14:31:30 +0200

On 21 May 2008, at 01:08, Fred Baker wrote:

> I just replied privately. Thanks for readig the document; it  
> confirms my belief that if I waited to update the document I would  
> get another review.
>

I did get that point. The comments applied with that in mind.  
Anyways, remaining open points specifically discussed in the "please  
review changes" thread.
Cheers
Francois

>> If yes, then I think this should be said more explicitely. In  
>> fact, I would propose you add a section specifically discussion  
>> include the ...". You clarify underneath that the new DSCP does  
>> not apply to Video classes. But for readability I suggest]:
>> Other video classes are believed to not have the current problem  
>> of confusion with unadmitted traffic and therefore would not  
>> benefit from the notion of a separate DSCP for admitted traffic/
>>
>> * section 2.2.5