Skip to main content

OSPFv3 Autoconfiguration
RFC 7503

Yes

(Alia Atlas)
(Ted Lemon)

No Objection

(Martin Stiemerling)
(Pete Resnick)
(Richard Barnes)
(Spencer Dawkins)

Recuse

(Jari Arkko)

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

(Adrian Farrel; former steering group member) (was Discuss) Yes

Yes (2015-02-11)
Thanks for addressing my copious concerns

(Alia Atlas; former steering group member) Yes

Yes (for -12)

                            

(Ted Lemon; former steering group member) Yes

Yes (for -13)

                            

(Alissa Cooper; former steering group member) No Objection

No Objection (2015-02-04 for -13)
= 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

No Objection (2015-01-26 for -12)
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

No Objection (2015-02-09 for -14)
Thanks for resolving my DISCUSS.

(Brian Haberman; former steering group member) No Objection

No Objection (2015-02-04 for -13)
I support Adrian's points.

(Joel Jaeggli; former steering group member) No Objection

No Objection (2015-02-05 for -13)
benoit's is worth addressing.

(Kathleen Moriarty; former steering group member) No Objection

No Objection (2015-02-03 for -13)
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

No Objection (for -13)

                            

(Pete Resnick; former steering group member) No Objection

No Objection (for -13)

                            

(Richard Barnes; former steering group member) No Objection

No Objection (for -13)

                            

(Spencer Dawkins; former steering group member) No Objection

No Objection (for -13)

                            

(Stephen Farrell; former steering group member) No Objection

No Objection (2015-02-03 for -13)

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

Recuse (for -12)