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
_______________________________________________
Gen-art mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/gen-art
