RE: Gen-ART review of draft-ietf-intarea-nat-reveal-analysis-06

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Dear Peter,

The two OLD nits are already fixed in my local copy.

As for the new one, I'm generating the references automatically. The RFC Editor can fix this if needed.

Thanks.

Cheers,
Med

>-----Message d'origine-----
>De : Peter Yee [mailto:peter@xxxxxxxxxx]
>Envoyé : samedi 6 avril 2013 01:56
>À : draft-ietf-intarea-nat-reveal-analysis.all@xxxxxxxxxxxxxx
>Cc : gen-art@xxxxxxxx; ietf@xxxxxxxx
>Objet : Gen-ART review of draft-ietf-intarea-nat-reveal-analysis-06
>
>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 wait for direction from your document shepherd or AD before posting
>a new version of the draft.
>
>Document: draft-ietf-intarea-nat-reveal-analysis-06
>Reviewer: Peter Yee
>Review Date: Apr-5-2013
>IETF LC End Date: Mar-8-2013
>IESG Telechat date: Apr-11-2013
>
>This draft is basically ready for publication, but has nits that should be
>fixed before publication. [Ready with nits]
>
>It addresses most of the issues raised in my review of the -05 version.
>Two items from that review that I'm
>revisiting are noted below with text from the original review and responses
>from one of the authors (Med).
>We agreed that those two revisited items could be addressed in a subsequent
>revision; they are just
>recorded here for ease of reference.
>
>Major issues:
>
>Minor issues:
>
>Nits:
>
>[Old]
>
>>>Section 3.1, 5th paragraph: I don't quite follow what's being said here.
>>>Is the point that the address-sharing function should reveal the same
>>>HOST_ID for any given host regardless of what layer or mechanism that
>>>HOST_ID is being conveyed across?  How does this relate to
>>>interference between HOST_IDs?
>
>>Med: The point is: when several layers are used to inject a host_id, the
>device should check the same subset of information is revealed. For
>instance, there should not be conflict, etc.
>
>Then perhaps you could reword so that "should reveal subsets of the same
>information" becomes "should reveal the same subsets of information at each
>layer"?
>
>>>Section 4.9.2, 4th bullet item, 2nd sentence: Delete "heavy and" unless
>you want to
>>>explain what heavy means.
>
>>Med: Establishing agreements with the owner of the address sharing
>function and owners of servers is heavy. This is already mentioned in the
>text.
>
>Perhaps you could replace "heavy" with "burdensome".
>
>[New]
>
>In the references, there seem to be an excess of commas in a couple of
>places.   Look for the string ", ," (comma space comma) and you'll see what
>I mean.  The document titles start with an extra comma and end with one.
>
>Also in the references, for RFC 1413, put a space between the "M." and the
>"C." in Mike St. Johns' initials.
>






[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]