[auth48] Re: AUTH48: RFC-to-be 9965 <draft-ietf-emu-eap-arpa-10> for your review

[Alan DeKok <[e-mail]>]

On Apr 28, 2026, at 12:52 AM, [e-mail] wrote:
> 1)  <!-- [rfced] We had the following questions related to the document's title:
> 
> a) Please note that the title of the document has been updated as
> follows:
> 
> Abbreviations have been expanded per Section 3.6 of RFC 7322 ("RFC
> Style Guide"). Please review.
> 
> Original:
> The eap.arpa. domain and EAP provisioning
> 
> Current:
> The eap.arpa. Domain and Extensible Authentication Protocol (EAP) Provisioning

  This is OK.

> b) Please confirm that no period should appear at the end of the
> abbreviated title (that appears in the running header of the PDF
> output).
> 
> Current:
> eap.arpa
> -->

  It would be better as:   The eap.arpa. Domain

> 2) <!-- [rfced] Please insert any keywords (beyond those that appear in
> the title) for use on https://www.rfc-editor.org/search. -->
> 
> 
> 3) <!--[rfced] Would it make sense to update as follows?
> 
> Original:
> Without credentials, the device cannot obtain network access in order
> to be provisioned with credentials.
> 
> Perhaps:
> Without pre-provisioned credentials, the device cannot obtain network
> access in order to be provisioned with credentials.

  Yes.

> Or maybe "Without these credentials"?
> -->      
> 
> 
> 4) <!--[rfced] Please confirm the use of the period in the following
>     (i.e., outside the quotation marks).  Seems to be related to
>     domain use.
> 
> Original:
> The EPI is an NAI which is a subdomain of "eap.arpa".
> 
> Perhaps:
> The EPI is an NAI that is a subdomain of "eap.arpa.".
> -->

  The change is correct, thanks.

> 
> 5) <!-- [rfced] We had a few questions about the following:
> 
> Original:
>   NOTE: the "arpa" domain is controlled by the IAB.  Allocation of the
>   eap.arpa. domain name requires agreement from the IAB.
> 
> a) We have updated this text as follows as requested in the RFC Editor
> Note.  Please review and let us know if you have any objections.
> 
> Current:
> As the controller of the "arpa" domain, the IAB has approved the
> allocation of eap.arpa.
> 
> b) We were curious if the reader might need a pointer to where this
> agreement could be found?  Or any further citation needed here?
> -->

  I don't know of any official statement from the IAB.  It would be worth double-checking with the IAB that they are aware of this request, and have approved it.

> 6) <!--[rfced] Please clarify the use of "the EAP registry" in this text:
>     Original: ...However, the EAP registry does not follow the domain
>     name conventions specified in...
> -->        

  It should be instead:

However, the names in the EAP Method Type registry [EAP-METHOD] do not follow the domain name formats specified in ...

[EAP_METHOD]: https://www.iana.org/assignments/eap-numbers/eap-numbers.xhtml#eap-numbers-4

> 
> 7) <!--[rfced] In the following, is "EAP peers" intentionally repeated?
>     Please review and let us know if a rephrase is necessary.
> 
> Original:
> Having described the format and contents of NAIs in the eap.arpa realm
> to define the EPI, we now describe how those EPIs are used by EAP
> peers and EAP peers to signal provisioning information
> 
> Perhaps:
> Having described the format and contents of NAIs in the eap.arpa realm
> to define the EPI, we now describe how those EPIs are used by EAP
> peers to signal provisioning information.
> -->        

  It should be "... by EAP peers and EAP servers to ..."

  i.e. it's a forward reference to 3.4.1 (EAP peers) and 3.4.2 (EAP servers)
 
> 8) <!--[rfced] We had a few questions regarding this text:
> 
> Original:
> An EAP server supporting this
> specification MUST examine the identity to see if it uses a realm
> located under eap.arpa. 
> 
> a) Would it make sense to update this text as follows (to clarify the
> trailing "." character?
> 
> Perhaps A:
> An EAP server supporting this
> specification MUST examine the identity to see if it uses a realm
> located under the eap.arpa. domain.
> 
> Perhaps B:
> An EAP server supporting this
> specification MUST examine the identity to see if it uses a realm
> located under the eap.arpa realm.         

  (B) is correct.

> b) Would it make sense to reword the following?
> 
> Perhaps:
> An EAP server implementing this specification...
> -->

  Yes.  "implementing" is better than "supporting".

> 
> 9) <!-- [rfced] We had two questions about the following text:
> 
> Original:
> For example, both EAP-MSCHAPv2 (PEAP) and EAP-PWD [RFC5931]
>   perform cryptographic exchanges where both parties knowing a shared
>   password. 
> 
> a) We see that [RFC5931] uses "EAP-pwd" rather than "EAP-PWD".  Please
> review and let us know if any updates are necessary.

 We can use EAP-pwd throughout.

> Current:
>   For example, both EAP-MSCHAPv2 (PEAP) and EAP-PWD [RFC5931] perform
>   cryptographic exchanges where both parties knowing a shared password.
> 
> b) Should MSCHAPv2 be expanded to Microsoft Challenge Handshake
> Authentication Protocol version 2?  If so, how does it interact with
> the parenthetical (PEAP)?
> -->

  We shouldn't expand MSCHAPv2.  The "EAP-MSCHAPv2" is the name of an EAP type.

> 10) <!--[rfced] Please review the use of 802.11u in the following.  As all
>     other instances are to 802.11X, is this use intentional?  If so,
>     should a pointer to 802.11u be added?

  We can add a reference to 802.11u.

> Original:
> The captive portal can advertise support for the eap.arpa. domain via
> an 802.11u realm.
> -->
> 
> 
> 11) <!--[rfced] We had several questions related to the IANA
>     Considerations in this document.
> 
> a) We note that Section 5 (IANA Considerations) describes some of
> what's to come in the subsections of Section 5.  This pointed out to
> us that perhaps Sections 5.3, 5.3.1, 5.4, and 5.5 should actually be
> subsections of Section 5.2 (i.e., what registry does "...this
> registry" in Section 5.3 refer to?).
> 
> Original:
>   A number of IANA actions are required.  There are two registry
>   updates in order to define the eap.arpa. domain.  A new registry is
>   created.  The "[e-mail]" registry entry is deprecated.
> 
> Current:
> This document describes a number of IANA actions:
> 
> - There are two registry updates in order to define the
> eap.arpa. domain (see Section 5.1).
> 
> - A new registry is created (see Section 5.2).
> 
> - The "[e-mail]" registry entry is deprecated (see Section 5.1.1).
> 
> Perhaps:
> This document describes a number of IANA actions:
> 
> -IANA has made two registry updates in order to define the
> eap.arpa. domain (see Section 5.1).
> 
> -IANA has created a new registry (see Section 5.2).
> 
> 
> With the reorganization of the sections as mentioned above?  Please
> review and advise.

  The proposed changes are good, thanks.

> b) Note that we have updated mentions of ".arpa registry" to point
> instead to the ".ARPA Zone Management" registry.

  That's fine.

> Please review and advise if this was not what was intended.
> 
> c) For the ease of the reader, we have added some citations as well as
> an informative reference to the Special-Use Domain Names registry.
> Please let us know any objections.

  No objections.

> d) In point 6 of Section 5.1.2.1, we see:
> 
> Original:
> Either behavior will have no impact on this specification.
> 
> Would the behavior have an effect on this document (or the content
> therein)?  Please review.

  No.  Perhaps:

Either behavior will have no impact on implementations of this specification.

> e) We see that the "EAP Provisioning Identifiers" registry uses
> "Method-Type" while the registry itself uses "Method Type" (with no
> hyphen).  May we update uses of Method-Type to read as Method Type
> throughout?  Note that we will communicate this change (as well as any
> other changes related to IANA registries) to IANA once AUTH48
> completes.
> -->

  Yes.  "Method Type" is fine.

> 
> 12)  <!--[rfced] Please clarify the antecedent of the pronoun "it" in the
>      following:
> 
> Original:
> This specification allows for unauthenticated EAP peers to obtain
> network access, however limited.  As with any unauthenticated process,
> it can be abused. Implementations should take care to limit the use of
> the provisioning network."
> -->

OLD:
	it

NEW
	this access

> 
> 13) <!--[rfced] In the following, is "to" missing?  Or is there another
>     way to rephrase?
> 
> Original:
> for any one device, rate limit its access the provisioning network.
> 
> Perhaps:
> for any one device, rate limit its access to the provisioning network.

  Yes.

> 14) <!--[rfced] We note that RFC 7170 has been obsoleted by RFC 9930.  We
>     have updated to the latter.  Please let us know any
>     objections. -->

  No objection.

> 15) <!--[rfced] We had the following questions related to terminology use
>     throughout the document:
> 
> a) We see that eap.arpa. domain is used consistently throughout.
> 
> However, we see the following with regard to .arpa:
> 
> "arpa" domain 
> ".arpa" domain
> 
> Should these be made consistent between themselves or more similar to
> eap.arpa. (i.e., no double quotes and trailing period)?

  Yes, no double quotes, and trailing period is correct.

> Further, please review the following with regard to the trailing period:
> 
> Original:
> ...the NAI SHOULD be of the form "[e-mail]".
> -->

  No trailing period here.

> 16) <!--[rfced] FYI - We see that an extra space is being inserted after
>     "eap.arp." in some places (e.g., titles).  We will dig into to
>     see if there is some formatting we can implement to remove the
>     added space. -->

  :)  I understand.  I suspect that the tools see the trailing "." as the end of a sentence.  Oh well.