Re: [IPsec] WGLC for draft-ietf-ipsecme-ikev1-algo-to-historic

Hi,

I think document is mostly ready. Few observations:

- FWIW I think that Dan's efforts to make draft's language less speculative and more concrete 
   are valid and should be reflected in the document. 

- Is it OK that the intended status is Standards Track? Shouldn't it be BCP?

- The draft states that it updates RFC 7296, 8221, 8247. What in particular is being updated?
   I believe the recent IESG directives require a short explanation of what is being updated
   to be present in Abstract. In any case, it should be clearly indicated in the body of the document.
   Have I missed it?

- Section3: I think that phrase "IKEv2 is a more secure protocol than IKEv1 in every aspect." is a bit too vague.
  I believe it's better to list security aspects where we believe IKEv2 is superior:

  * IKEv2 supports modern cryptographic primitives, including AEAD ciphers
  * IKEv2 provides real defense against DoS (cookies, core spec) and DDoS (puzzles, RFC 8019) attacks
  * support for post-quantum crypto in IKEv2 is being developed (draft-ietf-ipsecme-ikev2-multiple-ke)
  * IKEv2 supports various authentication methods via integration with EAP (core spec)
  * an extension that allows build PAKE methods in IKEv2 exists (RFC 6467)
  * did I forget something?

- Section 4.3. Formally RFC 6407 is not directly concerned with IKEv1.
   This is an independent protocol developed by msec WG that was based on IKEv1.
   I think more accurate language should be used to make this clear. For example:

       Group Domain of Interpretation (GDOI, RFC 6407) protocol based on IKEv1
       defines the support for Multicast Group SAs.

   I also think that reference to RFC 3740 should be remove (it doesn't even mention IKE
   in any substantial way). I'm not so sure about RFC 5374, but I'm inclining 
   to remove it too - it's mostly concerned with MCAS architecture and doesn't
   define any concrete IKEv1 changes to support it. So, leave only RFC 6407.

- Section 5 lists deprecated algorithms. In my reading this list
   is inconsistent with Section 7 (IANA Considerations) which lists
   many more deprecated algorithms... So, I'm a bit puzzled
   how to read this section.

- The draft currently has all its references as Normative.
   I have no problems with this (except that RFC 3740 is Informational,
   so should not be referenced as Normative in Standards Track and BCP documents,
   but I suggested to remove it anyway). My concern is that 
   referencing active drafts as Normative will lead to slow down
   publication of this document until those drafts are published.
   I don't think it's a major problem (we will have an incentive 
   to work harder on these drafts :-)), just should be noted.

Regards,
Valery.

> Hi, all.
> 
> Although this draft is really new, having been submitted in April of this year, its predecessor draft has been
> under discussion since March of 2019.
> 
> This begins a 2-week WGLC. Please read the draft and post comments to the list. Since this is rather new,
> short messages in the vein of “Yeah, this is good. Ship it”, but substantive comments are, of course, even
> more welcome.
> 
> The WGLC ends at EOD (for me) July 12th, just a week before the IETF meeting.
> 
> Thanks
> 
> _______________________________________________
> IPsec mailing list
> IPsec@ietf.org
> https://www.ietf.org/mailman/listinfo/ipsec