Francis --
Thanks for your review. I have fixed all the typos, with the exception of
the "remoted/remote" and "need not be/needs not be" suggestion, which I
think are ok.
With respect to the reference to SP 800-57, is there a better reference
you would suggest?
An updated version of the document incorporating the fixes is available here:
http://www.ietf.org/internet-drafts/draft-simon-emu-rfc2716bis-13.txt
BTW, I'd note that there were some issues in the scheduling of this
GEN-ART review, given that the document was to have been considered
on the IESG agenda today. As a result, Sam objected to my addressing your
comments (even though the changes were purely editorial) and will delay
the processing of the document (see below). So perhaps the GEN-ART
reviews need to come in sooner (or the IESG needs to be informed when
they are going to come in so they are not suprised).
________________________________________From: Sam Hartman [EMAIL PROTECTED]:
Thursday, January 10, 2008 5:57 AMTo: [EMAIL PROTECTED]; [EMAIL PROTECTED]:
[EMAIL PROTECTED]: Re: New Version Notification -
draft-simon-emu-rfc2716bis-13.txt>>>>> "Internet-Draft" == Internet-Draft
<[EMAIL PROTECTED]> writes: Internet-Draft> New version (-13) has been
submitted for Internet-Draft> draft-simon-emu-rfc2716bis-13.txt.
Internet-Draft>
http://www.ietf.org/internet-drafts/draft-simon-emu-rfc2716bis-13.txtAs far as
I can tell, version 13 was not requested by either the AD orthe proto shepherd.
It is completely unacceptable to submit draftsafter publication request
without coordinating with the proto shepherdor shepherding AD. We're sometimes
sloppy about that, but doing soafter the draft is on a telechat agenda is
absolutely inappropriate.I am pulling the draft from the agenda and moving it
to the bottom of my queue.If I missed a message from Joe agreeing to this draft
being publishedI will re-evaluate.
> -----Original Message-----> From: [EMAIL PROTECTED] [mailto:[EMAIL
> PROTECTED]> Sent: Wednesday, January 09, 2008 1:24 PM> To: [email protected]>
> Cc: Dan Simon; Bernard Aboba; Ryan Hurst; [EMAIL PROTECTED]> Subject: review
> of draft-simon-emu-rfc2716bis-12.txt> > I have been selected as the General
> Area Review Team (Gen-ART)> reviewer for this draft (for background on
> Gen-ART, please see>
> http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html).> > Please resolve
> these comments along with any other Last Call comments> you may receive.> > >
> Document: draft-simon-emu-rfc2716bis-12.txt> Reviewer: Francis Dupont> Review
> Date: 2008-01-09> IETF LC Date: 2007-12-27> IESG Telechat date: 2008-01-10> >
> Summary: Ready> > Comments: I have some editorial comments (editorial means
> they should be> handled by the RFC Editor):> - 2.1 page 4: s/backend security
> server/backend authentication server/> - 2.1.1 page 5: s/e.g. /e.g., /> -
> 2.1.2 page 7: s/remoted/remote/> - 2.2 page 16: s/need not be/needs not be/
> (subject is "the identity")> - 5.1 page 22: s/KDF/key derivation function/> -
> 5.2 page 24: s/RDN/relative distinguished name (RDN)/> - 5.2 page 24:
> s/CN/CommonName (CN)/ ? (I know CN is more used than the> full name but as
> far as I know the official name is CommonName)> Note there could be other not
> introduced abbrevs> - 5.3 pages 24 and 25: s/conformant/compliant/ ?> - 6.2
> page 28: s/Bands" IEEE 802.16e/Bands", IEEE 802.16e/> - Acknowledgments page
> 29: it is not usual to add the companies> - Authors' Addresses page 30:
> please add USA (yes! :-)> > For the iESG I am not very satisfied with the
> reference to the NIST> SP800-57: this document is a good one and it is better
> to reference> it than to leave nothing but the IETF is an international body
> so> one could complain about the National in NIST... I don't know if it>
> really matters, BTW it is an informative reference, but it should be> nice to
> find a way to avoid any complains for this kind.> (Note I don't complain but
> I know the editor of the similar French gov> text (from an organization with
> the same N in its name :-) so I am> trying to understand what he should think
> about this point).> > Thanks> > [EMAIL PROTECTED]> > PS: as EAP-TLS seems to
> still be the only blessed EAP method usable> according to RFC 4017 it is (was
> now) very important to have a high> quality new version of 2716, so again
> thanks!
_______________________________________________
Gen-art mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/gen-art
