Subject: [Tsvwg] Last Call: draft-ietf-tsvwg-admitted-realtime-dscp (DSCP for Capacity-Admitted Traffic) to Proposed Standard

From: The IESG <[email-masked]>
Date: Thu, 13 Nov 2008 08:54:34 -0800 (PST)

The IESG has received a request from the Transport Area Working Group WG
(tsvwg) to consider the following document:

- 'DSCP for Capacity-Admitted Traffic '
   <draft-ietf-tsvwg-admitted-realtime-dscp-05.txt> as a Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action.  Please send substantive comments to the
[email-masked] mailing lists by 2008-11-27. Exceptionally, 
comments may be sent to [email-masked] instead. In either case, please 
retain the beginning of the Subject line to allow automated sorting.

This document have a normative reference to "Configuration Guidelines for
DiffServ Service Classes" RFC 4594 (Informational RFC) that this document
updates. There is no dependency from this document on RFC 4594, instead
the informative part in this document extend and changes the text in RFC
4594.

The file can be obtained via
http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-admitted-realtime-dscp-05.txt

IESG discussion can be tracked via
https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=15534&rfc_flag=0

---

From: Bob Briscoe <[email-masked]>
Date: Sun, 16 Nov 2008 15:25:31 +0000

Magnus, Fred, James, Martin,

I'm happy now.

I liked the bullets at the end of S.2.2 that define the minimum 
admission procedure that warrants use of this new codepoint. I 
especially like the one that says "If multiple polices are in use in 
a network, that the user is identified and the correct policy 
applied...". That satisfies my previous bugbear that it should be 
possible to use this admitted-voice class in business models that 
apply admission control but that don't need all the trappings to 
identify users, e.g. in jurisdictions where emergency services etc 
aren't required. Then, for instance, operaters could protect QoS with 
admission control, but charge users monthly in bulk for the volume of 
all admitted traffic, rather than all the complexity of identifying 
and charging users per session.

A few nits have crept in to the new text (in addition to the ones 
Magnus identified, which I had also noticed and agree with).

1.1 Definitions
PHB:
s/It may be thought of as a program ... specified drop probabilities .../
  /It may be thought of as a program ... specifying drop probabilities .../

2.2 Capacity Admission Control
s/The operator's choice of admission procedure must, for this DSCP, ensure.../
  /The operator's choice of admission procedure MUST, for this DSCP, ensure.../

(You may have deliberately not capitalised this, but it seems to me 
the nub of what makes this doc standards track?)

3. Summary: changes from RFC4594
s/... a ... Class is added which performs capacity admission dynamically/
  /... a ... Class is added which requires dynamic capacity admission 
to be performed/

Cheers

Bob

>https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=15534&rfc_flag=0

____________________________________________________________________________
Bob Briscoe, <[email-masked]>      Networks Research Centre, BT Research
B54/77 Adastral Park,Martlesham Heath,Ipswich,IP5 3RE,UK.    +44 1473 645196

---

From: Fred Baker <[email-masked]>
Date: Sun, 16 Nov 2008 19:10:12 -0600

I'm OK with these changes being done by the RFC Editor during the  
final processing, or I can pick them up in an update if someone prefers.

On Nov 16, 2008, at 9:25 AM, Bob Briscoe wrote:

> aren't required. Then, for instance, operaters could protect QoS  
> with admission control, but charge users monthly in bulk for the  
> volume of all admitted traffic, rather than all the complexity of  
> identifying and charging users per session.
>