Skip to main content

Protocol Extensions for Support of Diffserv-aware MPLS Traffic Engineering
draft-ietf-tewg-diff-te-proto-08

Yes

(Bert Wijnen)

No Objection

(Alex Zinin)
(Bill Fenner)
(David Kessens)
(Jon Peterson)
(Margaret Cullen)
(Sam Hartman)
(Scott Hollenbeck)
(Steven Bellovin)
(Thomas Narten)

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

Bert Wijnen Former IESG member
Yes
Yes () Unknown

                            
Alex Zinin Former IESG member
(was Discuss) No Objection
No Objection () Unknown

                            
Allison Mankin Former IESG member
(was Discuss) No Objection
No Objection (2004-12-22) Unknown
The note which makes clear that this is not DiffServ awareness but something different
has cleared my Discuss.  Transport needs to continue to pay attention to this protocol.
Bill Fenner Former IESG member
No Objection
No Objection () Unknown

                            
David Kessens Former IESG member
No Objection
No Objection () Unknown

                            
Harald Alvestrand Former IESG member
No Objection
No Objection (2004-09-16) Unknown
Reviewed by Lucy Lynch, Gen-ART

Her review indicated a number of places in proto-07 where it was unclear whether the authors were intending 2119 keyword meaning (MUST) where the text said "must". Review forwarded to authors and AD.

HTA: Within my limited time and understanding, this seems sensible.

Philosophical sigh:
I distrust all numbers except 1, 2 and "many".
This document sanctifies the number 8.
I hope they know what they're doing.
Jon Peterson Former IESG member
No Objection
No Objection () Unknown

                            
Margaret Cullen Former IESG member
No Objection
No Objection () Unknown

                            
Russ Housley Former IESG member
(was Discuss) No Objection
No Objection (2004-04-13) Unknown
  -diff-te-mam-03 and -diff-te-mar-04 and -diff-te-russian-06 say that
  security considerations related to the use of DS-TE are discussed in
  draft-ietf-tewg-diff-te-proto-07.  However, the security considerations
  in this document points to RFC 2475, without adding much additional
  insight.  Please remove the additional level of indirection.
Sam Hartman Former IESG member
No Objection
No Objection () Unknown

                            
Scott Hollenbeck Former IESG member
(was Discuss) No Objection
No Objection () Unknown

                            
Steven Bellovin Former IESG member
No Objection
No Objection () Unknown

                            
Ted Hardie Former IESG member
No Objection
No Objection (2004-04-13) Unknown
Many of the <iana-note> sections are actually requests to the RFC editor to update
values upon assignment.  I don't think this requires any change to the document,
but I thought I'd note it so that the purpose was clear to our RFC Editor liaison.
Thomas Narten Former IESG member
(was Discuss) No Objection
No Objection () Unknown