Traffic Engineering Extensions to OSPF Version 3
RFC 5329

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

(Jari Arkko) Yes

Comment (2008-06-03 for -** No value found for 'p.get_dochistory.rev' **)
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?

(Ross Callon) Yes

(Mark Townsley) Yes

(David Ward) Yes

(Ron Bonica) No Objection

(Lars Eggert) No Objection

(Pasi Eronen) No Objection

Comment (2008-06-04 for -** No value found for 'p.get_dochistory.rev' **)
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?

(Russ Housley) No Objection

(Cullen Jennings) No Objection

(Chris Newman) No Objection

(Jon Peterson) No Objection

(Tim Polk) No Objection

Comment (2008-06-04 for -** No value found for 'p.get_dochistory.rev' **)
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.

(Dan Romascanu) (was Discuss) No Objection