Protocol Extensions for Support of Diffserv-aware MPLS Traffic Engineering
Note: This ballot was opened for revision 08 and is now closed.
(Bert Wijnen) Yes
(Harald Alvestrand) No Objection
Comment (2004-09-16 for -)
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.
(Steven Bellovin) No Objection
(Margaret Cullen) No Objection
(Bill Fenner) No Objection
(Ted Hardie) No Objection
Comment (2004-04-13 for -)
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.
(Sam Hartman) No Objection
(Scott Hollenbeck) (was Discuss) No Objection
(Russ Housley) (was Discuss) No Objection
-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.
(David Kessens) No Objection
(Allison Mankin) (was Discuss) No Objection
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.