OSPFv3 Autoconfiguration
RFC 7503

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

(Alia Atlas) Yes

(Adrian Farrel) (was Discuss) Yes

Comment (2015-02-11)
No email
send info
Thanks for addressing my copious concerns

(Ted Lemon) Yes

(Richard Barnes) No Objection

(Benoît Claise) (was Discuss) No Objection

Comment (2015-02-09 for -14)
No email
send info
Thanks for resolving my DISCUSS.

Alissa Cooper No Objection

Comment (2015-02-04 for -13)
No email
send info
= 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.

(Spencer Dawkins) No Objection

(Stephen Farrell) No Objection

Comment (2015-02-03 for -13)
No email
send info

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.

(Brian Haberman) No Objection

Comment (2015-02-04 for -13)
No email
send info
I support Adrian's points.

(Joel Jaeggli) No Objection

Comment (2015-02-05 for -13)
No email
send info
benoit's is worth addressing.

Barry Leiba No Objection

Comment (2015-01-26 for -12)
No email
send info
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.

(Kathleen Moriarty) No Objection

Comment (2015-02-03 for -13)
No email
send info
Thanks for addressing the SecDir review.
https://www.ietf.org/mail-archive/web/secdir/current/msg05391.html

I support Stephen's comments as well.

(Pete Resnick) No Objection

(Martin Stiemerling) No Objection

(Jari Arkko) Recuse