With the changes to this draft in the -02 version, I'm having a little trouble seeing its purpose. It basically now seems like a shell for the recommendation in 3.3, with the analysis stuffed into appendices. But given that there is no stable proposal for the actual TCP option to be implemented, what is the purpose for advancing this document right now? I think I've heard that folks "needed to know what to implement," but does this document really resolve that problem given that even within the space of TCP-option-based solutions for this, there are multiple different proposals, none of which has been standardized? This document made more sense when it was just a comparison of the different potential solutions spaces.
Some other comments: Section 2 claims that for all solutions analyzed, the draft explains what the HOST_ID is. I don't think this is true for the TCP option solution for the application header solution. Even the specific solution proposals for both of those (draft-wing-nat-reveal-option or draft-ietf-appsawg-http-forwarded) are not specific about the limits to which IDs can be inserted. Section 3.1: Is this really specifying requirements for all solutions? Is that sort of a self-fulfilling prophecy for a document that already has a solution chosen? Given that the Forwarded header is being standardized, it seems like references to XFF should be reduced to places where existing deployments are being discussed (as opposed to encouraging the use of XFF, e.g., in A.8.1, "service providers...can enable the feature of injecting the XFF header"). As a general matter I think it would be helpful for this document to be reviewed by some appsarea folks and/or the authors of draft-ietf-appsawg-http-forwarded. It seems like A.8.1 and A.8.2 contradict each other about whether header information is preserved through multiple address sharing functions. Also, if XFF is in such widespread use, the question of what to do when the TCP option and the XFF header conflict seems like something that needs to be resolved. It seems odd to reference "earlier versions" of draft-wing-nat-reveal-option in A.5.2 rather than just explaining why this option is limited to SYN. This seems like an artifact of the oddness of having a whole document just to recommend an as-yet-unspecified solution. Cheers, Alissa On Jun 27, 2012, at 11:57 AM, Suresh Krishnan wrote: > Hi all, > The WGLC on this draft ended with no comments at all. In this context, > we cannot assume that silence equates to consent. In order for this > draft to progress, we need people to read the draft and provide their > opinions on whether the draft is ready. To enable people to comment, the > last call period is extended until Friday July 6, 2012. > > Thanks > Suresh and Julien > > On 06/08/2012 10:06 AM, Suresh Krishnan wrote: >> Hi all, >> This message starts a two week intarea working group last call on >> advancing the draft about Analysis of Solution Candidates to Reveal a >> Host Identifier (HOST_ID) in Shared Address Deployments as an >> Informational RFC. The draft is available at >> >> http://www.ietf.org/id/draft-ietf-intarea-nat-reveal-analysis-02.txt >> http://tools.ietf.org/html/draft-ietf-intarea-nat-reveal-analysis-02 >> >> Substantive comments and statements of support/opposition for advancing >> this document should be directed to the mailing list. Editorial >> suggestions can be sent directly to the authors. This last call will >> conclude on June 22, 2012. >> >> Regards, >> Suresh & Julien >> _______________________________________________ >> 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 > _______________________________________________ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area
