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

[Meral Shirazipour <[e-mail]>]

Hi,
  Many thanks. Looks good to me.

Best Regards,
Meral

From: Alejandro Perez Mendez [mailto:[e-mail]]
Sent: Friday, January 09, 2015 1:02 AM
To: Meral Shirazipour; [e-mail]; [e-mail]
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.

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],"Compliant RADIUS 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<http://www.ericsson.com>