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:
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
At 16:54 13/11/2008, The IESG wrote:
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
ietf(_at_)ietf(_dot_)org mailing lists by 2008-11-27. Exceptionally,
comments may be sent to iesg(_at_)ietf(_dot_)org 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
____________________________________________________________________________
Bob Briscoe, <bob(_dot_)briscoe(_at_)bt(_dot_)com> Networks Research Centre, BT
Research
B54/77 Adastral Park,Martlesham Heath,Ipswich,IP5 3RE,UK. +44
1473 645196
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf