Traffic Engineering Extensions to OSPF Version 3
RFC 5329

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

Lars Eggert No Objection

(David Ward; former steering group member) Yes

Yes ( for -)
No email
send info

(Jari Arkko; former steering group member) Yes

Yes (2008-06-03 for -)
No email
send info
Section 3 does not specify what type of IPv6 address is legal or
illegal for the TLV defined in there. Other TLV definitions in this
document do that. Worth adding the same statement here about
link-local addresses not being legal?

(Mark Townsley; former steering group member) Yes

Yes ( for -)
No email
send info

(Ross Callon; former steering group member) Yes

Yes ( for -)
No email
send info

(Chris Newman; former steering group member) No Objection

No Objection ( for -)
No email
send info

(Cullen Jennings; former steering group member) No Objection

No Objection ( for -)
No email
send info

(Dan Romascanu; former steering group member) (was Discuss) No Objection

No Objection ()
No email
send info

(Jon Peterson; former steering group member) No Objection

No Objection ( for -)
No email
send info

(Pasi Eronen; former steering group member) No Objection

No Objection (2008-06-04 for -)
No email
send info
Section 4:
> All other sub-TLVs defined in this document MAY occur at 
> most once in a Link TLV.

RFC 2119 "MAY" means something that is optional (you can decide
not to do it). Probably "MUST NOT occur more than once" is meant 
here.

Reference [OSPFV3] should point to draft-ietf-ospf-ospfv3-update
instead of RFC 2740?

(Ron Bonica; former steering group member) No Objection

No Objection ( for -)
No email
send info

(Russ Housley; former steering group member) No Objection

No Objection ( for -)
No email
send info

(Tim Polk; former steering group member) No Objection

No Objection (2008-06-04 for -)
No email
send info
Rob Austein's secdir review noted two issues that really should get addressed.

(1) The ASCII art describing the OSPFv3 Intra-Area-TE-LSA does not match
  the text.  The text looks reasonable, but the ASCII art appears to
  have the U and S2 bits of the LSA type field swapped -- should be
  "|1|0|1|", not "|0|1|1|".

(2) The security considerations correctly points out that the security
  considerations from the base OSPFv3 protocol apply, but do not
  mention that the security considerations from the base traffic
  engineering extensions specification (RFC 3630) also apply.  Please
  add a reference to [TE] in the security considerations section.