OSPFv2 Multi-Instance Extensions
RFC 6549
Yes
No Objection
Note: This ballot was opened for revision 09 and is now closed.
(Adrian Farrel; former steering group member) (was Discuss) Yes
I have a few additional Comments that I think would improved the document and I hope you will consider incorporating them into a new revision. --- The Abstract is very dense. Nothing wrong with what you have written, but it's quite hard work. How about... OSPFv3 includes a mechanism to support multiple instances of the protocol running on the same interface. OSPFv2 can utilise such a mechanism in order to support multiple routing domains on the same subnet. This document defines the OSPFv2 instance ID to enable separate OSPFv2 protocol instances on the same interface. Unlike OSPFv3 where te instance ID can be used for multiple purposes, such as putting the same interface in multiple areas, the OSPFv2 instnce ID is reserved for identifying protocol instances. This document updates RFC 2328. Note that I have left out of the Abstract the statementabout how a different funciton is supported by a diffenent protocol extension defined in a different document! --- You are inconsistent about whether to say "OSPF" or "OSPFv2" when refering to OSPFv2. Given that you keep comparing to OSPFv3, I think it would be helful to always say "OSPFv2". --- You use phrases such as "OSPFv2 currently doesn't offer" which are, of course, correct before this becomes an RFC, whereupon they become wrong. If you can avoid this sortof thing by saying "This document defines..." then the draft is future-proofed. --- Can you please replace the future tense with the present tense. For example, Section 3 OSPF [OSPFV2] describes the conceptual interface data structure in section 9. The OSPF Interface Instance ID will be added to this structure. The OSPF Interface Instance ID will default to 0. --- Section 3.1 When sending OSPF packets, if the OSPF Interface Instance ID has a non-zero value, it will be set in the OSPF packet header. Surely the zero value is also set in the packet header. That is, the field is not left uninitialised.
(Jari Arkko; former steering group member) Yes
(Stewart Bryant; former steering group member) Yes
(Dan Romascanu; former steering group member) (was Discuss) No Objection
(Gonzalo Camarillo; former steering group member) No Objection
(Pete Resnick; former steering group member) No Objection
(Peter Saint-Andre; former steering group member) No Objection
Although the authors appear to have documented the interoperability implications of reducing the AuType field from 2 octets to 1 octet, that still feels like a hack to me. However, I lack the context to judge whether the implications have been fully understood or documented. (Note also that this issue is not even mentioned in the shepherd writeup!)
(Ralph Droms; former steering group member) No Objection
(Robert Sparks; former steering group member) No Objection
The abstract (identical to the introduction except for references) doesn't actually describe what this document does.
(Ron Bonica; former steering group member) No Objection
I agree whole-heartedly with Adrian's Discuss regarding redefining fields from another RFC rather than referencing them.
(Russ Housley; former steering group member) No Objection
(Sean Turner; former steering group member) No Objection
I'm with Peter on this draft - I too lack the background and ultimately trust that the AD is doing the right. But, I am curious why this wouldn't be a version # change especially if it affects all implementations.
(Stephen Farrell; former steering group member) No Objection
Yep, I agree with all the "what a hack" comments. OTOH, I do agree that its not likely that a 256th auth type will be needed here. I also agree that the abstract is very unclear and should be rewritten.
(Wesley Eddy; former steering group member) No Objection