Traffic Engineering Extensions to OSPF Version 3
RFC 5329
Yes
No Objection
Note: This ballot was opened for revision 13 and is now closed.
Lars Eggert No Objection
(David Ward; former steering group member) Yes
(Jari Arkko; former steering group member) Yes
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
(Ross Callon; former steering group member) Yes
(Chris Newman; former steering group member) No Objection
(Cullen Jennings; former steering group member) No Objection
(Dan Romascanu; former steering group member) (was Discuss) No Objection
(Jon Peterson; former steering group member) No Objection
(Pasi Eronen; former steering group member) No Objection
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
(Russ Housley; former steering group member) No Objection
(Tim Polk; former steering group member) No Objection
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.