Skip to main content

Traffic Engineering Extensions to OSPF Version 3
RFC 5329

Yes

(David Ward)
(Mark Townsley)
(Ross Callon)

No Objection

Lars Eggert
(Chris Newman)
(Cullen Jennings)
(Dan Romascanu)
(Jon Peterson)
(Ron Bonica)
(Russ Housley)

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

Lars Eggert No Objection

(David Ward; former steering group member) Yes

Yes ()

                            

(Jari Arkko; former steering group member) Yes

Yes (2008-06-03)
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 ()

                            

(Ross Callon; former steering group member) Yes

Yes ()

                            

(Chris Newman; former steering group member) No Objection

No Objection ()

                            

(Cullen Jennings; former steering group member) No Objection

No Objection ()

                            

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

No Objection ()

                            

(Jon Peterson; former steering group member) No Objection

No Objection ()

                            

(Pasi Eronen; former steering group member) No Objection

No Objection (2008-06-04)
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 ()

                            

(Russ Housley; former steering group member) No Objection

No Objection ()

                            

(Tim Polk; former steering group member) No Objection

No Objection (2008-06-04)
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.