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

From: Benoit Claise <[email-masked]>
Date: Mon, 05 Jan 2015 11:13:33 +0100

Dear draft-ietf-radext-radius-fragmentation authors,

Can you please address the GEN-ART review.

Regards, Benoit
>
> 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.
>
> 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.
>
> -[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"
>
> -Other:
>
> * Not sure if this RFC should reference to 
> draft-ietf-radext-bigger-packets as another alternative to look for?
>
> * Please spell at first use: EAP, NAS, PKI, SAML,ABFAB
>
> *chunk/chunking, would it be better to use 
> fragment/fragmenting/fragmentation instead ? or mention the two terms 
> are used interchangeably.
>
> Best Regards,
>
> Meral
>
> ---
>
> Meral Shirazipour
>
> Ericsson
>
> Research
>
> www.ericsson.com
>

---

From: Alejandro Perez Mendez <[email-masked]>
Date: Wed, 07 Jan 2015 09:31:16 +0100

Hi Benoit,

sure, we will provide an updated version in a few days.

Regards,
Alejandro

El 05/01/15 a las 11:13, Benoit Claise escribió:
>> -[Page 6], "NOT be used to exchange more than 100K of data", not 
>> clear what 100K is here? bytes? why?
>>

---

From: Alejandro Perez Mendez <[email-masked]>
Date: Fri, 09 Jan 2015 10:01:55 +0100

Dear Meral,

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

> 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.

> 4096 octet limit was put in place initially and what has changed since.

We've added some clarifying text.

> -[Page 27], "into a even"--->"into an even"

Thanks, we have fixed these issues.

> 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.

> 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

---

From: Meral Shirazipour <[email-masked]>
Date: Fri, 9 Jan 2015 17:31:29 +0000

Hi,
  Many thanks. Looks good to me.

Best Regards,
Meral

From: Alejandro Perez Mendez [mailto:[email-masked]]
Sent: Friday, January 09, 2015 1:02 AM
To: Meral Shirazipour; [email-masked]; [email-masked]
Subject: Re: Gen-ART Last Call review of draft-ietf-radext-radius-fragmentation-09

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.

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.

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.

-[Page 4], "this approach does entirely solve"---> should it be "does not" ?

-[Page 6], "NOT be used to exchange more than 100K of data", not clear what 100K is here? bytes? why?

-[Page 14],"Compliant RADIUS Chlient"-->"...client"

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

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<http://www.ericsson.com>