Re: [Emu] [Gen-art] Genart last call review of draft-ietf-emu-rfc5448bis-06

Jari Arkko <jari.arkko@piuha.net> Mon, 09 March 2020 12:28 UTC

Return-Path: <jari.arkko@piuha.net>
X-Original-To: emu@ietfa.amsl.com
Delivered-To: emu@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4179F3A0E9F; Mon, 9 Mar 2020 05:28:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vgSW9uMOjXyu; Mon, 9 Mar 2020 05:28:05 -0700 (PDT)
Received: from p130.piuha.net (p130.piuha.net [IPv6:2001:14b8:1829::130]) by ietfa.amsl.com (Postfix) with ESMTP id E6BD93A0E97; Mon, 9 Mar 2020 05:28:04 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id D9803660130; Mon, 9 Mar 2020 14:28:03 +0200 (EET)
Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gmPcO_rVQtQq; Mon, 9 Mar 2020 14:28:02 +0200 (EET)
Received: from [127.0.0.1] (p130.piuha.net [IPv6:2001:14b8:1829::130]) by p130.piuha.net (Postfix) with ESMTPS id D944F66012C; Mon, 9 Mar 2020 14:28:02 +0200 (EET)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
From: Jari Arkko <jari.arkko@piuha.net>
In-Reply-To: <157994710010.26892.94839866352802954@ietfa.amsl.com>
Date: Mon, 09 Mar 2020 14:28:02 +0200
Cc: gen-art@ietf.org, last-call@ietf.org, draft-ietf-emu-rfc5448bis.all@ietf.org, emu@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <54CD762A-D555-4BAC-9927-F9D3D02F095F@piuha.net>
References: <157994710010.26892.94839866352802954@ietfa.amsl.com>
To: Dan Romascanu <dromasca@gmail.com>
X-Mailer: Apple Mail (2.3273)
Archived-At: <https://mailarchive.ietf.org/arch/msg/emu/NODFdcVIVnfFG-0glESqi5fugoQ>
Subject: Re: [Emu] [Gen-art] Genart last call review of draft-ietf-emu-rfc5448bis-06
X-BeenThere: emu@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "EAP Methods Update \(EMU\)" <emu.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/emu>, <mailto:emu-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/emu/>
List-Post: <mailto:emu@ietf.org>
List-Help: <mailto:emu-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/emu>, <mailto:emu-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 09 Mar 2020 12:28:18 -0000

Thanks for your review, Dan.

Some responses below. We are also about to publish a new document version.

> This is a very detailed and well-written document that describes a new
> specification of the specification of EAP-AKA' to support 5G deployments. This
> specification is ready, but I have a concern about the relationship to the 3GPP
> specifications that I would suggest to be clarified by the authors and
> considered by the IESG.
> 
> Major issues:
> 
> 1. The document includes the following statements related to the 5G and 3GPP
> relevant specifications:
> 
> In the Abstract:
> 
>> This version of EAP-AKA' specification specifies the protocol
>   behaviour for 5G deployments as well.
> 
> In Section 1:
> 
>> Note: This specification refers only to the 5G specifications.
>      Any further update that affects, for instance, key derivation is
>      something that EAP-AKA' implementations should take into account.
>      Upon such updates there will be a need to both update the
>      specification and the implementations.
> 
> The first quoted text seems to indicate that the specification refers to 5G and
> other deployments. The second quoted text seems to indicate that the
> specification refers only to 5G. The two statements seem to be contradictory.

The text in the draft is confusing and wrong. But the actual situation is that the draft refers to both 4G and 5G specifications and to the best of our knowledge applies to both.
 
The text has been clarified in -07.

> 2. The References sections (both Normative and Informative) include a note that
> advises the RFC Editor to ...
> 
> Editors, "All 3GPP references should be updated to the
>              latest Release 15 version before publishing.".
> 
> Is this sufficient? I mean is this a pure editorial task for updating the
> references? Are the authors certain that none of the changes between now and
> the publication of the 3GPP latest releases will not impact this document? I am
> a little nervous about relying on a set of 5G-related work which is still in
> evolution. Maybe a technical pass by the authors is desirable before
> publication?

Rel-15 documents are pretty stable now :-) We need to make the final references point to the right versions, however. We believe we’ve done that in -07.

> Minor issues:
> 
> Nits/editorial comments:
> 
> Appendix B.  Changes from RFC 4187 to RFC 5448 is a copy-paste of Appendix A in
> RFC 5448. Was this necessary? In any case, it would probably be better to avoid
> any ambiguity by replacing in the second sentence 'this document' by 'RFC 5448’.

We believe the document still needs to describe the changes to RFC 4187 because going forward this new RFC will be the main reference to both EAP-AKA’ and what updates were also made in EAP-AKA. However, that section is and was in RFC 5448 very misleading. It talks about what has been added to EAP-AKA, but without being clear about that.
 
The text has been corrected and clarified in -07.

Jari