Skip to main content

Traffic Engineering Extensions to OSPF Version 3
draft-ietf-ospf-ospfv3-traffic-13

Yes

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

No Objection

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

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

David Ward Former IESG member
Yes
Yes () Unknown

                            
Jari Arkko Former IESG member
Yes
Yes (2008-06-03) Unknown
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 IESG member
Yes
Yes () Unknown

                            
Ross Callon Former IESG member
Yes
Yes () Unknown

                            
Chris Newman Former IESG member
No Objection
No Objection () Unknown

                            
Cullen Jennings Former IESG member
No Objection
No Objection () Unknown

                            
Dan Romascanu Former IESG member
(was Discuss) No Objection
No Objection () Unknown

                            
Jon Peterson Former IESG member
No Objection
No Objection () Unknown

                            
Lars Eggert Former IESG member
No Objection
No Objection () Unknown

                            
Pasi Eronen Former IESG member
No Objection
No Objection (2008-06-04) Unknown
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 IESG member
No Objection
No Objection () Unknown

                            
Russ Housley Former IESG member
No Objection
No Objection () Unknown

                            
Tim Polk Former IESG member
No Objection
No Objection (2008-06-04) Unknown
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.