Re: [Gen-art] Gen-ART Last Call review of draft-ietf-radext-radius-fragmentation-09

[Alejandro Perez Mendez <[e-mail]>]

Dear Meral,

thank you for the review. We have posted a new version (-10) addressing 
your comments.
Please, see inline for more details.

> I am the assigned Gen-ART reviewer for this draft. For background on 
> Gen-ART, please see the FAQ at 
> http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq.
>
> Please resolve these comments along with any other Last Call comments 
> you may receive.
>
> Document: draft-ietf-radext-radius-fragmentation-09
>
> Reviewer: Meral Shirazipour
>
> Review Date: 2014-12-25
>
> IETF LC End Date:  2014-12-25
>
> IESG Telechat date: NA
>
> Summary:
>
> This draft is ready to be published as Experimental RFC but I have 
> some comments.
>
> Minor issues:
>
> -Not sure about this, [page 1] says Updates: 2865, 6158, 6929 (if 
> approved). Can an experimental RFC update non-experimental RFCs?
>
> I read the note in Section 12.1. Just raising the question.
>

Yes, we had suppport from the IESG. This is what Barry Leib said:

    I think it absolutely makes sense (in the right circumstances) for an
    Experimental spec to "update" a Standards Track document: it's
    reasonable to consider something as an experimental update.  In those
    cases, I think it's very important for the Experimental document to be
    very clear about what the update is, and that it's experimental.


> Nits/editorial comments:
>
> -[Page 4], Intro, it would be good to remind the reader on why the 
> 4096 octet limit was put in place initially and what has changed since.
>

We've added some clarifying text.

> -[Page 4], Section 1, "limitation mean that"--->"limitation means that"
>
> -[Page 4], "this approach does entirely solve"---> should it be "does 
> not" ?
>
> -[Page 5], "the set up"--->"the setup"
>
> -[Page 5], "to implement the draft"--->"to implement the RFC"
>
> -[Page 6], "NOT be used to exchange more than 100K of data", not clear 
> what 100K is here? bytes? why?
>
> -[Page 7], "more than 4K of data", as above, not clear what 4K is?
>
> -[Page 9], "the RADIUS and COA"-->"CoA" instead of "COA"
>
> -[Page 14],"other then Additional-Authorization."--->"other than ..."
>
> -[Page 14],"CompliantRADIUS Chlient"-->"...client"
>
> -[Page 14],"if tey had"--->"if they had"
>
> -[Page 27], "into a even"--->"into an even"
>

Thanks, we have fixed these issues.

> -Other:
>
> * Not sure if this RFC should reference to 
> draft-ietf-radext-bigger-packets as another alternative to look for?
>

Good point. We've added a paragraph at the end of the introduction section.

> * Please spell at first use: EAP, NAS, PKI, SAML,ABFAB
>

Done.

> *chunk/chunking, would it be better to use 
> fragment/fragmenting/fragmentation instead ? or mention the two terms 
> are used interchangeably.
>

We chose chunk precisely to avoid the term "fragment", which is already 
used to refer to a portion of a "Long Extended Type" attribute from 
RFC6929. This distinction is required.

Best regards,
Alejandro


> Best Regards,
>
> Meral
>
> ---
>
> Meral Shirazipour
>
> Ericsson
>
> Research
>
> www.ericsson.com
>