OSPFv3 Autoconfiguration
RFC 7503
Yes
No Objection
Recuse
Note: This ballot was opened for revision 12 and is now closed.
(Adrian Farrel; former steering group member) (was Discuss) Yes
Thanks for addressing my copious concerns
(Alia Atlas; former steering group member) Yes
(Ted Lemon; former steering group member) Yes
(Alissa Cooper; former steering group member) No Objection
= Section 1 = "OSPFv3 [OSPFV3] is a candidate for deployments in environments where auto-configuration is a requirement. Its operation is largely unchanged from the base OSPFv3 protocol specification [OSPFV3]." The use of "its" here doesn't make a lot of sense -- a plain reading of this is that OSPFv3 is unchanged from OSPFv3.
(Barry Leiba; former steering group member) No Objection
I'll note that the RFC Editor will move Section 1.2 to the end. If there's a reason you don't want that, you should let them know. -- Section 10 -- This specification also creates a registry for OSPFv3 Auto- Configuration (AC) LSA TLVs. This registry should be placed in the existing OSPFv3 IANA registry, and new values can be allocated via IETF Consensus or IESG Approval. The current term is "IETF Review" (not "IETF Consensus"), and you should have a normative reference to RFC 5226 here. It would also be good to say when IESG Approval is an appropriate alternative to IETF Review.
(Benoît Claise; former steering group member) (was Discuss) No Objection
Thanks for resolving my DISCUSS.
(Brian Haberman; former steering group member) No Objection
I support Adrian's points.
(Joel Jaeggli; former steering group member) No Objection
benoit's is worth addressing.
(Kathleen Moriarty; former steering group member) No Objection
Thanks for addressing the SecDir review. https://www.ietf.org/mail-archive/web/secdir/current/msg05391.html I support Stephen's comments as well.
(Martin Stiemerling; former steering group member) No Objection
(Pete Resnick; former steering group member) No Objection
(Richard Barnes; former steering group member) No Objection
(Spencer Dawkins; former steering group member) No Objection
(Stephen Farrell; former steering group member) No Objection
Thanks for including section 4 - I was wondering if you would before I read this:-) - section 4: just saying "password" is likely to lead to password == password or password == 123456. Why not advise that a long higher entropy secret needs to be used? - section 4: I hate to do this to you, but if by saying "password" you also mean "entered by a human and likely a human memorable secret" then aren't there i18n considerations? Non-ascii characters in there are otherwise likely to lead to a lack of interop. If you wanted my advice as to how to avoid that, I'd go for RECOMMENDING that the secret be entered as ascii-hex digits and that 32 such digits be used if possible. - section 8: What "stronger" auth trailer do you mean in the last para? The weakness is that a password is used - the rest (e.g. hmac-sha-256 vs. hmac-sha-1) is in the noise. Maybe re-phrase.
(Jari Arkko; former steering group member) Recuse