Hi Suresh, all, A new version incorporating the requested changes is online:
The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-intarea-nat-reveal-analysis There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-intarea-nat-reveal-analysis-06 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-intarea-nat-reveal-analysis-06 Please see inline. Cheers, Med >-----Message d'origine----- >De : int-area-boun...@ietf.org >[mailto:int-area-boun...@ietf.org] De la part de Suresh Krishnan >Envoyé : dimanche 10 mars 2013 18:56 >À : Internet Area >Objet : [Int-area] NAT reveal analysis IETF Last Call comments > >Hi all, > These comments were received on the IETF discussion list during the >IETF last call. > >http://www.ietf.org/mail-archive/web/ietf/current/msg77707.html >http://www.ietf.org/mail-archive/web/ietf/current/msg77273.html > > >Thanks >Suresh > > > >-------- Original Message -------- >Subject: Re: Last Call: <draft-ietf-intarea-nat-reveal-analysis-05.txt> >(Analysis of Solution Candidates to Reveal a Host Identifier (HOST_ID) >in Shared Address Deployments) to Informational RFC >Date: Mon, 25 Feb 2013 11:33:07 -0800 >From: SM <s...@resistor.net> >To: <i...@ietf.org> > >At 11:06 22-02-2013, The IESG wrote: >>The IESG has received a request from the Internet Area >Working Group WG >>(intarea) to consider the following document: >>- 'Analysis of Solution Candidates to Reveal a Host >Identifier (HOST_ID) >> in Shared Address Deployments' >> <draft-ietf-intarea-nat-reveal-analysis-05.txt> as >Informational RFC >> >>The IESG plans to make a decision in the next few weeks, and solicits >>final comments on this action. Please send substantive comments to the >>i...@ietf.org mailing lists by 2013-03-08. Exceptionally, >comments may be > >My comments should not be read as a statement of support. :-) > >In Section 1: > > "Section 3 discusses privacy issues common to all HOST_ID solutions. > It is out of scope of this document to elaborate on privacy issues > specific to each solution." > >I suggest explaining what "HOST_ID" is. Med: As HOST_ID is introduced in Section 2, the new text is now: Section 3 discusses privacy issues common to all candidate solutions. It is out of scope of this document to elaborate on privacy issues specific to each solution. > >In Section 2: > > "HOST_ID does not reveal the identity of a user, a subscriber or an > application." > >I suggest adding an explanation for that statement. Med: The new text is: HOST_ID is not designed to reveal the identity of a user, a subscriber, or an application. HOST_ID is designed to identify a host under a shared IP address. > >In Section 4.4.1: > > "For HTTP, Forwarded header >([I-D.ietf-appsawg-http-forwarded]) can be > used to display the original IP address when an address sharing > device is involved." > >A HTTP proxy is not an address sharing device in my opinion. Med: The document does not say an http proxy is an address sharing device. Section 4 analyzes the scenario where the address sharing function is able to inject such header. Section 2 says: Within this document, we assume the address-sharing function injects the HOST_ID. > > "The address sharing device has to strip all included Forwarded > headers before injecting their own." > >In Section 4.4.2: > > "Injecting Forwarded header also introduces some implementation > complexity if the HTTP packet is at or close to the MTU size." > >What is a HTTP packet? Med: Changed to HTTP message. > >Regards, >-sm > > > > > > > >_______________________________________________ >Int-area mailing list >Int-area@ietf.org >https://www.ietf.org/mailman/listinfo/int-area > _______________________________________________ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area
