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

From: Alejandro Perez Mendez <[email-masked]>
Date: Tue, 02 Dec 2014 08:39:39 +0100

Dear Benoit,

thanks for the review. We will prepare a new revision considering your 
comments.

Best regards,
Alejandro

El 27/11/14 a las 22:31, Benoit Claise escribió:
> Dear all,
>
> Here is the AD review.
> Note that I initiated a discussion with the IESG on the topic of an 
> experimental doc updating a Standard Track doc. More on this pretty 
> soon (hopefully).
>
> 1.
> Since this is an experimental future RFC, the experiment should be 
> better explained. And if/when the experiment is successful, what's the 
> next step.
> As an example, 
> http://tools.ietf.org/html/draft-ietf-radext-dtls-13#section-1.3 was 
> appreciated by the IESG.
> Coming back to this draft, if the experiment is success, the Standard 
> Track version will update RFC 2865?
>
> 2.
> Open question: Does this draft update RFC 6158?
>     The Length field in the RADIUS packet header is defined in[RFC2865]
>     Section 3  <http://tools.ietf.org/html/rfc2865#section-3>.  It is noted there that the maximum length of a RADIUS
>     packet is 4096 octets.  As a result, attribute designers SHOULD NOT
>     assume that a RADIUS implementation can successfully process RADIUS
>     packets larger than 4096 octets.
> Or maybe this is taken care of by:
>     No such
>     exchange is possible for accounting or authorization data.[RFC6158]
>     Section 3.1  <http://tools.ietf.org/html/rfc6158#section-3.1>  suggests that exchanging large amounts authorization data
>     is unnecessary in RADIUS.
>
> Or, maybe, if this experiment is successful, then the Standard Track 
> version will update RFC 6158?
>
>
> _Editorial:_
> -
> Your first sentence in the introduction speaks about "Authentication 
> Server (AS)", but some other parts of the document speak about "server"
> Example:
>     In some cases, however, the
>     authorization data sent by the server is large and highly dynamic.
>     In other cases, the NAS needs to send large amounts of authorization
>     data to the server.
> Btw, RFC 6158 speaks of RADIUS Server, which I believe is the right term.
> Please be consistent regarding terminology: server, AS, RADIUS server
> Same remark for client, RADIUS client.
>
> -
> OLD
>   [RFC6158] recommends three approaches for the transmission of large
>     amount of data within RADIUS.  However, they are not applicable to
>     the problem statement of this document for the following reasons:
>
> NEW:
>   [RFC6158] section 3.1 recommends three approaches for the transmission of large
>     amount of data within RADIUS.  However, they are not applicable to
>     the problem statement of this document for the following reasons:
>
> -
> OLD
>     o  The first approach does not talk about large ...
>
>     o  The second approach is not usable either, ...
>
>     o  PMTU discovery does not solve the problem, as it does not allow to
>        send data larger than the minimum of (PMTU or 4096) octets.
>
> NEW:
>     o  The first approach (Utilization of a sequence of packets) does not talk about large ...
>
>     o  The second approach (Utilization of names rather than values) is not usable either, ...
>
>     o  PMTU discovery does not solve the problem, as it does not allow to
>        send data larger than the minimum of (PMTU or 4096) octets.
>
> -
> Similarly, there is no need to fragment CoA packets.
>
> A reference, or at least expanding the acronym would help
>
> -
> This limit is the minimum of 4096 octets, and the current PMTU.
> I guess you want to say
> This limit is the minimum of 4096 octets and the current PMTU.
>
> -
> It is strongly RECOMMENDED that servers include a State attribute
>
> So strongly RECOMMENDED is between RECOMMENDED and MUST? :-)
> Let's not invent new RFC 2119 semantics.
> NEW: It is RECOMMENDED that servers include a State attribute
>
> - Section 4.2
> OLD: Compliant clients receiving this packet will see the Frag-Status
>     attribute, wand suspend all authorization and authentication handling
>     until all of the chunks have been received.
>
> NEW: Compliant clients receiving this packet will see the Frag-Status
>     attribute,_and_suspend all authorization and authentication handling
>     until all of the chunks have been received.
>
> Regarding this sentence, we are in the "post-authorization section".
> So shouldn't be:
>
> NEW: Compliant clients receiving this packet will see the Frag-Status
>     attribute,_and_suspend all authorization handling
>     until all of the chunks have been received.
>
> - Section 11.2
>
>   The authors acknowledge that this specification violates the "MUST"
>     requirement of[RFC2865] Section 4.1  <http://tools.ietf.org/html/rfc2865#section-4.1>.
>
> Be specific on which MUST requirements in [RFC2865] Section 4.1 
> <http://tools.ietf.org/html/rfc2865#section-4.1>. you refer to
>
> While you revise the document, you might want to take care of 
> http://tools.ietf.org/idnits?url=https://tools.ietf.org/id/draft-ietf-radext-radius-fragmentation-08.txt
>
> Regards, Benoit
>
>
> _______________________________________________
> radext mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/radext