Subject: Re: [AAA-DOCTORS] RFC3575, "IANA Considerations for RADIUS (Remote Authentication Dial In User Service)"

From: Glen Zorn <[email-masked]>
Date: Mon, 03 Dec 2012 09:20:21 +0700

On 11/29/2012 04:24 PM, Benoit Claise wrote:

> Dear AAA doctors,
 >
 > An errata has been filed forFC3575
 > <http://www.rfc-editor.org/rfc/rfc3575.txt>, "IANA Considerations for
 > RADIUS (Remote Authentication Dial In User Service)" See
 > http://www.rfc-editor.org/errata_search.php?eid=3378 This errata was
 > discussed in RADEXT. However, I want to double check that you guys
 > are fine with it.

Thanks for checking: I, at least, am not fine with it.  AFAICT, the 
erratum is either a no-op or nonsense, since there seems to be no part 
of RFC 3575 that applies to 2868.

>
 > Regards, Benoit
 >
 >
 > _______________________________________________ AAA-DOCTORS mailing
 > list [email-masked]
 > https://www.ietf.org/mailman/listinfo/aaa-doctors

---

From: Glen Zorn <[email-masked]>
Date: Mon, 03 Dec 2012 13:13:04 +0700

On 11/30/2012 05:00 PM, Leaf yeh wrote:

>  http://www.rfc-editor.org/errata_search.php?eid=3378
 >
 > <quote> Section Metadata says: Updates: 2865 It should say: Updates:
 > 2865, 2868 </quote>
 >
 > a. I can't find RFC2868 in text body of RFC3575 except for the
 > section 3.2 of 'Informative References'. b. There is also no
 > explanation (or notes) on this errata.
 >
 >
 > On the other hand, I might found a errata in the Appendix A of
 > RFC3575.

Looks right to me, file it!

>
 > # Message Reference ----
 > ------------------------- --------- 4 Accounting-Request
 > [RFC2865] 5 Accounting-Response [RFC2865]
 >
 > It should be:
 >
 > # Message Reference ----
 > ------------------------- --------- 4 Accounting-Request
 > [RFC2866] 5 Accounting-Response [RFC2866]
 >
 > Notes: Section 4 of RFC2865 has not really defined these 2 messages,
 > they are defined in section 4 of RFC2866.
 >
 >
 > Best Regards, Leaf
 >
 >
 >
 > From: [email-masked]
 > [mailto:[email-masked]] On Behalf Of Dave Nelson Sent:
 > Thursday, November 29, 2012 8:22 PM To: Benoit Claise Cc:
 > [email-masked] Subject: Re: [AAA-DOCTORS] RFC3575, "IANA
 > Considerations for RADIUS (Remote Authentication Dial In User
 > Service)"
 >
 > Looks good to me.
 >
 > Regards,
 >
 > Dave
 >
 > David B. Nelson Director of Technology Elbrys Networks, Inc.
 > www.elbrys.com +1.603.570.2636 On Thu, Nov 29, 2012 at 4:24 AM,
 > Benoit Claise <[email-masked]> wrote: Dear AAA doctors,
 >
 > An errata has been filed for FC3575, "IANA Considerations for RADIUS
 > (Remote Authentication Dial In User Service)" See

---

From: Benoit Claise <[email-masked]>
Date: Mon, 03 Dec 2012 11:09:58 +0100

Dear all, Glen,

Let me give you some background on this errata.
First of all, this errata, which was mentioned by Bernard, has been 
discussed a long time ago.
I asked Bernard to file the errata, to have some concrete text to discuss.

Some background information (email from Bernard)

    RFC 3575 Section 2.1 states the following:

    Certain attributes (for example, NAS-Port-Type) in RADIUS define a list of values to correspond with various meanings.
    There can be 4 billion (2^32) values for each attribute. Additional values can be allocated by the Designated Expert.
    The exception to this policy is the Service-Type attribute (6), whose values define new modes of operation for RADIUS.
    Values 1-16 of the Service-Type attribute have been allocated. Allocation of new Service-Type values are by IETF Consensus.
    The intention is that any allocation will be accompanied by a published RFC.

    Note that the Tunnel-Type and Tunnel-Medium-Type attributes arenot called out as an exception, only Service-Type.
    If the intent was to exempt RFC 2868, those attributes would have  been  included as exceptions but they are not.

    Therefore, it looks to me like the omission of RFC 2868 in the  Updates: header is an errata.

 From the IETF 80 meeting minutes, 
https://www.ietf.org/proceedings/80/minutes/radext.txt:

    2. IANA issues
    A. How to allocate tunnel params? In RFC 3575 (RFC2868 conflicts as
    3575 assigns based on expert review but didn't update 2868).
    Omission of RFC 2868 could be an errata; this is basically a request
    for metadata.
    - Asks Dan for comment: was looking for input from the working group
    before proceeding.
    - Alan thought it was an errata.
    - Stefan states no opinion.
    - Klaas also states no opinion.
    - Nancy asks for further understanding. Bernard clarifies: RFC 2868
    states "standards action" and 3575 is more lenient in saying just
    expert review.
    - Now Dan remembers: when there's conflicts such as this, 2
    solutions: take the stricter or take the latest. But if it's the
    latest, then it needs to be clearer. Believes in this case, explicit
    clarification is justified since 3575 is more recent and the request
    is justified. But need IESG perspective review by WG.
    - Bernard suggests to get a sense of this group and then take it to
    the mailgroup.
    Asks: proposal is to accept and verify the errata and update 3575 to
    include 2868.
    In favor: 10, non oppose. Given consensus, will take to the mail list.

So we have consensus in the WG that this errata is valid.

I wanted to update the errata with the information above.
However, there is a problem, I can't: "Access Denied: RFC3575 is not a 
product of your stream. You are not the verifier of its errata. If you 
have information about this errata, please contact the *ISE & Editorial 
Board*."
Note: I copied Nevil Brownlee on this email thread.

This is weird: this is an independent track RFC, but with the status of 
Proposed Standard!!! Maybe this document was an exception because it 
updated RFC 2865?
I found back the old last call: 
http://www.ietf.org/mail-archive/web-old/ietf-announce-old/current/msg22711.html

Bernard, can you please update the errata with the background 
information above.
Also, this errata itself is not complete, you must add:
OLD:

	This document updates RFC 2865.

NEW:

	This document updates RFC 2865 and RFC 2868.

So the plan of action is:
1. update the errata with the background information.
2. double-check the proposed resolution with the AAA doctors. This email 
thread.
     Glen, does this background information change your point of view?
3. discuss with the IESG and ISE what to do in case of errata related to 
the metadata.

Regards, Benoit.

---

From: Glen Zorn <[email-masked]>
Date: Tue, 04 Dec 2012 11:08:55 +0700

On 12/03/2012 05:09 PM, Benoit Claise wrote:

> Dear all, Glen,
 >
 > Let me give you some background on this errata. First of all, this
 > errata, which was mentioned by Bernard, has been discussed a long
 > time ago. I asked Bernard to file the errata, to have some concrete
 > text to discuss.
 >
 > Certain attributes (for example, NAS-Port-Type) in RADIUS define a
 > list of values to correspond with various meanings. There can be 4
 > billion (2^32) values for each attribute. Additional values can be
 > allocated by the Designated Expert. The exception to this policy is
 > the Service-Type attribute (6), whose values define new modes of
 > operation for RADIUS. Values 1-16 of the Service-Type attribute have
 > been allocated. Allocation of new Service-Type values are by IETF
 > Consensus. The intention is that any allocation will be accompanied
 > by a published RFC.
 >
 > Note that the Tunnel-Type and Tunnel-Medium-Type attributes are not
 > called out as an exception, only Service-Type. If the intent was to
 > exempt RFC 2868, those attributes would have been included as
 > exceptions but they are not.
 >
 > 2. IANA issues A. How to allocate tunnel params? In RFC 3575 (RFC2868
 > conflicts as 3575 assigns based on expert review but didn’t update
 > 2868). Omission of RFC 2868 could be an errata; this is basically a
 > request for metadata. - Asks Dan for comment: was looking for input
 > from the working group before proceeding. - Alan thought it was an
 > errata. - Stefan states no opinion. - Klaas also states no opinion. -
 > Nancy asks for further understanding. Bernard clarifies: RFC 2868
 > states “standards action” and 3575 is more lenient in saying just
 > expert review. - Now Dan remembers: when there’s conflicts such as
 > this, 2 solutions: take the stricter or take the latest. But if it’s
 > the latest, then it needs to be clearer. Believes in this case,
 > explicit clarification is justified since 3575 is more recent and the
 > request is justified. But need IESG perspective review by WG. -
 > Bernard suggests to get a sense of this group and then take it to the
 > mailgroup. Asks: proposal is to accept and verify the errata and
 > update 3575 to include 2868. In favor: 10, non oppose. Given
 > consensus, will take to the mail list.
 >
 >
 > I wanted to update the errata with the information above. However,
 > there is a problem, I can't: "Access Denied: RFC3575 is not a product
 > of your stream. You are not the verifier of its errata. If you have
 > information about this errata, please contact the *ISE & Editorial
 > Board*." Note: I copied Nevil Brownlee on this email thread.
 >
 > This is weird: this is an independent track RFC, but with the status
 > of Proposed Standard!!! Maybe this document was an exception because
 > it updated RFC 2865? I found back the old last call:
 > 

IIRC,
there were no "Tracks" back then ; the IETF universe was a far less 
anal-retentive place ;-).

> Also, this errata itself is not  complete, you must add: OLD: This
 > document updates RFC 2865. NEW: This document updates RFC 2865 and
 > RFC 2868.
 >
 > So the plan of action is: 1. update the errata with the background
 > information. 2. double-check the proposed resolution with the AAA
 > doctors. This email thread. Glen, does this background information
 > change your point of view?

Not at all; in fact, it supports my assertion. The quote from RFC 3575 
above says that "Certain attributes (for example, NAS-Port-Type) in 
RADIUS define a
list of values to correspond with various meanings. There can be 4 
billion (2^32) values for each attribute." However, both the Tunnel-Type 
and Tunnel-Medium-Type Attributes are 3 octets in length, giving a range 
of 2^24 values for each. If you want to update 3575 so that it applies, 
that's fine, but right now it doesn't. Furthermore, the IANA allocation 
policy specified in RFC 2868 was chosen carefully, after considerable 
deliberation, to dissuade people from populating the table with "flavor 
of the month" values; loosening the policy seems purposeless at best. Do 
we really have nothing better to do?

 > 3. discuss with the IESG and ISE what to
> do in case of errata related to  the metadata.
 >
 > Regards, Benoit.
 >
 >
 >
 >>> <http://www.rfc-editor.org/rfc/rfc3575.txt>, "IANA Considerations
 >>> for RADIUS (Remote Authentication Dial In User Service)" See
 >>> http://www.rfc-editor.org/errata_search.php?eid=3378 This errata
 >>> was discussed in RADEXT. However, I want to double check that
 >>> you guys are fine with it.
 >>
 >> erratum is either a no-op or nonsense, since there seems to be no
 >> part of RFC 3575 that applies to 2868.
 >>
 >>>
 >>> Regards, Benoit
 >>>
 >>>
 >>> _______________________________________________ AAA-DOCTORS
 >>> mailing list [email-masked]

---

From: Benoit Claise <[email-masked]>
Date: Tue, 04 Dec 2012 12:34:57 +0100

Glen,
> billion (2^32) values for each attribute." However, both the 
> Tunnel-Type and Tunnel-Medium-Type Attributes are 3 octets in length, 
> giving a range of 2^24 values for each. If you want to update 3575 so 
> that it applies, that's fine, but right now it doesn't. Furthermore, 
> the IANA allocation policy specified in RFC 2868 was chosen carefully, 
> after considerable deliberation, to dissuade people from populating 
> the table with "flavor of the month" values; loosening the policy 
> seems purposeless at best. Do we really have nothing better to do?
The discussion, as I understand it,  is about "IETF consensus" versus 
"Designated Expert"
 From RFC 2868

    6.1.  Tunnel-Type Attribute Values

        Values 1-12 of the Tunnel-Type Attribute are defined in Section 5.1;
        the remaining values are available for assignment by the IANA with
        _IETF Consensus_  [16].

    6.2.  Tunnel-Medium-Type Attribute Values

        Values 1-15 of the Tunnel-Medium-Type Attribute are defined in
        Section 5.2; the remaining values are available for assignment by the
        IANA with_IETF Consensus_  [16].

 From RFC 3575

    Certain attributes (for example, NAS-Port-Type) in RADIUS define a
    list of values to correspond with various meanings.  There can be 4
    billion (2^32) values for each attribute.  Additional values can be
    allocated by the_Designated Expert_._The exception to this policy is
    the Service-Type attribute (6)_, whose values define new modes of
    operation for RADIUS.

So  Tunnel-Type and Tunnel-Medium-Type are "IETF consensus" or 
"Designated Expert"?

Regards, Benoit

---

From: Benoit Claise <[email-masked]>
Date: Tue, 04 Dec 2012 17:21:34 +0100

Dear all,

The errata has been updated.
See 
http://www.rfc-editor.org/errata_search.php?rfc=3575&rec_status=15&presentation=records

Regards, Benoit
>> Not at all; in fact, it supports my assertion. The quote from RFC 
>> 3575 above says that "Certain attributes (for example, NAS-Port-Type) 
>> in RADIUS define a
>> the IANA allocation policy specified in RFC 2868 was chosen 
>> carefully, after considerable deliberation, to dissuade people from 
>> populating the table with "flavor of the month" values; loosening the 
>> policy seems purposeless at best. Do we really have nothing better to 
>> do?
> _______________________________________________
> AAA-DOCTORS mailing list
> [email-masked]

---

From: Benoit Claise <[email-masked]>
Date: Thu, 06 Dec 2012 22:33:49 +0100

Bernard,

I believe that the IANA registry needs to be updated as well.
Can you please let me know what exactly.

Regards, Benoit
>>> 3575 above says that "Certain attributes (for example, 
>>> NAS-Port-Type) in RADIUS define a
>>> Tunnel-Type and Tunnel-Medium-Type Attributes are 3 octets in 
>>> length, giving a range of 2^24 values for each. If you want to 
>>> update 3575 so that it applies, that's fine, but right now it 
>>> doesn't. Furthermore, the IANA allocation policy specified in RFC 
>>> 2868 was chosen carefully, after considerable deliberation, to 
>>> dissuade people from populating the table with "flavor of the month" 
>>> values; loosening the policy seems purposeless at best. Do we really 
>>> have nothing better to do?

---

From: Glen Zorn <[email-masked]>
Date: Fri, 07 Dec 2012 20:09:12 +0700

On 12/04/2012 06:34 PM, Benoit Claise wrote:

> Glen,
 >>
 >>>
 >>> So the plan of action is: 1. update the errata with the
 >>> background information. 2. double-check the proposed resolution
 >>> with the AAA doctors. This email thread. Glen, does this
 >>> background information change your point of view?
 >>
 >> NAS-Port-Type) in RADIUS define a list of values to correspond with
 >> various meanings. There can be 4 billion (2^32) values for each
 >> attribute." However, both the Tunnel-Type and Tunnel-Medium-Type
 >> Attributes are 3 octets in length, giving a range of 2^24 values
 >> for each. If you want to update 3575 so that it applies, that's
 >> fine, but right now it doesn't. Furthermore, the IANA allocation
 >> policy specified in RFC 2868 was chosen carefully, after
 >> considerable deliberation, to dissuade people from populating the
 >> table with "flavor of the month" values; loosening the policy seems
 >> purposeless at best. Do we really have nothing better to do?
 > "Designated Expert" From RFC 2868

Oh, I see!  Silly me, I had thought that the discussion was about 
whether there had been an oversight or, you know, an actual /error/ made 
in RFC 3575 that would make an erratum necessary.  I made the case that 
this was not correct, because 3575 and 2868 are talking about different 
RADIUS data types (at least according to RFC 6158). However, if the 
discussion is about "IETF Consensus" versus "Designated Expert" then I 
can't imagine that anyone on the planet actually cares -- certainly not I.

...

---

From: Benoit Claise <[email-masked]>
Date: Fri, 07 Dec 2012 14:39:39 +0100

Dear all,

(Thanks Glen for your reply)

Do you confirm that IANA needs to be changed the following way?

http://www.iana.org/assignments/radius-types/radius-types.xml#radius-types-14
OLD
Registration Procedures
     IETF Consensus
Reference
     [RFC2868]

NEW
Registration Procedures
     Designated Expert
Reference
     [RFC3575]

http://www.iana.org/assignments/radius-types/radius-types.xml#radius-types-15
OLD
Registration Procedures
     IETF Consensus
Reference
     [RFC2868]

NEW
Registration Procedures
     Designated Expert
Reference
     [RFC3575]

Regards, Benoit
> whether there had been an oversight or, you know, an actual /error/ 
> made in RFC 3575 that would make an erratum necessary.  I made the 
> case that this was not correct, because 3575 and 2868 are talking 
> about different RADIUS data types (at least according to RFC 6158). 
> However, if the discussion is about "IETF Consensus" versus 
> "Designated Expert" then I can't imagine that anyone on the planet 
> actually cares -- certainly not I.
>
> ...
>
>

---

From: Benoit Claise <[email-masked]>
Date: Tue, 11 Dec 2012 10:08:05 +0100

Bernard, All,

Like you, I want to close this errata, but I need a confirmation:

OLD
Registration Procedures
     IETF Consensus
Reference
     [RFC2868]

NEW
Registration Procedures
     Designated Expert
Reference
     [RFC3575]

OLD
Registration Procedures
     IETF Consensus
Reference
     [RFC2868]

NEW
Registration Procedures
     Designated Expert
Reference
     [RFC3575]

Do I miss anything?

Regards, Benoit