Re: [radext] Adoption call for draft-perez-radext-radius-fragmentation-06

[Sam Hartman <[e-mail]>]

>>>>> "Alejandro" == Alejandro Perez Mendez <[e-mail]> writes:

    Alejandro> El 23/08/13 02:12, Peter Deacon escribió:
    >> On Thu, 22 Aug 2013, Alejandro Perez Mendez wrote:
    >> 
    >>> Hello Peter, thanks for the comments. See some responses below.
    >> 
    >>>>> Based on the discussion in Berlin we are ready to start
    >>>>> another adoption call for the solution for fragmentation of
    >>>>> RADIUS packets.
    >> 
    >>>> I would support this draft with narrower scope as interim
    >>>> solution addressing a specific use.
    >> 
    >>>> Have some concerns with draft as a general solution:
    >> 
    >>>> Section 2.  RFC5176 dynamic auth clients are not necessarily
    >>>> always RADIUS servers. We have production systems where CoA
    >>>> client and RADIUS server are separate with separate roles.
    >>>> Seeing value in maintaining separation I do not favor
    >>>> Additional-Authorization.
    >> 
    >>>> Accounting proposal is not atomic and depends on assumptions
    >>>> about type of content.  (e.g long attribute not able to fit
    >>>> within 4096 byte limit cannot be transmitted)
    >> 
    >>> I probably misunderstood your comment. We do not deal with CoA
    >>> or Accounting exchanges. They are left the way they are.
    >> 
    >> Hi Alejandro,
    >> 
    >> From section 2 "scope of this document".  Perhaps it might be
    >> best to simply address what is supported and remove extraneous
    >> references to what is not changed (CoA and
    >> Accounting). Specifically:
    >> 
    >> " Instead, the CoA client MUST send a CoA-Request packet
    >> containing session identification attributes, along with
    >> Service-Type = Additional- Authorization, and a State attribute.
    >> Implementations not supporting fragmentation will respond with a
    >> CoA-NAK, and an Error-Cause of Unsupported-Service.
    >> 
    >> Implementations supporting this specification may not be able to
    >> change authorization data for a particular session.  In that
    >> case, they MUST respond with a CoA-NAK, as above.  Otherwise, the
    >> implementation MUST start fragmentation via Access-Request, using
    >> the methods defined here."
    >> 

    Alejandro> The purpose of that text is to explain why we do not deal
    Alejandro> with CoA or Accounting, that is, why they do not need of
    Alejandro> a fragmentation solution. Removing them would provoke
    Alejandro> other people to ask why we do not support them.

I support retaining the section 2 text.