Skip to main content

Telechat Review of draft-ietf-intarea-nat-reveal-analysis-06
review-ietf-intarea-nat-reveal-analysis-06-genart-telechat-yee-2013-04-06-00

Request Review of draft-ietf-intarea-nat-reveal-analysis
Requested revision No specific revision (document currently at 10)
Type Telechat Review
Team General Area Review Team (Gen-ART) (genart)
Deadline 2013-04-09
Requested 2013-03-28
Authors Mohamed Boucadair , Dr. Joseph D. Touch , Pierre Levis , Reinaldo Penno
I-D last updated 2013-04-06
Completed reviews Genart Last Call review of -05 by Peter E. Yee (diff)
Genart Telechat review of -06 by Peter E. Yee (diff)
Secdir Last Call review of -05 by Scott G. Kelly (diff)
Assignment Reviewer Peter E. Yee
State Completed
Request Telechat review on draft-ietf-intarea-nat-reveal-analysis by General Area Review Team (Gen-ART) Assigned
Reviewed revision 06 (document currently at 10)
Result Ready w/nits
Completed 2013-04-06
review-ietf-intarea-nat-reveal-analysis-06-genart-telechat-yee-2013-04-06-00
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.