Subject: [Gen-art] review of draft-ietf-intarea-shared-addressing-issues-02.txt

From: Francis Dupont <[email-masked]>
Date: Wed, 02 Feb 2011 16:18:10 +0100

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-intarea-shared-addressing-issues-02.txt
Reviewer: Francis Dupont
Review Date: 2011-02-01
IETF LC End Date: 2011-02-01
IESG Telechat date: unknown

Summary: Not Ready (a new version should be published)

Major issues: None

Minor issues: None but there are some comments from AD review
and many from TSVDIR review so I really expect the document will
be changed. BTW it seems these comments are about minor issues.

Nits/editorial comments:
(including personal comments)

 - 1 page 4: the beginning should be updated as the forecast was
  realized...

 - 5.1 page 10 (and other places):
  [I-D.ietf-tsvwg-port-randomization]  was published as RFC 6056

 - 5.2.1.1 page 11: UPnP IGD 2.0 last published last year

 - 9 page 14: at the exception of the last sentence the ICMP
  considerations are in fact about the ICMP echo service. I suggest
  to make this clearer: add some words at the beginning and make
  the last sentence about ICMP messages 'in general'.

 - 9 page 14: as far as I know *no* 'ping' tool supports the
  specification of the identifier to ping, so to provide
  'identifier forwarding' for pinging a host behind a NAT is useless
  (i.e., it only satisfies the ego of the programmer :-).

 - 11 page 15: IMHO in most of the cases the 'special handling'
  is reassembly. BTW if some NAT can be distributed (i.e., they
  share the mapping state) as far as I know this is never true
  for the reassembly state.

 - 12 page 16: in
 "Address sharing solutions must record and store all mappings"
 the term mappings could be considered as too general, i.e.,
 I don't believe the whole 7-tuple has to be logged. Now it is
 an informative document so a strict interpretation is not required
 (or even desirable).

 - 13.5 page 18 (and 6 page 13): RFC 3947 is no longer used: IKEv2
 has integrated NAT-detection/protection/traversal. IMHO at least
 the reference must be updated.

 - 27 page 26: please update [UPnP-IGD]. BTW the UPnP v2 includes both
  IGD 1.0 and IGD 2.0 so it is enough to put the parent reference.

spelling:
 - (twice) Acknowledgements -> Acknowledgments

 - wi-fi -> Wi-Fi

 - (and similar) geolocates -> geo-locates

 - (multiple) randomisation -> randomization

 - (twice) Behaviour -> Behavior

 - organisation -> organization

 - realise -> realize

 - customised -> customized

 - centralised -> centralized

 - (twice) optimisation -> optimization

 - (twice) utilise -> utilize

(to summarize just switch to an American spelling checker :-)

Regards

[email-masked]

---

From: Matthew Ford <[email-masked]>
Date: Tue, 8 Feb 2011 23:02:56 +0100

Hi,

Thanks for the review. I've noted how/whether I've addressed your comments inline below.

Mat

> - 1 page 4: the beginning should be updated as the forecast was

Updated.

>  [I-D.ietf-tsvwg-port-randomization]  was published as RFC 6056

Updated.

> - 5.2.1.1 page 11: UPnP IGD 2.0 last published last year

Updated.

>  the last sentence about ICMP messages 'in general'.

This section now references RFC5508 for details.

>  (i.e., it only satisfies the ego of the programmer :-).

Identifier was mentioned in the context of routing incoming responses.

>  for the reassembly state.

No change.

> an informative document so a strict interpretation is not required

No change.

> the reference must be updated.

Added ref to RFC5996 in §13. Earlier ref to RFC3947 has been removed after AD comments.

>  IGD 1.0 and IGD 2.0 so it is enough to put the parent reference.

Updated.