Subject: [IPsec] Barry Leiba's Discuss on draft-ietf-ipsecme-ikev2-null-auth-06: (with DISCUSS and COMMENT)

From: "Barry Leiba" <[email-masked]>
Date: Thu, 21 May 2015 11:35:27 -0700

Barry Leiba has entered the following ballot position for
draft-ietf-ipsecme-ikev2-null-auth-06: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-ipsecme-ikev2-null-auth/

----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

First: Thanks, Paul, for a very informative and useful shepherd writeup.

I have no problem with the reference to Experimental RFC 5739, but I do
have a problem with the downref not having been noted in the last call
announcement, as required by RFC 3967 (BCP 97).  And I think the MUST in
the last paragraph of Section 2.5 requires 5739 to be normative.  I hate
to say this, but I think this requires a second last call on this
document, which will really serve no one.  We really do need to do an
update to BCP 97 to fix this, because it comes up all the time.

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Editorial comment in Section 2:

   If a peer
   that requires authentication receives an AUTH payload containing the
   NULL Authentication method type, it MUST return an
   AUTHENTICATION_FAILED notification.

We're referring to NULL authentication as "authentication", so maybe this
should say something like "If a peer that requires positive
identification receives [...]", or "If a peer that requires authenticated
identity receives [...]" ?

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 21 May 2015 11:45:30 -0700

> First: Thanks, Paul, for a very informative and useful shepherd writeup.

...but then...

> update to BCP 97 to fix this, because it comes up all the time.

If the IESG wants to fix BCP 97, that's grand. Do note in the "very informative and useful shepherd writeup", it says:

If this becomes too much of an issue for the
purists, the reference can be moved to the Informative References section, but it is more
appropriate as a normative reference.

I really meant that. Instead of wasting everyone's time with another IETF LC, please strongly consider changing the DISCUSS to "yes, you need to move that reference to the Informational References" section.

--Paul Hoffman

---

From: Barry Leiba <[email-masked]>
Date: Thu, 21 May 2015 14:58:19 -0400

> If the IESG wants to fix BCP 97, that's grand. Do note in the "very
> informative and useful shepherd writeup", it says:
>
> I really meant that. Instead of wasting everyone's time with another
> IETF LC, please strongly consider changing the DISCUSS to "yes, you
> need to move that reference to the Informational References" section.

The problem is that Section 2.5 says that you MUST do what's in 5739,
so I think 5739 has to be normative.  And, while I do think a second
last call is silly, it doesn't really waste must of anyone's time, and
only delays the document by a week or two, depending upon when
Kathleen is able to start the second last call.

I think the best thing is just to start a second last call tout de
suite, which notes the downref and asks for comments only on that
point.  And then we've done the right thing with respect to BCP 97.
(And meanwhile, I'll scare up an author for an update to BCP 97,
because I, too, am tired of this silliness.)

Barry

Barry

---

From: Kathleen Moriarty <[email-masked]>
Date: Thu, 21 May 2015 16:24:33 -0400

If it's decided to put this draft back into last call, I can do this in the
next couple of hours, but then will be on an overnight flight and will be
without much access until tomorrow afternoon US eastern time.

Thanks,
Kathleen

-- 

Best regards,
Kathleen