The eap.arpa. domain and EAP provisioning
draft-ietf-emu-eap-arpa-10

Many thanks to Ben Kaduk for their secdir review and follow up. 

Informative References:  FYI... RFC 4210 has been obsoleted by RFC 9810 (https://datatracker.ietf.org/doc/rfc9810/)

# Internet AD comments for draft-ietf-emu-eap-arpa-09
CC @ekline

* comment syntax:
  - https://github.com/mnot/ietf-comments/blob/main/format.md

* "Handling Ballot Positions":
  - https://ietf.org/about/groups/iesg/statements/handling-ballot-positions/

### S3.2

* "ietf.org" realm is used -> "ietf.org" domain is used

  I read "ietf.org" as the _domain_ that becomes part of the _realm_ per
  the example you give at the end of the sentence.

Thank you for the work that you have put into this document. 

The only transoport related topic I found was that peers MUST
rate-limit their provisioning attempts, which is already covered in
the current document. From a transport perspective, I have no
additional comments.

Consider introducing the term/abbreviation NAI in Sections 1 or 2. It's expanded in the abstract and used in the definition of EPI (Section 2) with an appropriate reference (thank you!), but the abbreviation isn't expanded in the main text until Section 3.

Section 3.2, it seems strange to scope "experimental" use to ietf.org. Experiments happen other places, too. Perhaps instead say that experiments should happen exclusively within an appropriate vendor space, and "*.ietf.org.v.eap.arpa" can be used for draft version of documents in an IETF working group?

Only need to expand EPI once -- it's not necessary to re-introduce the abbreviation in each section.

Section 4 seems like it would be more useful folded into the Introduction, or perhaps as an Appendix if you feel it's too long for that.

In Section 5.2, I would appreciate an informative reference for "802.11u NAI realm". Also, is it sufficient to advertise the entire universe of possible NAI realms when what's supported is specifically "portal@tls.eap.arpa"? Is it possible to make a more specific advertisement with that mechanism, and if so, why wouldn't we recommend that?

=== NITS FOLLOW ===

3.4: Period at end of sentence
3.4.1: "is no ... issues" => "is no ... issue" or "are no ... issues"
3.4.2: "actoer" => "actors"?
5.1: ". ." => "." and don't put commas around the parentheses
6: "number IANA" => "number of IANA"
8: delete comma after "registry"

Hi Alan,

Thank you for the effort put into this specification. Appreciate the detailed operational considerations discussed through the document. 

Please find below some few comments: 

# Abstract

CURRENT:
   This document also updates RFC9140 to deprecate "eap-
   noob.arpa", and replace it with "noob@eap.arpa"

* There is no noob@eap.arpa mention in the document. Should this be changed to “eap.arpa”?

* Alternatively, given that RFC9140 reasons also with noob@eap-noob.arpa, should this text mention “@noob.eap.arpa"

# STD13 vs RFC1034

CURRENT:
   The subdomain MUST follow the syntax
   defined in [RFC7542], Section 2.2, which is a more restrictive subset
   of the domain name conventions specified in RFC1034.
   ..

   However, that registry does
   not follow the domain name conventions specified in RFC1034, so it is
   not possible to make a "one-to-one" mapping between the Method Type
   name and the subdomain.

I suggest to replace all occurrences of RFC1034 with [STD13]

# Experimental Use

CURRENT:
   For experimental uses, it is RECOMMENDED that the "ietf.org" realm is
   used.  Different uses SHOULD be distinguished by using the name of a
   working group or document, such as "emu.ietf.org.v.eap.arpa".

Why is this restricted to WGs? Couldn’t other experiment forms be considered beyond the IETF or you think that those can be covered by use of a vendor subdomain?

# Inappropriate use of normative language

OLD: Other EAP methods MAY omit the username as RECOMMENDED in [RFC7542].
NEW: Other EAP methods MAY omit the username as recommended in [RFC7542].

The reco is already covered in 7542.

# Field

CURRENT:
   result, the EAP peer MUST NOT have a field which lets the user
   identifier field be configured directly.  

Nots sure what “field” means here. I suspect that you meant configuration knob or something similar. If so, you can consider this change:

NEW:
   result, the EAP peer MUST NOT expose a configuration option which lets the user
   identifier field be configured directly.  

# Why this is not “MUST NOT”?

CURRENT:
   While EAP peers allow users to enter user identifiers directly for
   existing EAP methods, they SHOULD NOT check whether those identifiers
   match any EPI.  

# Redundant behavior 

Section 3.4.1 has the following:
   EAP peers MUST rate limit attempts at
   provisioning, in order to avoid overloading the server. 

Section 3.4.2 says:
   Peers MUST rate-limit their provisioning attempts.  

Please consider keeping this in 3.4.1 only. Pleas note that 3.4.2 is about servers.

# Unspecified behavior in Section 3.4.1

CURRENT:
   This rate
   limiting SHOULD include jitter and exponential backoff.

This text does not explicit how these parameters are defined/used to avoid overload. I see that Section 3.4.2 zooms into this: 

   The peer SHOULD retry provisioning no more than once
   every few minutes, and SHOULD perform exponential back-off on its
   provisioning attempts.

I think that it is better to move para to be under 3.4.1 as this is about peers behavior and also answers some of the questions triggered by the current 3.4.1 text: 

   Peers MUST rate-limit their provisioning attempts.  If provisioning
   fails, it is likely because provisioning is not available.  Retrying
   provisioning repeatedly in quick succession is not likely to change
   the server behavior.  Instead, it is likely to result in the peer
   being blocked.  The peer SHOULD retry provisioning no more than once
   every few minutes, and SHOULD perform exponential back-off on its
   provisioning attempts.

# General network access?!

CURRENT:
   The limited
   network MUST NOT permit general network access.  

I guess I understand what is meant here, maybe “unrestricted network access” is more explicit about the intent.

# Redundant behavior in Section 3.5

CURRENT:
   Implementations MUST NOT permit EAP method negotiation with
   provisioning credentials.  That is, when an EPI is used, any EAP Nak
   sent by a server MUST contain only EAP method zero (0).  

These are the same requirement. The second MUST is an explanation of the MUST NOT. Please fix this:

NEW:
   Implementations MUST NOT permit EAP method negotiation with
   provisioning credentials.  That is, when an EPI is used, any EAP Nak
   sent by a server must contain only EAP method zero (0).  

# Background and rationale

This section is very useful but too late in the document. Please consider adding a pointer to this section early in the document.

Cheers,
Med

Thank you to Ines Robles for the GENART review.

Thank you for addressing my DISCUSS and COMMENT feedback.