[Emu] Éric Vyncke's Discuss on draft-ietf-emu-eap-arpa-08: (with DISCUSS and COMMENT)

[Éric Vyncke via Datatracker <[e-mail]>]

Éric Vyncke has entered the following ballot position for
draft-ietf-emu-eap-arpa-08: 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/about/groups/iesg/statements/handling-ballot-positions/ 
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-emu-eap-arpa/



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


# Éric Vyncke, INT AD, comments for draft-ietf-emu-eap-arpa-08
CC @evyncke

Thank you for the work put into this document. Even with my DISCUSS ballot, I
really like the idea.

Please find below two blocking DISCUSS points (trivial to address), some
non-blocking COMMENT points/nits (replies would be appreciated even if only for
my own education).

Special thanks to Peter Yee for the shepherd's detailed write-up including the
WG consensus *and* the justification of the intended status.

I hope that this review helps to improve the document,

Regards,

-éric

## DISCUSS (blocking)

As noted in
https://datatracker.ietf.org/doc/statement-iesg-handling-ballot-positions-20220121/,
a DISCUSS ballot is a request to have a discussion on the points below; I
really think that the document would be improved with a change here, but can be
convinced otherwise.

### Abstract

As flagged by id-nits, when a document updates others, it must also mention
them in the abstract (bonus with concise description about what is updated).

### Section 3.7

Please use a MUST NOT in `names in the "eap.arpa" domain SHOULD NOT be looked
up in DNS`. Of course, existing implementations won't implement the MUST NOT
but a SHOULD would allow cheap implementation to hammer the DNS.


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


## COMMENTS (non-blocking)

### Title

s/The eap.arpa domain and EAP provisioning/The eap.arpa. domain and EAP
provisioning/ (trailing dot after a FQDN). The RFC editor will have the final
say.

### Section 1

s/EAP peer have pre-provisioned credentials/EAP peer*s* have pre-provisioned
credentials/

### Section 3

Please always add a trailing dot to all FQDN in an I-D, this happens several
times and has been noted bu the DNS directorate review.

Who is the "we" in `We note that this specification`? The author ? The WG ? The
IETF ? Let's be clear ;-) Also in other sections, e.g., 3.4.

### Section 3.2

Please add an informative reference to `IANA Extensible Authentication Protocol
(EAP) Registry`

About the RECOMMENDED and SHOULD in `It is RECOMMENDED that the first
subdomain` and `realm registry SHOULD be similar enough` why not using "SHOULD"
and "MUST" ?  If the terms are kept unchanged, then an explanation must be
stated when the SHOULD can bypassed.

In addition to "v" for vendor, should there be one for private or experimental ?

### Section 3.4.2

What is `malformed EPI` ? Should examples be given (e.g., not matching the IANA
registries) ?

In a world of randomized MAC address, how can a EAP server implement: `Servers
SHOULD rate-limit provisioning attempts` ?

Should this be a MAY in `Implementations SHOULD use functionality such as the
RADIUS Filter-Id` ? After it is a local deployment issue.

Should there be some text that the underlying network (e.g., Wi-Fi AP) MUST
prevent inter-EAP-peer communication ? I.e., no hostile EAP peer can attack
victim EAP peer while the latter is being provisionned ?

### Section 3.6.2

s/to create credentials which do not expire/to create credentials *that* do not
expire/ ?

### Section 5.1

An informative reference to `web CAs` would be beneficial.

### Section 5?2

The 3rd paragraph is about network access restriction, why not simply pointing
to section 3.4.2 ?

### Section 6

Unsure whether "deprecated" is the right term in `The "[e-mail]"
registry entry is deprecated`, suggest using "deleted" but obviously IANA will
have the final say.

Please provide informative references (including URI) for all registries, e.g.,
https://www.iana.org/domains/arpa