Subject: [eap] Another two minor and finicky IANA considerations questions for RFC3748

From: Florent Bersani <[email-masked]>
Date: Tue, 08 Jun 2004 12:59:51 +0200

Hi all,

While reviewing again RFC 3748b, I just came across two little (and 
fairly uninteresting I admit) questions/remarks (that may however help 
RFC 3748 understanding in the future:

1) It is apparently not specified how expanded (method) types for 
vendor-ID 0 (IETF) can be allocated (e.g. Designated Expert, with 
Specification Required or standards action, FCFS, ...).
In section 6.2 we indeed only read:
"Method Type values 256-4294967295 may be allocated after Type values 
1-191 have been allocated."
I know we've probably got time before this happens but I just feel 
reluctant to leave an incomplete spec behind us ;-)

2) The (non)-use of 0 as packet code or method type

The newbie I am is pretty sure that there are good reasons why EAP did 
not start its code and type space at 0 (and I'd be more than thankful to 
anybody who could tell me why) but I find the current wording about not 
using this value a (very little) bit confusing.

In section 6.1 of RFC 3748b we read:
"Packet Codes have a range from 1 to 255" and on the IANA website 
(http://www.iana.org/assignments/eap-numbers) we find:

"(last updated 12 April 2004)
Packet Codes:
Value Description Reference
1 Request [RFC-ietf-eap-rfc2284bis-09.txt]
2 Response [RFC-ietf-eap-rfc2284bis-09.txt]
3 Success [RFC-ietf-eap-rfc2284bis-09.txt]
4 Failure [RFC-ietf-eap-rfc2284bis-09.txt]
5-255 Unallocated"

In section 6.2 of RFC 3748b we read:
"The original EAP method Type space has a range from 1 to 255" and on 
the IANA website (http://www.iana.org/assignments/eap-numbers) we find:

"(last updated 12 April 2004)
...
Value Description Reference
0 RESERVED
1 Identity [RFC-ietf-eap-rfc2284bis-09.txt]
..."

Indeed, the value 0 is used in the NAK response.

My suggestion would be to find a way to simply reflect this usage in RFC 
3748 and for IANA.
My preference would be adding a small reminder on the value 0 usage in 
RFC 3748 section 6.2 and updating the IANA website to also refer to RFC 
3748 for this value. I am ready to propose some text if people feel like 
making this minor and unimportant change.

BR,
Florent

P.S: BTW, it seems like we (EAP and/or IANA) have not captured the point 
I raised earlier on Method Type 7&8 
(http://mail.frascone.com/pipermail/public/eap/2004-May/002486.html).
Again, I am ready to propose some text if people feel like making this 
minor and unimportant change (and I concurred to Jari's proposal 
"allocated but unused").
_______________________________________________
eap mailing list
[email-masked]
http://mail.frascone.com/mailman/listinfo/eap

---

From: Jari Arkko <[email-masked]>
Date: Thu, 10 Jun 2004 08:35:57 +0300

Hi Florant,

Thanks again for looking into the details!

> reluctant to leave an incomplete spec behind us ;-)

I think it would make sense to add ", through the advice of a
Designated Expert, with Specification Required" to the end of the sentence
that you quoted. Henrik tells me that he still can send a change
to the RFC editor.

> using this value a (very little) bit confusing.

I'm not sure what the history was. We probably shouldn't allocate
that number to anyone, someone's code might break if it uses 0
to represent "no method" or "no EAP" or something like that.

> making this minor and unimportant change.

I think we could add "0 RESERVED" to the IANA page of packet
codes (after we have published the RFC).

> minor and unimportant change (and I concurred to Jari's proposal 

There has been some new confusion about the exact status of 7 & 8.
We don't want to say anything about them at this point in time,
at least not in RFC 3748. I think we can update the IANA web page
later if we get more confident that they indeed are not used.

--Jari

---

From: Henrik Levkowetz <[email-masked]>
Date: Thu, 10 Jun 2004 09:57:07 +0200

Hi,

> that you quoted. Henrik tells me that he still can send a change

Ok, so the proposed change is as follows:

Section 6.2., para. 3:
OLD:
 
    Method Type 254 is allocated for the Expanded Type.  Where the
    Vendor-Id field is non-zero, the Expanded Type is used for functions
    specific only to one vendor's implementation of EAP, where no
    interoperability is deemed useful.  When used with a Vendor-Id of
    zero, method Type 254 can also be used to provide for an expanded
    IETF method Type space.  Method Type values 256-4294967295 may be
    allocated after Type values 1-191 have been allocated.
 
NEW:
 
    Method Type 254 is allocated for the Expanded Type.  Where the
    Vendor-Id field is non-zero, the Expanded Type is used for functions
    specific only to one vendor's implementation of EAP, where no
    interoperability is deemed useful.  When used with a Vendor-Id of
    zero, method Type 254 can also be used to provide for an expanded
    IETF method Type space.  Method Type values 256-4294967295 may be
    allocated after Type values 1-191 have been allocated, on the advice
    of a Designated Expert, with Specification Required.

I'll send it in.

	Henrik