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

From: Jari Arkko <[email-masked]>
Date: Mon, 9 Mar 2020 14:28:02 +0200

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

---

From: Dan Romascanu <[email-masked]>
Date: Mon, 9 Mar 2020 17:23:19 +0200

Hi Jari,

Thank you for the answer and for addressing the issues raised in my review.
Looks fine to me by now, I am waiting for version -07 to check the precise
edits.

Regards,

Dan

On Mon, Mar 9, 2020 at 2:28 PM Jari Arkko <[email-masked]> wrote:

> 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.
>
> 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:
> >
> 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.
>