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

From: Benoit Claise <[email-masked]>
Date: Thu, 27 Nov 2014 22:31:32 +0100

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