Subject: Re: [AAA-DOCTORS] [IANA #803042] Re: Evaluation: <draft-ietf-radext-radius-fragmentation-10.txt> to Experimental RFC

From: Benoit Claise <[email-masked]>
Date: Tue, 13 Jan 2015 10:57:55 +0100

Including the AAA-doctors, to make sure we do the right thing with the 
registry.

Regards, Benoit
> Dear Pearl,
>
> El 12/01/15 a las 18:33, Pearl Liang via RT escribió:
>> Dear Alejandro,
>>
>> On Sat Jan 10 12:15:36 2015,[email-masked]  wrote:
>>> Hi Pearl,
>>>
>>> you are right. The table in the IC section and the attribute
>>> descriptions in section 10 contain some errors.
>>> Hopefully, the following changes should fix them:
>>>
>>>    * The table header in the IC section called "Tag" should be "Type"
>>>      instead.
>>>    * The text in the IC section that says "assigned values of TBD1 and
>>>      TBD2 from the Long Extended Space of RFC6929" should be "assigned
>>>      values of SHORT-TBD1 and SHORT-TBD2 from the Short Extended Space
>>> of
>>>      RFC6929"
>>>    * In section 10.1, values for the Type and Extended Type fields
>>> should
>>>      take the SHORT-TBD1 placeholder (note this is a split value)
>>>    * In section 10.2, values for the Type and Extended Type fields
>>> should
>>>      take the SHORT-TBD2 placeholder (note this is a split value)
>>>
>>> Therefore, the table should be the following:
>>>
>>> Type       Name            Length  Meaning
>>> ----       ----            ------  -------
>>> SHORT-TBD1 Frag-Status     7       Signals fragmentation
>>> SHORT-TBD2 Proxy-State-Len 7       Indicates the length of the
>>>                                      received Proxy-State attributes
>>>
>> Hmm...how would SHORT-TBD1 and SHORT-TBD2 match the place holder TBA
>> in both section 10.1 and 10.2?
>
> Those TBA place holders are changed by SHORT-TBD1 and SHORT-TBD2 as 
> follows:
>
> Section 10.1
>
>    Type
>       SHORT-TBD1
>
>    Length
>       7
>
>    Extended-Type
>      SHORT-TBD1
>
>
> Section 10.2
>
>    Type
>       SHORT-TBD2
>
>    Length
>       7
>
>    Extended-Type
>      SHORT-TBD2
>
>> Also, as I noted in the Eval message, you use the placeholder "TBA" for a different
>> assignment:
>>
>> TBA Additional-Authorization See section 4.1
>
> Now, TBA would only refer to the allocation of a new Service-Type value.
>
>> Again, these discrepancies are not a show stopper.  You need to clarify those
>> when you are ready to replace those place holders with the actually assigned
>> values.  Thus I marked IANA Okay.
>
> That's great. Thanks,
> Alejandro
>
>>
>> Thanks,
>> ~pl
>>
>>
>>> If these changes fix the problem, I will commit them and submit a new
>>> version (if that's required).
>>>
>>> Thanks and best regards,
>>> Alejandro
>>>
>>>
>>> El 09/01/15 a las 20:59, Pearl Liang via RT escribió:
>>>> IESG:
>>>>
>>>> IANA OK. Comments in tracker.
>>>> IANA Actions - YES
>>>>
>>>> Note: I do have a question about the three place holders in the IC
>>> section.
>>>> I noticed that there are 3 different place holders, TBD1, TBD2, and
>>> TBA,
>>>> in the IC section:
>>>>
>>>> Tag    Name            Length  Meaning
>>>>          ----   ----            ------  -------
>>>>          TBD1   Frag-Status     7       Signals fragmentation
>>>>          TBD2   Proxy-State-Len 7       Indicates the length of the
>>>>                                         received Proxy-State
>>> attributes
>>>>      Additionally, allocation of a new Service-Type value for
>>> "Additional-
>>>>      Authorization" is requested.
>>>>
>>>>             Value    Service Type Value              Definition
>>>>             ----     ------------------------        ----------
>>>>             TBA      Additional-Authorization        See section 4.1
>>>>
>>>>
>>>> However "TBA" is used in multiple locations in section 10 of the
>>> draft for
>>>> Frag-Status and Proxy-State-Len.  That doesn't match what the
>>> authors
>>>> proposed in the IC section.  Can someone clarify that?
>>>>
>>>> Thank you,
>>>>
>>>> Pearl Liang
>>>> ICANN
>>>>
>>>>
>>>> On Fri Jan 09 14:26:30 2015,[email-masked]  wrote:
>>>>> Evaluation for <draft-ietf-radext-radius-fragmentation-10.txt> can
>>> be
>>>>> found at
>>>>> http://datatracker.ietf.org/doc/draft-ietf-radext-radius-
>>>>> fragmentation/
>>>>>
>>>>> Last call to expire on: 2014-12-25 00:00
>>>>>
>>>>>
>>>>>           Please return the full line with your position.
>>>>>
>>>>>                         Yes  No-Objection  Discuss  Abstain
>>>>> Benoit Claise        [ X ]     [   ]      [   ]    [   ]
>>>>>
>>>>>
>>>>> Has enough positions to pass.
>>>>>
>>>>> DISCUSSES AND COMMENTS
>>>>> ======================
>>>>> 
>>>>> ---- following is a DRAFT of message to be sent AFTER approval ---
>>>>> From: The IESG<[email-masked]>
>>>>> To: IETF-Announce<[email-masked]>
>>>>> Cc: RFC Editor<[email-masked]>,
>>>>>       radext mailing list<[email-masked]>,
>>>>>       radext chair<[email-masked]>
>>>>> Subject: Document Action: 'Support of fragmentation of RADIUS
>>> packets'
>>>>> to Experimental RFC (draft-ietf-radext-radius-fragmentation-09.txt)
>>>>>
>>>>> The IESG has approved the following document:
>>>>> - 'Support of fragmentation of RADIUS packets'
>>>>>     (draft-ietf-radext-radius-fragmentation-09.txt) as Experimental
>>> RFC
>>>>> This document is the product of the RADIUS EXTensions Working
>>> Group.
>>>>> The IESG contact persons are Benoit Claise and Joel Jaeggli.
>>>>>
>>>>> A URL of this Internet Draft is:
>>>>> http://datatracker.ietf.org/doc/draft-ietf-radext-radius-
>>>>> fragmentation/
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> Technical Summary
>>>>>
>>>>>      The Remote Authentication Dial-In User Service (RADIUS)
>>> protocol is
>>>>>      limited to a total packet size of 4096 octets.  Provisions
>>> exist
>>>>> for
>>>>>      fragmenting large amounts of authentication data across
>>> multiple
>>>>>      packets, via Access-Challenge.  No similar provisions exist for
>>>>>      fragmenting large amounts of authorization data.  This document
>>>>>      specifies how existing RADIUS mechanisms can be leveraged to
>>>>> provide
>>>>>      that functionality.  These mechanisms are largely compatible
>>> with
>>>>>      existing implementations, and are designed to be invisible to
>>>>>      proxies, and "fail-safe" to legacy clients and servers.
>>>>>
>>>>> Working Group Summary
>>>>>
>>>>>      The content of this document was discussed at length in the
>>> working
>>>>>      group, and there are multiple other approaches to the same
>>> problem.
>>>>>      The document thus got significant exposure at the experts of
>>> the
>>>>>      working group. The document has a few rough edges which were
>>> the
>>>>> cause
>>>>>      of discussions. Considering the target status of Experimental,
>>> they
>>>>>      appear minor enough to carry on with the experiment. The
>>> authors
>>>>> have
>>>>>      documented the friction points in their section 11 "Operational
>>>>>      Considerations". 11.1 in particular shows a process question:
>>> is it
>>>>>      appropriate for an Experimental RFC to update a Standards-track
>>>>> RFC?
>>>>>      The document attempts to follow that course; if this is
>>> ultimately
>>>>>      agreed after IESG review, the text in that section will be
>>> changed
>>>>>      accordingly.
>>>>>
>>>>> Document Quality
>>>>>
>>>>>      At least one implementation is known which implements this
>>>>>      specification: FreeRADIUS. The sheperd has no information about
>>>>> plans of
>>>>>      other vendors. There were no particular expert reviews outside
>>> the
>>>>>      working group process; i.e. no MIB doctor review nor Media Type
>>>>> review
>>>>>      (and no need for those two as the document contains neither
>>> MIBs
>>>>> nor
>>>>>      requests a Media Type). Since the document adds new transport
>>>>>      capabilities, a thorough review by transport experts (e.g.
>>> TSVDIR)
>>>>> during
>>>>>      IETF Last Call would be appreciated.
>>>>>
>>>>> Personnel
>>>>>
>>>>>      The Document Shepherd is Stefan Winter
>>> <[email-masked]>.
>>>>> The
>>>>>      responsible Area Directors are Benoit Claise
>>>>> <���[email-masked]>.
>>>>>
>>>>> RFC Editor Note
>>>>>
>>>>>     (Insert RFC Editor Note here or remove section)
>>>>>
>>>>> IRTF Note
>>>>>
>>>>>     (Insert IRTF Note here or remove section)
>>>>>
>>>>> IESG Note
>>>>>
>>>>>     (Insert IESG Note here or remove section)
>>>>>
>>>>> IANA Note
>>>>>
>>>>>     (Insert IANA Note here or remove section)
>>>>>
>>>>>
>>>>>
>>>>>
>

---

From: <[email-masked]>
Date: Tue, 13 Jan 2015 14:17:15 +0000

Hi Alejandro, All

Regarding the changes proposed for section 10.1 and 10.2, there is an error: "type" value and "extended type" value cannot be the same.  "Type" identifies the attribute type (i.e. "this is an extended attribute") and "extended type" identifies a specific attribute defined in the extended space created for the given attribute type value.

Moreover, I think it would be simpler for IANA guys to specifically identify the short extended space from which the new extended type value should be allocated.
As no other extended attribute has been allocated yet, the short extended space "241." in the Radius Attribute Types registry is more than likely the one to use.
It means that the requested values will be:

       Type       Name                   Length  Meaning
       ----       ----                   ------  -------
       241.TBD1   Frag-Status            7       Signals fragmentation
       241.TBD2   Proxy-State-Len(*gth*) 7       Indicates the length of the
                                                 received Proxy-State attributes

TBD1 and TBD2 values being picked inside the following possible ranges for 241:
(most likely)       * 241.{1-25}    Unassigned
or (unlikely)    * 241.{27-240}  Unassigned

[comment: I think that there is no reason not to name the second attribute "Proxy-State-Length" that is more explicit. if agreed, should be replace all across the document]

Consequences on section 10.1 and 10.2:
10.1<http://tools.ietf.org/html/draft-ietf-radext-radius-fragmentation-10#section-10.1>.  Frag-Status attribute
   This attribute is used for fragmentation signalling, and its meaning
   depends on the code value transported within it.  The following
   figure represents the format of the Frag-Status attribute.

                            1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |   Type        |    Length     | Extended-Type |     Code
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                         Code (cont)                   |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                       Figure 13: Frag-Status format

   Type

      241 (To be confirmed by IANA)

   Length

      7

   Extended-Type

      TBD1

   Code

      4 byte.  Integer indicating the code.  The values defined in this
      specifications are:

         0 - Reserved

         1 - Fragmentation-Supported

         2 - More-Data-Pending

         3 - More-Data-Request

   This attribute MAY be present in Access-Request, Access-Challenge and
   Access-Accept packets.  It MUST NOT be included in Access-Reject
   packets.  RADIUS Clients supporting this specification MUST include a
   Frag-Status = Fragmentation-Supported attribute in the first Access-
   Request sent to the RADIUS Server, in order to indicate they would
   accept fragmented data from the sever.

10.2<http://tools.ietf.org/html/draft-ietf-radext-radius-fragmentation-10#section-10.2>.  Proxy-State-Len(*gth*) attribute
   This attribute indicates to the RADIUS Client the length of the
   Proxy-State attributes received by the RADIUS Server.  This
   information is useful to adjust the length of the chunks sent by the
   RADIUS Client.  The format of this Proxy-State-Len(*gth*) attribute is the
   following:

                            1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |   Type        |    Length     | Extended-Type |     Value
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                   Value (cont)                        |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                     Figure 14: Proxy-State-Len(*gth*) format

   Type

      241 (To be confirmed by IANA)

   Length

      7

   Extended-Type

      TBD2

   Value

      4 octets.  Total length (in octets) of received Proxy-State
     attributes (including headers).

   This attribute MAY be present in Access-Challenge and Access-Accept
   packets.  It MUST NOT be included in Access-Request or Access-Reject
   packets.

I hope that this closes the small issue regarding IANA number allocation.

regards,

Lionel

De : AAA-DOCTORS [mailto:[email-masked]] De la part de Benoit Claise
Envoyé : mardi 13 janvier 2015 10:58
À : Alejandro Perez Mendez; [email-masked]
Cc : [email-masked]; [email-masked]; [email-masked]; [email-masked]
Objet : Re: [AAA-DOCTORS] [IANA #803042] Re: Evaluation: <draft-ietf-radext-radius-fragmentation-10.txt> to Experimental RFC

Including the AAA-doctors, to make sure we do the right thing with the registry.

Regards, Benoit
Dear Pearl,

Dear Alejandro,

On Sat Jan 10 12:15:36 2015, [email-masked]<mailto:[email-masked]> wrote:

Hi Pearl,

    instead.

of

    RFC6929"

should

should

Type       Name            Length  Meaning

----       ----            ------  -------

Those TBA place holders are changed by SHORT-TBD1 and SHORT-TBD2 as follows:

Section 10.1

   Type
      SHORT-TBD1

   Length
      7

   Extended-Type
     SHORT-TBD1

Section 10.2

   Type
      SHORT-TBD2

   Length
      7

   Extended-Type
     SHORT-TBD2

assignment:

That's great. Thanks,
Alejandro

Thanks,

~pl

Thanks and best regards,

Alejandro

IESG:

IANA Actions - YES

section.

TBA,

in the IC section:

Tag    Name            Length  Meaning

        ----   ----            ------  -------

                                       received Proxy-State

attributes

"Additional-

draft for

authors

Thank you,

Pearl Liang

ICANN

On Fri Jan 09 14:26:30 2015, [email-masked]<mailto:[email-masked]> wrote:

be

found at

fragmentation/

DISCUSSES AND COMMENTS

======================

---- following is a DRAFT of message to be sent AFTER approval ---

From: The IESG <[email-masked]><mailto:[email-masked]>

To: IETF-Announce <[email-masked]><mailto:[email-masked]>

Cc: RFC Editor <[email-masked]><mailto:[email-masked]>,

     radext mailing list <[email-masked]><mailto:[email-masked]>,

     radext chair <[email-masked]><mailto:[email-masked]>

packets'

RFC

Group.

fragmentation/

Technical Summary

protocol is

exist

for

multiple

provide

with

Working Group Summary

working

problem.

the

the

cause

they

authors

have

is it

RFC?

ultimately

changed

    accordingly.

Document Quality

plans of

the

review

MIBs

nor

TSVDIR)

during

Personnel

<[email-masked]><mailto:[email-masked]>.

The

<���[email-masked]><mailto:[email-masked]>.

RFC Editor Note

IRTF Note

IESG Note

IANA Note

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

---

From: Alan DeKok <[email-masked]>
Date: Tue, 13 Jan 2015 09:21:19 -0500

I think Lionel’s suggestion is the best way forward.

On Jan 13, 2015, at 9:17 AM, <[email-masked]> <[email-masked]> wrote:

> 10.1.  Frag-Status attribute
> 10.2.  Proxy-State-Len(*gth*) attribute
> On Sat Jan 10 12:15:36 2015, [email-masked] wrote:
> Hi Pearl,
>  
> On Fri Jan 09 14:26:30 2015, [email-masked] wrote:
> From: The IESG <[email-masked]>
> To: IETF-Announce <[email-masked]>
> Cc: RFC Editor <[email-masked]>,
>      radext mailing list <[email-masked]>,
>      radext chair <[email-masked]>
> _______________________________________________
> AAA-DOCTORS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/aaa-doctors

---

From: Alejandro Perez Mendez <[email-masked]>
Date: Tue, 13 Jan 2015 19:03:30 +0100

Hi Lionel,

Thank you for the suggestion. I completely agree with it too.

Regards,
Alejandro

---

From: Benoit Claise <[email-masked]>
Date: Tue, 20 Jan 2015 20:59:51 +0100

Dear IANA,

V11 has been posted today.
Please let us know if everything is fine now.

Regards, Benoit
>>>   Regarding the changes proposed for section 10.1 and 10.2, there is 
>>> an error: "type" value and "extended type" value cannot be the 
>>> same.  "Type" identifies the attribute type (i.e. "this is an 
>>> extended attribute") and "extended type" identifies a specific 
>>> attribute defined in the extended space created for the given 
>>> attribute type value.
>>>   Moreover, I think it would be simpler for IANA guys to 
>>> specifically identify the short extended space from which the new 
>>> extended type value should be allocated.
>>> As no other extended attribute has been allocated yet, the short 
>>> extended space "241." in the Radius Attribute Types registry is more 
>>> than likely the one to use.
>>>   [comment: I think that there is no reason not to name the second 
>>> attribute "Proxy-State-Length" that is more explicit. if agreed, 
>>> should be replace all across the document]
>>> Cc : [email-masked]; 
>>> [email-masked]; 
>>> [email-masked]; [email-masked]
>>> Objet : Re: [AAA-DOCTORS] [IANA #803042] Re: Evaluation: 
>>> <draft-ietf-radext-radius-fragmentation-10.txt> to Experimental RFC
>>> Ce message et ses pieces jointes peuvent contenir des informations 
>>> confidentielles ou privilegiees et ne doivent donc
>>> pas etre diffuses, exploites ou copies sans autorisation. Si vous 
>>> avez recu ce message par erreur, veuillez le signaler
>>> a l'expediteur et le detruire ainsi que les pieces jointes. Les 
>>> messages electroniques etant susceptibles d'alteration,
>>> This message and its attachments may contain confidential or 
>>> privileged information that may be protected by law;
>>> If you have received this email in error, please notify the sender 
>>> and delete this message and its attachments.
>>> As emails may be altered, Orange is not liable for messages that 
>>> have been modified, changed or falsified.
>>> Thank you.
>>>
> .

---

From: "Pearl Liang via RT" <[email-masked]>
Date: Thu, 22 Jan 2015 04:21:44 +0000

Benoit and AAA-doctors,

IANA has updated the tracker.

Thanks,
~pl

On Tue Jan 20 20:00:21 2015, [email-masked] wrote:
> >>>           0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8
> >>> 9
> >>> 0 1
> >>>      information is useful to adjust the length of the chunks sent
> >>> by
> >>> the
> >>>           0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8
> >>> 9
> >>> 0 1
> >>>    Including the AAA-doctors, to make sure we do the right thing
> >>> with
> >>> the registry.
> >>>
> >>> Regards, Benoit
> >>> Dear Pearl,
> >>>