Subject: [Gen-art] Gen-ART review of draft-ietf-intarea-nat-reveal-analysis-06

From: "Peter Yee" <[email-masked]>
Date: Fri, 5 Apr 2013 16:56:18 -0700

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.

---

From: <[email-masked]>
Date: Wed, 10 Apr 2013 08:53:02 +0200

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:[email-masked]]
>Envoyé : samedi 6 avril 2013 01:56
>À : [email-masked]
>Cc : [email-masked]; [email-masked]
>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>
>
>This draft is basically ready for publication, but has nits that should be
>fixed before publication. [Ready with nits]
>
>>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"?
>
>>Med: Establishing agreements with the owner of the address sharing
>function and owners of servers is heavy. This is already mentioned in the
>text.
>
>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.
>

---

From: Jari Arkko <[email-masked]>
Date: Wed, 10 Apr 2013 14:43:58 +0300

Peter: Thank you very much for your review. It helps me form an opinion of the document in preparation for tomorrow's IESG telechat.

Jari