Skip to main content

OSPFv3 Autoconfiguration
draft-ietf-ospf-ospfv3-autoconfig-15

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 IESG member
(was Discuss) Yes
Yes (2015-02-11) Unknown
Thanks for addressing my copious concerns
Alia Atlas Former IESG member
Yes
Yes (for -12) Unknown

                            
Ted Lemon Former IESG member
Yes
Yes (for -13) Unknown

                            
Alissa Cooper Former IESG member
No Objection
No Objection (2015-02-04 for -13) Unknown
= 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 IESG member
No Objection
No Objection (2015-01-26 for -12) Unknown
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 IESG member
(was Discuss) No Objection
No Objection (2015-02-09 for -14) Unknown
Thanks for resolving my DISCUSS.
Brian Haberman Former IESG member
No Objection
No Objection (2015-02-04 for -13) Unknown
I support Adrian's points.
Joel Jaeggli Former IESG member
No Objection
No Objection (2015-02-05 for -13) Unknown
benoit's is worth addressing.
Kathleen Moriarty Former IESG member
No Objection
No Objection (2015-02-03 for -13) Unknown
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 IESG member
No Objection
No Objection (for -13) Unknown

                            
Pete Resnick Former IESG member
No Objection
No Objection (for -13) Unknown

                            
Richard Barnes Former IESG member
No Objection
No Objection (for -13) Unknown

                            
Spencer Dawkins Former IESG member
No Objection
No Objection (for -13) Unknown

                            
Stephen Farrell Former IESG member
No Objection
No Objection (2015-02-03 for -13) Unknown

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 IESG member
Recuse
Recuse (for -12) Unknown