Skip to main content

A Differentiated Services Code Point (DSCP) for Capacity-Admitted Traffic
draft-ietf-tsvwg-admitted-realtime-dscp-07

Yes

(Magnus Westerlund)

No Objection

(Cullen Jennings)
(Dan Romascanu)
(Jari Arkko)
(Lars Eggert)
(Lisa Dusseault)
(Pasi Eronen)
(Ralph Droms)
(Ross Callon)
(Russ Housley)
(Tim Polk)

Note: This ballot was opened for revision 07 and is now closed.

Magnus Westerlund Former IESG member
Yes
Yes () Unknown

                            
Adrian Farrel Former IESG member
No Objection
No Objection (2009-12-15) Unknown
The Abstract says...

   ...for real-time traffic classes similar to voice...

A nit, but the traffic class is not similar to voice. The Introduction
says this much better. Any chance of polishing the Abstract?


---

Section 1.
Paragraph 3 begins...

   These applications...

Which applications? Is this paragraph intended to be attached to
paragraph 2, or is the whole context of paragraph 1 and paragraph 2
supposed to be applications rather than traffic classes?

The second sentence of the same paragraph reads...

   Reserving capacity for them is important to application performance.

I think you reserve capacity for traffic flows, not for applications?

---

Section 1.1

Do you have a reference for your definition of UNI? It doesn't seem to 
conform completely with the definition I am used to in transport 
networks withint the ITU-T. I think that the main issue I have is that
your definition implies that the use of a UNI indicates that the UNI-C
and UNI-N do not trust each other. Maybe just needs a tweak on the 
wording.

Should your NNI really be termed "E-NNI"?

---

Section 1.2

s/may not be present/might not be present/

---

Section 2.3 says...

   It is the belief of the authors that either PHB implementation

Is this not the work of the TSV Working Group with IETF consensus?
Can this please be rephrased. Either "It is believed that..." or
(preferably) a simple statement of fact.

---

e-911 is used as a term without explanation or reference.

---

Section 4
Rather obviously, you should ask IANA to asign from Pool 1
Alexey Melnikov Former IESG member
No Objection
No Objection (2009-12-13) Unknown
For a person not familiar with the underlying technology,
I found the Security Consideration section to be insufficiently detailed
about threats. While the list of threats seems to be adequate,
it would be useful to have some pointers to documents describing possible
remedies (for example how to achieve adequately strong proof of identity),
or a clear statement that the protocol doesn't provide such facility.
Cullen Jennings Former IESG member
(was Discuss) No Objection
No Objection () Unknown

                            
Dan Romascanu Former IESG member
(was Discuss) No Objection
No Objection () Unknown

                            
Jari Arkko Former IESG member
No Objection
No Objection () Unknown

                            
Lars Eggert Former IESG member
No Objection
No Objection () Unknown

                            
Lisa Dusseault Former IESG member
No Objection
No Objection () Unknown

                            
Pasi Eronen Former IESG member
No Objection
No Objection () Unknown

                            
Ralph Droms Former IESG member
No Objection
No Objection () Unknown

                            
Robert Sparks Former IESG member
No Objection
No Objection (2009-12-17) Unknown
Support Cullen's discuss (if the draft's intent was to specify the use of these mechanisms in those services. If that wasn't the intent, perhaps the motivation language could be edited to avoid the problem?)
Ron Bonica Former IESG member
No Objection
No Objection (2009-12-17) Unknown
I support Dan's DISCUSS.
Ross Callon Former IESG member
No Objection
No Objection () Unknown

                            
Russ Housley Former IESG member
No Objection
No Objection () Unknown

                            
Tim Polk Former IESG member
(was No Record, Discuss) No Objection
No Objection () Unknown