Automatically Switched Optical Network (ASON) Routing for OSPFv2 Protocols
draft-ietf-ccamp-rfc5787bis-06
Yes
(Adrian Farrel)
No Objection
(Barry Leiba)
(Benoît Claise)
(Brian Haberman)
(Gonzalo Camarillo)
(Martin Stiemerling)
(Ralph Droms)
(Robert Sparks)
(Ron Bonica)
(Russ Housley)
(Sean Turner)
(Wesley Eddy)
Note: This ballot was opened for revision 06 and is now closed.
Adrian Farrel Former IESG member
Yes
Yes
()
Unknown
Barry Leiba Former IESG member
No Objection
No Objection
()
Unknown
Benoît Claise Former IESG member
No Objection
No Objection
()
Unknown
Brian Haberman Former IESG member
No Objection
No Objection
()
Unknown
Gonzalo Camarillo Former IESG member
No Objection
No Objection
()
Unknown
Martin Stiemerling Former IESG member
No Objection
No Objection
()
Unknown
Ralph Droms Former IESG member
No Objection
No Objection
()
Unknown
Robert Sparks Former IESG member
No Objection
No Objection
()
Unknown
Ron Bonica Former IESG member
No Objection
No Objection
()
Unknown
Russ Housley Former IESG member
No Objection
No Objection
()
Unknown
Sean Turner Former IESG member
No Objection
No Objection
()
Unknown
Stephen Farrell Former IESG member
(was Discuss)
No Objection
No Objection
(2012-10-24)
Unknown
- 6.1 says the router IDs SHOULD NOT be zero but I don't get when it'd be ok for zero to be used (just asking as its always good to say when going against a SHOULD NOT is fine). - I wondered if the combination of exporting routing information up, down and sideways, and dealing with not-quite overlapping ASON and OSPF hierarchical concepts might increase the probability of error here to the point where this draft ought say something about that. I don't know the answer, just asking. - Is the definition of looping in 7.2 appropriate? Why are only ASON-specific loops considered? Why not consider anything that causes a routing loop, regardless? - 7.2.1, 2nd last para, should that "must" be a "MUST" in "The RA ID value must be a unique identifier for the RA within the ASON routing domain." - I was surprised not to see the string "ASON" in any of the TLV names defined here. - Section 9, 2nd para: How can message authentication improve security against passive attacks? Seems plain wrong. Adding crypto for integrity/authenticaiton is purely to prevent/detect active attacks. My suggestion is to do s/secure against passive attacks and// - Section 9, 3rd para: Signatures do not by themselves provide stronger security than MACs. That all depends on key management and specific algorithms. I'd argue to just delete that paragraph.
Stewart Bryant Former IESG member
(was Discuss)
No Objection
No Objection
(2012-10-25)
Unknown
This is a well written document. Since the security of this mechanism is fundamentally associated with the security of OSPF, an informational reference to draft-ietf-karp-ospf-analysis would seem useful to the reader.
Wesley Eddy Former IESG member
No Objection
No Objection
()
Unknown