[Int-area] ACTION REQUIRED: Extending working group last call for draft-ietf-intarea-nat-reveal-analysis-02
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
Re: [Int-area] ACTION REQUIRED: Extending working group last call for draft-ietf-intarea-nat-reveal-analysis-02
Support. Regards, Behcet On Wed, Jun 27, 2012 at 10: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
Re: [Int-area] ACTION REQUIRED: Extending working group last call for draft-ietf-intarea-nat-reveal-analysis-02
I support draft-ietf-intarea-nat-reveal-analysis going forward.
I would like the draft to include a citation of MAP
(draft-ietf-softwire-map), and mention MAP in its abstract. This is because
many technologists assume address sharing only occurs with NAT, even though
it occurs with a bunch of other technologies. On this point, I noticed
"application proxies" is mentioned in the abstract (which is good), but
application proxies are not mentioned again in the introduction to
draft-ietf-intarea-nat-reveal-analysis nor mentioned in RFC6269 ("Issues
with IP Address Sharing").
-d
> -Original Message-
> From: int-area-boun...@ietf.org [mailto:int-area-boun...@ietf.org] On
> Behalf Of Suresh Krishnan
> Sent: Wednesday, June 27, 2012 8:57 AM
> To: Internet Area
> Subject: [Int-area] ACTION REQUIRED: Extending working group last call
> for draft-ietf-intarea-nat-reveal-analysis-02
>
> 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
Re: [Int-area] ACTION REQUIRED: Extending working group last call for draft-ietf-intarea-nat-reveal-analysis-02
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
Re: [Int-area] ACTION REQUIRED: Extending working group last call for draft-ietf-intarea-nat-reveal-analysis-02
BTW, the MAP doc cites RFC 6145, which has errors as follows:
1. it sets IPv4 ID=0 when IPv6 lacks a frag header
that will hopefully be possible after ipv4-id-update is final,
but wasn't valid a the time the doc was published
2. copying the low 16 bits of the IPv6 ID field to the IPv4 ID field is
invalid
that field might not follow the ID uniqueness criteria of IPv4
3. the system assumes IPv4 can reassemble 1280 byte packets
but only 576 can be assumed
I've brought these to the attention of the authors...
Joe
On 7/2/2012 1:36 PM, Dan Wing wrote:
I support draft-ietf-intarea-nat-reveal-analysis going forward.
I would like the draft to include a citation of MAP
(draft-ietf-softwire-map), and mention MAP in its abstract. This is because
many technologists assume address sharing only occurs with NAT, even though
it occurs with a bunch of other technologies. On this point, I noticed
"application proxies" is mentioned in the abstract (which is good), but
application proxies are not mentioned again in the introduction to
draft-ietf-intarea-nat-reveal-analysis nor mentioned in RFC6269 ("Issues
with IP Address Sharing").
-d
-Original Message-
From: int-area-boun...@ietf.org [mailto:int-area-boun...@ietf.org] On
Behalf Of Suresh Krishnan
Sent: Wednesday, June 27, 2012 8:57 AM
To: Internet Area
Subject: [Int-area] ACTION REQUIRED: Extending working group last call
for draft-ietf-intarea-nat-reveal-analysis-02
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
___
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area
Re: [Int-area] ACTION REQUIRED: Extending working group last call for draft-ietf-intarea-nat-reveal-analysis-02
As a co-author, I didn't want to remain silent per se, so I'll at least be public in my view. I think the doc is good, but I do take Alissa's concerns to point - it might be preferable to remove section 3.3 and leave this doc as a comparison of solutions, and avoid any recommendation of a way forward at this point. Joe On 6/27/2012 8: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
Re: [Int-area] ACTION REQUIRED: Extending working group last call for draft-ietf-intarea-nat-reveal-analysis-02
On Jul 5, 2012, at 22:48, Alissa Cooper wrote: > 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. Fully agree with Alissa. An comparison of options would be fine. But 3.3 and other text go beyond a comparison. I also don't understand why INTAREA is entertaining work that is clearly intending to define new TCP options. None of the -abdo- drafts have been presented in TCPM or even discussed on the mailing list. (My guess is that the authors know that this would never get traction in TCPM and are venue shopping.) Lars smime.p7s Description: S/MIME cryptographic signature ___ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area
Re: [Int-area] ACTION REQUIRED: Extending working group last call for draft-ietf-intarea-nat-reveal-analysis-02
On 7/6/2012 12:39 AM, Eggert, Lars wrote: On Jul 5, 2012, at 22:48, Alissa Cooper wrote: 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. Fully agree with Alissa. An comparison of options would be fine. But 3.3 and other text go beyond a comparison. I also don't understand why INTAREA is entertaining work that is clearly intending to define new TCP options. None of the -abdo- drafts have been presented in TCPM or even discussed on the mailing list. (My guess is that the authors know that this would never get traction in TCPM and are venue shopping.) FWIW, this doc discusses existing alternatives, including proposed ones that have been documented, based on pros/cons. It doesn't make an assessment of the viability of approaches as ways forward in the IETF. (and I agree it should probably not make any single positive recommendation; it might be OK to indicate which solutions aren't viable, though) Joe ___ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area
Re: [Int-area] ACTION REQUIRED: Extending working group last call for draft-ietf-intarea-nat-reveal-analysis-02
Dear Joe, all, Apologies for the delay to answer (I was out of office). I have no problem to remove Section 3.3 if this is what the WG wants. As a reminder, I added that section after the Paris meeting in accordance with what I heard in the meeting: more voices in favour of adding a recommendation. I sent a notification to the mailing list mid-april to acknowledge this change. Now, I'm waiting for a feedback from the WG to maintain or to remove Section 3.3. Cheers, Med >-Message d'origine- >De : int-area-boun...@ietf.org >[mailto:int-area-boun...@ietf.org] De la part de Joe Touch >Envoyé : vendredi 6 juillet 2012 02:17 >À : Suresh Krishnan >Cc : Internet Area >Objet : Re: [Int-area] ACTION REQUIRED: Extending working >group last call for draft-ietf-intarea-nat-reveal-analysis-02 > >As a co-author, I didn't want to remain silent per se, so I'll >at least >be public in my view. > >I think the doc is good, but I do take Alissa's concerns to point - it >might be preferable to remove section 3.3 and leave this doc as a >comparison of solutions, and avoid any recommendation of a way forward >at this point. > >Joe > >On 6/27/2012 8: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 > ___ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area
Re: [Int-area] ACTION REQUIRED: Extending working group last call for draft-ietf-intarea-nat-reveal-analysis-02
Dear Lars, Please see inline. Cheers, Med >-Message d'origine- >De : int-area-boun...@ietf.org >[mailto:int-area-boun...@ietf.org] De la part de Eggert, Lars >Envoyé : vendredi 6 juillet 2012 09:40 >À : Alissa Cooper >Cc : Internet Area >Objet : Re: [Int-area] ACTION REQUIRED: Extending working >group last call for draft-ietf-intarea-nat-reveal-analysis-02 > >On Jul 5, 2012, at 22:48, Alissa Cooper wrote: >> 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. > >Fully agree with Alissa. An comparison of options would be >fine. But 3.3 and other text go beyond a comparison. Med: FYI I added Section 3.3 after the Paris meeting where I asked the question whether we need to add a recommendation or not. It seems to me I heard more voices for having a recommendation in the document. A notification has been sent to this mailing list in mid-april. Anyway, I'm open to record the consensus of the WG: maintain or remove that section. > >I also don't understand why INTAREA is entertaining work that >is clearly intending to define new TCP options. Med: This draft is not about the TCP option but to analyze a set of solutions to solve a problem already documented in RFC6069. None of the >-abdo- drafts have been presented in TCPM or even discussed on >the mailing list. (My guess is that the authors know that this >would never get traction in TCPM and are venue shopping.) Med: I checked tcpm agenda, draft-abdo will be presented in tcpm in Vancouver. > >Lars ___ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area
Re: [Int-area] ACTION REQUIRED: Extending working group last call for draft-ietf-intarea-nat-reveal-analysis-02
Hi Med, On Thu, Jul 26, 2012 at 2:10 AM, wrote: > Dear Lars, > > Please see inline. > > Cheers, > Med > >>-Message d'origine- >>De : int-area-boun...@ietf.org >>[mailto:int-area-boun...@ietf.org] De la part de Eggert, Lars >>Envoyé : vendredi 6 juillet 2012 09:40 >>À : Alissa Cooper >>Cc : Internet Area >>Objet : Re: [Int-area] ACTION REQUIRED: Extending working >>group last call for draft-ietf-intarea-nat-reveal-analysis-02 >> >>On Jul 5, 2012, at 22:48, Alissa Cooper wrote: >>> 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. >> >>Fully agree with Alissa. An comparison of options would be >>fine. But 3.3 and other text go beyond a comparison. > > Med: FYI I added Section 3.3 after the Paris meeting where I asked the > question whether we need to add a recommendation or not. It seems to me I > heard more voices for having a recommendation in the document. A notification > has been sent to this mailing list in mid-april. Anyway, I'm open to record > the consensus of the WG: maintain or remove that section. > >> >>I also don't understand why INTAREA is entertaining work that >>is clearly intending to define new TCP options. > > Med: This draft is not about the TCP option but to analyze a set of solutions > to solve a problem already documented in RFC6069. > RFC 6069 is about TCP-LCD? Behcet ___ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area
Re: [Int-area] ACTION REQUIRED: Extending working group last call for draft-ietf-intarea-nat-reveal-analysis-02
Hi Behcet, Ooops, I wanted to quote RFC6269. Thanks. Cheers, Med >-Message d'origine- >De : Behcet Sarikaya [mailto:sarikaya2...@gmail.com] >Envoyé : jeudi 26 juillet 2012 18:22 >À : BOUCADAIR Mohamed OLNC/NAD/TIP >Cc : Eggert, Lars; Alissa Cooper; Internet Area >Objet : Re: [Int-area] ACTION REQUIRED: Extending working >group last call for draft-ietf-intarea-nat-reveal-analysis-02 > >Hi Med, >> >>> >>>I also don't understand why INTAREA is entertaining work that >>>is clearly intending to define new TCP options. >> >> Med: This draft is not about the TCP option but to analyze a >set of solutions to solve a problem already documented in RFC6069. >> > >RFC 6069 is about TCP-LCD? > >Behcet > ___ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area
