Subject: Re: [radext] AD review: draft-ietf-radext-radius-extensions

From: Benoit Claise <[email-masked]>
Date: Fri, 04 Jan 2013 11:51:09 +0100

Alan,

Thanks for addressing my feedback.
See inline

> Benoit Claise wrote:
>
>> Do you want to have a table like in RFC 2865 section 5.44 with the list
>> of attributes, explaining whether or not they can be part of the sub-TLV, and
>> with which multiplicity.
>    Quite likely, yes.
I don't see this table.

>
>> 5.
>>     * New specifications SHOULD NOT request allocation from the standard
>>       Attribute Type Space (i.e. Attributes 1 through 255).  That space
>>       is deprecated.
>>
>> Deprecated: is it the right term?
>> Maybe you meant: Assignment from that space is not to be used.
>    IANA can't do that.
>
>> In this case, this contradicts
>>        * specifcumber of attributes
>>          (i.e. less than ten) should have all allocations made from
>>          the standard space.
>    I'll update that to change the allocation strategy to be a bit more
> flexible.
I still see the two contradictory sentences regarding the standard space :

    * New specifications SHOULD NOT request allocation from the standard
      Attribute Type Space (i.e. Attributes 1 through 255).  That space
      is deprecated.

       * specifications which allocate a small number of attributes
         (i.e. less than ten) should have all allocations made from
         the standard space.

Btw, RFC 2119 should be used for interoperability sentences, not process 
ones.
>
>> 	
>> 8.
>> section 10.3.4
>>        * specifications which allocate a small number of attributes
>>          (i.e. less than ten) should have all allocations made from
>>          the standard space.
>>
>>        * specifications which allocate a large number of attributes
>>          (i.e. ten or more) should have all allocations made from the
>>          extended space.
>> Instead of using a number, which would anyway not be relevant very long, why don't you have a relative number?
>> For example, instead of "i.e. ten or more", "compared to the remaining available number of entries in the standard space"
>    OK.  I'll just change it to "many" attributes.
I don't see that change.
There is also a connection with the previous point
>
>> 2.
>> Vendor-Id
>>
>>        The 4 octets are the SMI Network Management Private Enterprise
>>        Code of the Vendor in network byte order.
>>
>> Give a reference to http://www.iana.org/assignments/enterprise-numbers
>> Note: there are multiple instances of that sentence.
>   OK.
Editorial
OLD
     [SMI] http://www.iana.org/assignments/enterprise-numbers

NEW
     [PEN] http://www.iana.org/assignments/enterprise-numbers
>> 9.
>> This document updates: 2865 <http://tools.ietf.org/html/rfc2865>, 2866 <http://tools.ietf.org/html/rfc2866>, 3575 <http://tools.ietf.org/html/rfc3575>, 5176 <http://tools.ietf.org/html/rfc5176>, 6158 <http://tools.ietf.org/html/rfc6158>
>> My guess is that those should be normative references
>    Sure... it's an informational document, but OK.
Maybe I'll stand corrected, but I think this is the right thing to do. 
Please apply the changes.

I'll send this document to IETF last call. Treat this feedback as part 
of the last call.

Regards, Benoit

---

From: Benoit Claise <[email-masked]>
Date: Fri, 04 Jan 2013 15:11:57 +0100

Alan,
>>> 9.
>>> This document updates: 2865 <http://tools.ietf.org/html/rfc2865>, 
>>> 2866 <http://tools.ietf.org/html/rfc2866>, 3575 
>>> <http://tools.ietf.org/html/rfc3575>, 5176 
>>> <http://tools.ietf.org/html/rfc5176>, 6158 
>>> <http://tools.ietf.org/html/rfc6158>
After some more investigation, and reading RFC 3967 ...
This document updates
     RFC 2865, standard track
     RFC 2866, informational
     RFC 3575, standard track
     RFC 5176, informational
     RFC 6158, BCP

I'm wondering why RFC 2866 and RFC 5176 were informational in the first 
place. Maybe someone with a long history in the WG could shed some light?

 From RFC 3967, we need to have a clear idea on the downref before the 
IETF Last Call

    For Standards Track or BCP documents requiring normative reference to
    documents of lower maturity, the normal IETF Last Call procedure will
    be issued, with the need for the downward reference explicitly
    documented in the Last Call itself.  Any community comments on the
    appropriateness of downward references will be considered by the IESG
    as part of its deliberations.

Regards, Benoit

---

From: Alan DeKok <[email-masked]>
Date: Fri, 04 Jan 2013 09:11:32 -0500

> Btw, RFC 2119 should be used for interoperability sentences, not process

  OK.  I'll just delete the first bullet point.  The point immediately
after it covers the subject:

* Specifications should not request allocation from a specific space.
  The IANA considerations given in Section 9, below, should be
  sufficient for attribute allocation.

>>> For example, instead of "i.e. ten or more", "compared to the
>>> remaining available number of entries in the standard space"

  I'll fix that.

>     [PEN] http://www.iana.org/assignments/enterprise-numbers

  Fixed, thanks.

> Please apply the changes.

  Done.

  Alan DeKok.

---

From: "David B. Nelson" <[email-masked]>
Date: Fri, 4 Jan 2013 09:27:39 -0500

Benoit Claise writes...

> I'm wondering why RFC 2866 and RFC 5176 were informational
> in the first place. Maybe someone with a long history in
> the WG could shed some light?

I've been involved since the second RADIUS BOF (for the RADIUS WG), so I
remember some of this history.

RADIUS Accounting was not considered as robust as RADIUS, for a number of
reasons.  I think one reasons was the lack of positive application layer
acknowledgement that the data had been received and logged.  Anyway, the
IESG politics at the time dictated that Standards Track status would require
enhancements to RADIUS Accounting beyond what the RADIUS user community
would actively support.

I think there were similar "maturity" arguments around Dynamic RADIUS.

With the passage of time, and additional field experience, perhaps we would
look at it differently today.

Regards,

Dave

---

From: Benoit Claise <[email-masked]>
Date: Fri, 11 Jan 2013 18:24:28 +0100

Dear all,

After consultation with the IESG, and according to RFC 3967, I'll 
restart the IETF LC with the down ref clearly mentioned.

Regards, Benoit

>> Maybe I'll stand corrected, but I think this is the right thing to 
>> do. Please apply the changes.
> I'm wondering why RFC 2866 and RFC 5176 were informational in the 
> first place. Maybe someone with a long history in the WG could shed 
> some light?
>
> _______________________________________________
> radext mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/radext
>
>