Subject: [BEHAVE] adopt draft-van-beijnum-behave-ftp64-06 as WG item

From: "Dan Wing" <[email-masked]>
Date: Thu, 22 Oct 2009 09:49:02 -0700

We are considering adopting draft-van-beijnum-behave-ftp64-06 as a WG document
to meet our milestone "Jan 2010 Submit to IESG: FTP ALG for IPv6/IPv4
translation (std)",
http://tools.ietf.org/html/draft-van-beijnum-behave-ftp64-06

The author believes the document now incorporates all feedback.

Please reply to the list.
-d

---

From: marcelo bagnulo braun <[email-masked]>
Date: Fri, 23 Oct 2009 12:12:47 +0200

I agree with adopting this doc as a WG  item

regards, marcelo

Dan Wing escribió:
> _______________________________________________
> Behave mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/behave
>
>

---

From: liu dapeng <[email-masked]>
Date: Fri, 23 Oct 2009 19:04:26 +0800

We know that there are two drafts discussing the ftp64 issue. Would
the WG consider merging draft-van-beijnum-behave-ftp64 and
draft-liu-behave-ftp64 as the WG document?

BR,
Dapeng Liu

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Fri, 23 Oct 2009 13:10:31 +0200

> draft-liu-behave-ftp64 as the WG document?

Do you feel the current text in draft-van-beijnum-behave-ftp64-06  
doesn't address your previous objections?

---

From: Sheng Jiang <[email-masked]>
Date: Sat, 24 Oct 2009 17:48:29 +0800

Hi,

I support to adopt the draft as WG documentation.

However, the author wrote in the draft: “Versions -05 and -06 of this
document adopts several important design decisions from
[I-D.liu-behave-ftp64].” Should at least one author from
draft-liu-behave-ftp64 deserve to be co-author of this
draft-van-beijnum-behave-ftp64?

Best wishes,

Sheng

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
Of
> Iljitsch van Beijnum
> Sent: Friday, October 23, 2009 7:11 PM
> To: liu dapeng
> Cc: 刘大鹏; 曹振; [email-masked]; Behave Chairs; Dan Wing
> Subject: Re: [BEHAVE] adopt draft-van-beijnum-behave-ftp64-06 as WG item
>

---

From: bo zhou <[email-masked]>
Date: Sun, 25 Oct 2009 00:12:46 +0800

Support Sheng's suggestion.

Regards,

Bo

2009/10/24 Sheng Jiang <[email-masked]>

-- 
Regards,

Bo Zhou
China Mobile

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Sun, 25 Oct 2009 11:41:32 +0100

> draft-van-beijnum-behave-ftp64?

I'm happy that so many of you want work together on the FTP64 document.

However, I would prefer to not add co-authors for the following reasons:

- Having a single author reduces the time needed for coordination so  
progress can be faster.

- Although many people have contributed tests, ideas and suggestions  
(as noted in the acknowledgments), I wrote all the text and I did all  
the presentations at IETF meetings.

However, when the document is adopted as a working group document I  
would be willing to listen to the chairs if they want to suggest  
additional authors if they have important reasons for adding more  
authors.

Iljitsch

---

From: "Dan Wing" <[email-masked]>
Date: Mon, 26 Oct 2009 10:19:29 -0700

Looking at
http://tools.ietf.org/rfcdiff?url2=draft-van-beijnum-behave-ftp64-06.txt and
reviewing draft-liu-behave-ftp64-03, I believe the change caused by
draft-liu-behave-ftp64 was the new paragraph in Section 6, "ALG Functionality"
starting with "On the other hand,".  Is that correct?  If that is all that was
incorporated, it falls below my threshold for adding a second author, and
rewording the Acknowledgements to better acknowledge the contribution seems
adequate along the lines of "Dapeng Liu and Zhen Cao suggested that network
operators encourage upgrading FTP clients rather than deploy an FTP ALG."

-d

> From: Sheng Jiang [mailto:[email-masked]] 
> Sent: Saturday, October 24, 2009 2:48 AM
> To: 'Iljitsch van Beijnum'; 'liu dapeng'
> Cc: '刘大鹏'; '曹振'; [email-masked]; 'Behave Chairs'; 'Dan 
> Wing'; 'Sheng Jiang'
> Subject: RE: [BEHAVE] adopt draft-van-beijnum-behave-ftp64-06 
> as WG item
> 
> Hi,
> 
> > From: [email-masked] 
> [mailto:[email-masked]] On Behalf
> Of
> > Iljitsch van Beijnum
> > Subject: Re: [BEHAVE] adopt 
> draft-van-beijnum-behave-ftp64-06 as WG item
> >

---

From: liu dapeng <[email-masked]>
Date: Tue, 27 Oct 2009 11:03:07 +0800

Hi Dan,

We updated the ftp64 draft:
http://tools.ietf.org/html/draft-liu-behave-ftp64-04.
As you mentioned, attitude toward FTP ALG is one of the ideas that
merged by draft-van-beijnum-behave-ftp64-06.txt; Furthermore, the
handling of FTP client when retrying with PASV command is another
important idea that merged by draft-van-beijnum-behave-ftp64-06.txt.
The original handling method will cause problems and probably does not
work.
We believe that draft-van-beijnum-behave-ftp64-06 still need more improvement,
so we upgrade draft-liu-behave-ftp64-04 to reflect our thoughts more
precisely. We would like the WG to review and comments on this draft
and to see whether it is more suitable to be the working foundation to
further proceed the ftp64 issue in IPv6 transition scenario. If it is
convenient, we would like to present it in the coming meeting(5-10
minutes). Thanks for your comments and kindly help.

BR,
Dapeng Liu

---

From: liu dapeng <[email-masked]>
Date: Tue, 27 Oct 2009 13:04:19 +0800

> - Having a single author reduces the time needed for coordination so
Single author has the problem that it may can not reflect all the
useful opinions that aim to improve the document in time. It may
depends on the single author's preference that whether to adopt the
useful ideas and opinions. From this perspective, it may not help to
quicken the progress since the WG draft should reflect consensus of
the WG .

BR,
Dapeng Liu

---

From: Zhen Cao <[email-masked]>
Date: Tue, 27 Oct 2009 23:40:08 +0800

Hi Dan and All,

Many parts of the document are still very confusing. 1) It did not
clearly specify the target scenario. From the title, people may think
it is talking about IPv6 ftp client communicating with IPv4 server.
But in section.5, it confuses me a lot by this sentence "even if the
client has IPv4 reachability......". 2) ALG problem. Section 6 starts
with ALG but does not specify clearly which case needs ALG and which
does not. 3) Again ALG, multiple protocols need ALG in the NAT64
cases, we cannot specify them all and in fact many protocols related
ALG have not been specified, i wonder if we have a strong motivation
to define FTP Alg in this document. In this case, i do not see much
difference between draft-liu-behave-ftp64-04 and
draft-van-beijnum-behave-ftp64-06.

Thanks and regards,
Zhen

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Tue, 27 Oct 2009 16:45:37 +0100

On 27 okt 2009, at 16:40, Zhen Cao wrote:

> Again ALG, multiple protocols need ALG in the NAT64
> ALG have not been specified,

Which protocols do you feel need ALGs to work through IPv6-to-IPv4  
translators?

Iljitsch

---

From: Zhen Cao <[email-masked]>
Date: Tue, 27 Oct 2009 23:59:25 +0800

> Which protocols do you feel need ALGs to work through IPv6-to-IPv4
RTSP, SIP where there needs SDP to carry the address.

---

From: Andrew Sullivan <[email-masked]>
Date: Tue, 27 Oct 2009 14:57:15 -0400

Dear colleagues,

On Tue, Oct 27, 2009 at 11:40:08PM +0800, Zhen Cao wrote:

> Many parts of the document are still very confusing. 

I'd very strongly prefer that we settle the question asked by the
Chairs ("adopt this document or not?") in one thread; and if another
thread for the discussion of the document is needed, open that thread
for such discussion.

As far as I can tell, the document is appropriate to adopt in order to
form the basis for the WG milestone.  I confess that I find it hard to
get real excited about the milestone itself -- ftp is no longer, in my
opinion, the critical protocol it once was -- but since the WG decided
on the milestone, I think draft-van-beijnum-behave-ftp64-06 is a solid
basis for the WG's work.  I therefore support the adoption.

A

-- 
Andrew Sullivan
[email-masked]
Shinkuro, Inc.

---

From: "Dan Wing" <[email-masked]>
Date: Tue, 27 Oct 2009 14:19:16 -0700

> From: Zhen Cao [mailto:[email-masked]] 
> Sent: Tuesday, October 27, 2009 8:40 AM
> To: Dan Wing
> Cc: [email-masked]; 刘大鹏; 曹振; Behave Chairs
> does not.

Thanks.  I expect those can be resolved as the document progresses
as a WG document.

> 3) Again ALG, multiple protocols need ALG in the NAT64

And are unlikely to be specified. On this topic, BEHAVE's charter says "ALGs
may be
considered only for the most crucial of legacy applications.",
http://www.ietf.org/dyn/wg/charter/behave-charter.html

> i wonder if we have a strong motivation
> to define FTP Alg in this document.

http://tools.ietf.org/html/draft-van-beijnum-behave-ftp64-06#section-6
provides the motivation.  Are you saying you disagree with the text in that
section, or disagree with its conclusion, or something else?

-d

> In this case, i do not see much
> > We are considering adopting 
> draft-van-beijnum-behave-ftp64-06 as a WG document

---

From: Zhen Cao <[email-masked]>
Date: Wed, 28 Oct 2009 13:16:46 +0800

> Thanks.  I expect those can be resolved as the document progresses

Back to Andrew's proposal, I was just raising some concerns on why I
do not support the adoption. I am afraid it is not a solid basis.

---

From: marcelo bagnulo braun <[email-masked]>
Date: Wed, 28 Oct 2009 08:54:32 +0100

Zhen,

from the points you make, it doesn't seem that you have a fundamental
problem with the document but changes that can easily be integrated in
the document, if the WG agreed with them. Since we are only accepting a
WG document and not in WGLC, i don't think the argument is strong not ot
accept the doc as a WG document, it just needs to be improved as any
other doc when accepted as WG document.

Regards, marcelo

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Wed, 28 Oct 2009 11:29:43 +0100

> RTSP, SIP where there needs SDP to carry the address.

I'm not sure about the status of RTSP, but I believe that it's used  
less and less exactly because it doesn't work through NAT44 without an  
ALG...

As for SIP, I believe the consensus is that ALGs create more harm than  
benefit.

The wg consensus is that the use of ALGs should be minimized. I don't  
believe there would be consensus to specify RTSP and SIP ALGs for NAT64.

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Wed, 28 Oct 2009 12:14:09 +0100

> important idea that merged by draft-van-beijnum-behave-ftp64-06.txt.

If I remember correctly, this is the first place this idea is mentioned:

http://www.ietf.org/mail-archive/web/behave/current/msg05940.html

It appears in the -03 version of draft-van-beijnum-behave-ftp64.

> further proceed the ftp64 issue in IPv6 transition scenario.

I read draft-liu-behave-ftp64-04, but I didn't see any places where  
you suggest new ways forward that are very different from draft-van- 
beijnum-behave-ftp64-06, except that the ALG specification is much  
less detailed and no server changes are specified, only client  
changes. Can you please outline your specific suggestions?

(It also seems that draft-liu-behave-ftp64 has taken many ideas from  
draft-van-beijnum-behave-ftp64. In some cases, the wording is even  
quite close.)

---

From: bo zhou <[email-masked]>
Date: Wed, 28 Oct 2009 20:00:22 +0800

Hi Iljitsch,

"minimize" does not mean avoid in my mind.
BTW, you ask "which protocols do you feel need ALGs to work through 6-to-4
translator?"
I guess Zhen want to answer your question using RTSP, SIP as two examples.
I believe more applications rather than RTSP, SIP need to do ALG in such
scenario, but it is really depend on how the user use these applications.
for example, a standard HTTP protocol can include IP address or domain name
inside. if the user choose the IP address filling, then the ALG cannot
avoid. But likely, more user use domain name rather than IP address for HTTP
application which need not ALG in the translator.

regards,

Bo

On Wed, Oct 28, 2009 at 6:29 PM, Iljitsch van Beijnum <[email-masked]>wrote:

> I'm not sure about the status of RTSP, but I believe that it's used less
> and less exactly because it doesn't work through NAT44 without an ALG...
>

-- 
Regards,

Bo Zhou
China Mobile

---

From: bo zhou <[email-masked]>
Date: Wed, 28 Oct 2009 20:02:42 +0800

Hi Marcelo,

In your mind, what's fundamental problem? Could you give us a definition? I
am a little confused.
Thank you very much.

Regards,

Bo

2009/10/28 marcelo bagnulo braun <[email-masked]>

-- 
Regards,

Bo Zhou
China Mobile

---

From: liu dapeng <[email-masked]>
Date: Wed, 28 Oct 2009 21:32:34 +0800

> http://www.ietf.org/mail-archive/web/behave/current/msg05940.html

We propose our idea in:
http://www.ietf.org/mail-archive/web/behave/current/msg06210.html

 At that time, we did not notice whether there was other opinions, but
it is clear that in a long time draft-van-beijnum-behave-ftp64 did not
update to accept this idea, which lead to a solution that can not work
until we post draft-liu-behave-ftp64-00.
That is why we post another draft on this topic. We have to express
our ideas which may improve the design precisely and make sure the
ideas will not be ignored without a specific reason.

> changes. Can you please outline your specific suggestions?

The attitude towards FTP ALG is our idea. So we insist that we need
not to identify too much details about FTP ALG.

Furthermore, it is reasonable to ask the IPv6 FTP client to "change"
since there is no much IPv6 FTP client right now and it is a good time
for us to make a guideline and to let the implementer to know how to
design the IPv6 FTP client to avoid bothering the translation box to
do FTP ALG. I guess that is the meaning why behave WG try to proceed
this document(without this ftp issue may belong to application area).
That idea is very important since it gives the meaning of this
document.

Conversely, require the legacy IPv4 FTP server to change is difficult.
So draft-liu-behave-ftp64-04 does not agree to change IPv4 FTP server.
We do not want to make a specification that no one want to comply.

> draft-van-beijnum-behave-ftp64. In some cases, the wording is even
As you mentioned, you can borrow many other's ideas in
draft-van-beijnum-behave-ftp64,  I also can borrow ideas from others
but I do not use any wording from draft-van-beijnum-behave-ftp64, if
you find any wording that are not appropriate, please kindly to point
it out, I will revise the wording.

> http://www.ietf.org/mail-archive/web/behave/current/msg05940.html

We propose our idea in:
http://www.ietf.org/mail-archive/web/behave/current/msg06210.html

 At that time, we did not notice whether there was other opinions, but
it is clear that in a long time draft-van-beijnum-behave-ftp64 did not
update to accept this idea, which lead to a solution that can not work
until we post draft-liu-behave-ftp64-00.
That is why we post another draft on this topic. We have to express
our ideas which may improve the design precisely and make sure the
ideas will not be ignored without a specific reason.

> changes. Can you please outline your specific suggestions?

The attitude towards FTP ALG is our idea. So we need not to identify
much details about FTP ALG.

Furthermore, it is reasonable to ask the IPv6 FTP client to "change"
since there is no much IPv6 FTP client right now and it is a good time
for us to make a guideline and to let the implementer to know how to
design the IPv6 FTP client to avoid bothering the translation box to
do FTP ALG. I guess that is the meaning why behave WG try to proceed
this document(which may belong to application area). That idea is very
important since it gives the meaning of this document.

Conversely, require the legacy IPv4 FTP server to change is difficult.
So draft-liu-behave-ftp64-04 does not agree to change IPv4 FTP server.
We do not want to make a specification that no one want to comply.

> draft-van-beijnum-behave-ftp64. In some cases, the wording is even
As you mentioned, you can borrow many other's ideas in
draft-van-beijnum-behave-ftp64,  I also can borrow ideas from others
but I do not use any wording from any other documents, if you find any
wording that are not appropriate, please kindly help to point it out,
I will revise the wording.

BR,
Dapeng Liu

Dapeng Liu

---

From: "Dan Wing" <[email-masked]>
Date: Wed, 28 Oct 2009 18:41:09 -0700

> [mailto:[email-masked]] On Behalf Of Zhen Cao
> Sent: Tuesday, October 27, 2009 8:59 AM
> To: Iljitsch van Beijnum
> Cc: [email-masked] WG

For the IPv6 transition, IPv6 endpoints are expected to do the work; that's
part of pushing intelligence to the host -- a long-standing IETF mantra.  I
have written down this expectation in
http://tools.ietf.org/html/draft-wing-v6ops-v6app-v4server-00 (recently
published) which I hope to present in v6ops.  However, the standards for RTSP
and SIP have already said that IPv6 hosts have do the work of IPv6/IPv4
interworking:

Regarding RTSP, please see 
http://tools.ietf.org/html/draft-ietf-mmusic-rtsp-nat-08, which 
extends RTSPv2 using ICE-like mechanisms for NAT traversal, 
including IPv6/IPv4 interworking.

Regarding SIP, note that most deployments today aren't using
ALGs (e.g., Vonage doesn't need an ALG, and works behind in-home
NAT44s successfully).  Rather, SBCs incorporate a 'media 
latching' feature, described in:
http://tools.ietf.org/html/draft-ietf-mmusic-media-path-middleboxes-02 

SIP interworking between IPv4 and IPv6 is also accomplished,
in the field, using SBCs.

Regarding SIP and its IPv6/IPv4 interworking in standards, see:
http://tools.ietf.org/html/draft-wing-behave-nat64-referrals-01#section-2.1
http://tools.ietf.org/html/draft-ietf-sipping-v6-transition-07
http://tools.ietf.org/html/draft-ietf-sipping-nat-scenarios-09#section-6

As IPv6-capable RTSP endpoints and SIP endpoints are built,
they are expected to comply with those specifications.  Most of
those I-Ds that I cited above are relatively mature and a few 
are in RFC editor's queue.

Which brings us to:  why do we need an FTP64 ALG?  Because IPv6
FTP clients send EPSV (in compliance with RFC2428), but EPSV does
not work in practice with deployed IPv4 FTP servers.  IPv6 FTP
clients aren't new -- they exist in deployed web browsers (IE,
Firefox, Opera, Safari, Chrome) and thus, if an IPv6-only network
is deployed today, it would break FTP.  An FTP64 ALG is the only
way for those deployed FTP clients to work with IPv4 FTP
servers.  Once those FTP clients are upgraded to work well
with IPv4 FTP servers, the FTP64 ALG is no longer needed.

-d

---

From: "Dan Wing" <[email-masked]>
Date: Wed, 28 Oct 2009 18:53:21 -0700

(This message contains the same content as my earlier post at
http://www.ietf.org/mail-archive/web/behave/current/msg07192.html.  But I
changed the subject line so we can quit the 'adopt FTP64' thread, as this
diverges considerably from 'adopt FTP64'.  Sorry about that; I had intended to
change the Subject line before replying, but neglected to do that.)

-d

---

From: Sheng Jiang <[email-masked]>
Date: Thu, 29 Oct 2009 11:06:24 +0800

Hi, Iljitsch,

Taking one coauthor from the carriers, who would be the major user of ftp64,
would potentially make your work better. Actually, their work has already
improved your draft as you took input from their draft and the discussion
with them. It should do no harm for you, I guess. 

Sheng

> [mailto:[email-masked]] On Behalf Of marcelo bagnulo braun
> Sent: Wednesday, October 28, 2009 3:55 PM
> To: Zhen Cao
> from the points you make, it doesn't seem that you have a 
> fundamental problem with the document but changes that can 
> easily be integrated in the document, if the WG agreed with 
> them. Since we are only accepting a WG document and not in 
> WGLC, i don't think the argument is strong not ot accept the 
> doc as a WG document, it just needs to be improved as any 
> >>> clearly specify the target scenario. From the title, people may 
> >>> think it is talking about IPv6 ftp client communicating 
> with IPv4 server.
> >>> client has IPv4 reachability......". 2) ALG problem. Section 6 
> >>> starts with ALG but does not specify clearly which case needs ALG 
> >>> and which does not.
> >>>       
> >> Thanks.  I expect those can be resolved as the document 
> progresses as 
> >> a WG document.
> >>     
> >

---

From: marcelo bagnulo braun <[email-masked]>
Date: Thu, 29 Oct 2009 07:44:10 +0100

What strikes me is that you seem to be conditioning the support for
acceptance of this doc as WG document to the fact whether and additional
editor is added to the document or not.

These seems different issues imho. Any document needs to reflect the WG
consensus whether it has one or many _editors_

The question at hand is whehter this document is or not a good starting
point to do that.

Regards, marcelo

Sheng Jiang escribió:
>> draft-van-beijnum-behave-ftp64-06 as WG 
>>     
>>>>> item
>>>>>
>>>>> Hi Dan and All,
>>>>>
>>>>> Many parts of the document are still very confusing. 1) 
>>>>>           
>> It did not 
>>     
>>>>> But in section.5, it confuses me a lot by this sentence 
>>>>>           
>> "even if the 
>>     
>>> Back to Andrew's proposal, I was just raising some concerns 
>>>       
>> on why I 
>>

---

From: "Dan Wing" <[email-masked]>
Date: Thu, 29 Oct 2009 00:29:49 -0700

> [mailto:[email-masked]] On Behalf Of bo zhou
> Sent: Wednesday, October 28, 2009 5:00 AM
> To: Iljitsch van Beijnum
> Cc: [email-masked] WG; Zhen Cao
> BTW, you ask "which protocols do you feel need ALGs to work 
> through 6-to-4 translator?"
> I believe more applications rather than RTSP, SIP need to do 
> ALG in such scenario, but it is really depend on how the user 
> use these applications. for example, a standard HTTP protocol 
> can include IP address or domain name inside. if the user 
> choose the IP address filling, then the ALG cannot avoid.

An ALG is not necessary for that problem.  I describe a workaround
for that specific problem in
http://tools.ietf.org/html/draft-wing-behave-http-ip-address-literals-01
which does not use an ALG.  However, as noted that draft, my workaround 
may not properly handle Java or Javascript which contains IPv4 
address literals -- but neither will an ALG (unless the ALG is
going to interpret Java and Javascript, which *significantly* 
increases its complexity and CPU hit to solve a small problem; 
see below).

> But likely, more user use domain name rather than IP address for 
> HTTP application which need not ALG in the translator.

Yes.  I analyzed the likelyhood by looking at the top 1,000,000 
domains per alexa.com, results are at:
http://tools.ietf.org/html/draft-wing-behave-http-ip-address-literals-01#appen
dix-B
which says:

...
   An examination of Alexa's top 1 million domains [Alexa] at the end of
   August, 2009, showed 2.38% of the HTML in their home pages contained
   IPv4 address literals.  
...
   Of the top 1 million websites at the end of August, 2009, 3455
   (0.35%) of them are IPv4 address literals (e.g., http://192.0.2.1).
...

-d

> regards,
>  
> Bo 
> 
> 
>  
> On Wed, Oct 28, 2009 at 6:29 PM, Iljitsch van Beijnum 
> 	I'm not sure about the status of RTSP, but I believe 
> that it's used less and less exactly because it doesn't work 
> through NAT44 without an ALG...
> 	
> 	As for SIP, I believe the consensus is that ALGs create 
> more harm than benefit.
> 	
> 	The wg consensus is that the use of ALGs should be 
> minimized. I don't believe there would be consensus to 
> specify RTSP and SIP ALGs for NAT64. 
>

---

From: Sheng Jiang <[email-masked]>
Date: Thu, 29 Oct 2009 17:24:11 +0800

My opinions here is simple: without the contributions from China Mobile, the
draft is not good enough to be adopted as WG document though its initial
contents are valuable and important. I support the current draft to be
adopted for its contents without conditions. I also think single author does
not respect the others who makes important contributions.

Furthermore, after the draft be accepted as WG document, future refine work
is still needed. A coauthor from China Mobile, who has proofed understanding
ftp64 issues, will only do good for the work.

I don't understand the insistence why rejects a helpful coauthor. For me, if
an expert who understands my draft well wants to coauthor my draft with
valuable contributions, he will be really appreciated.

Best regards,

Sheng

> Sent: Thursday, October 29, 2009 2:44 PM
> To: Sheng Jiang
> Cc: [email-masked]; 'Zhen Cao'; '刘大鹏'; '曹振'; 'Behave 
> Chairs'; 'Dan Wing'
> What strikes me is that you seem to be conditioning the 
> support for acceptance of this doc as WG document to the fact 
> whether and additional editor is added to the document or not.
> 
> These seems different issues imho. Any document needs to 
> reflect the WG consensus whether it has one or many _editors_
> 
> The question at hand is whehter this document is or not a 
> good starting point to do that.
> 
> Regards, marcelo
> 
> 
> 
> Sheng Jiang escribió:
> > Hi, Iljitsch,
> >
> > Taking one coauthor from the carriers, who would be the 
> major user of 
> > ftp64, would potentially make your work better. Actually, 
> their work 
> > has already improved your draft as you took input from 
> their draft and 
> > the discussion with them. It should do no harm for you, I guess.
> >
> > Sheng
> >
> >   
> fundamental 
> >> problem with the document but changes that can easily be 
> integrated 
> >> in the document, if the WG agreed with them. Since we are only 
> >> accepting a WG document and not in WGLC, i don't think the 
> argument 
> >> is strong not ot accept the doc as a WG document, it just 
> needs to be 
> >> improved as any other doc when accepted as WG document.
> >>
> >> Regards, marcelo
> >>
> >>
> >> Zhen Cao escribió:
> >>

---

From: marcelo bagnulo braun <[email-masked]>
Date: Thu, 29 Oct 2009 11:14:19 +0100

so, you do agree to take this doc as a WG item, right?

Sheng Jiang escribió:
>>>>>>> starts with ALG but does not specify clearly which case 
>>>>>>>               
>> needs ALG 
>>     
>>>>>>> and which does not.
>>>>>>>       
>>>>>>>           
>>>>>>>

---

From: Kai Ju <[email-masked]>
Date: Thu, 29 Oct 2009 22:59:35 +0800

jiang sheng's pre condition is quite clear, by including other author, this
draft could be adopted.

2009/10/29 marcelo bagnulo braun <[email-masked]>

---

From: marcelo bagnulo braun <[email-masked]>
Date: Thu, 29 Oct 2009 16:07:57 +0100

that s exactly the condition that i find very strange for adopting a
document... either the document is a good base for a WG document or not,
irrespectively of the editors that the document has.

the basis for accepting a WG document should be technical reasons not
whether you like or not the editor list.

regards, marcelo

Kai Ju escribió:
> jiang sheng's pre condition is quite clear, by including other author,
> this draft could be adopted.
>
> 2009/10/29 marcelo bagnulo braun <[email-masked]
> <mailto:[email-masked]>>
>
>     >> From: [email-masked] <mailto:[email-masked]>
>     >> [mailto:[email-masked]
>     <mailto:[email-masked]>] On Behalf Of marcelo bagnulo braun
>     >> Cc: [email-masked] <mailto:[email-masked]>; 'Zhen Cao'; '刘大
>     鹏'; '曹振'; 'Behave
>     >> Chairs'; 'Dan Wing'
>     >>>> From: [email-masked] <mailto:[email-masked]>
>     >>>> [mailto:[email-masked]
>     <mailto:[email-masked]>] On Behalf Of marcelo bagnulo braun
>     >>>> Cc: 刘大鹏; 曹振; [email-masked] <mailto:[email-masked]>;
>     Behave Chairs; Dan Wing
>     >>>>> 2009/10/28 Dan Wing <[email-masked] <mailto:[email-masked]>>:
>     >>>>>
>     >>>>>
>     >>>>>
>     >>>>>>
>     >>>>>>
>     >>>>>>
>     >>>>>>> From: Zhen Cao [mailto:[email-masked]
>     <mailto:[email-masked]>]
>     >>>>>>> Cc: [email-masked] <mailto:[email-masked]>; 刘大鹏; 曹
>     振; Behave Chairs
>     >>>>> [email-masked] <mailto:[email-masked]>
>     >>>> [email-masked] <mailto:[email-masked]>
>     >> [email-masked] <mailto:[email-masked]>
>     [email-masked] <mailto:[email-masked]>

---

From: Andrew Sullivan <[email-masked]>
Date: Thu, 29 Oct 2009 11:12:19 -0400

> jiang sheng's pre condition is quite clear, by including other author, this

I'm not sure how our Chairs prefer to work these matters, but it is my
understanding that the editors of a draft which is to be a WG product
normally serve at the pleasure of the Chairs.  Therefore, I don't
believe the WG participants are in a position to insist on one or
another editor for the draft as a condition of making it a WG work
item.  "Is the _draft_ to be worked on by the WG?" is the question, as
I understand it.  The Chairs might well decide that someone previously
entirely unconnected to this effort will hold the pen, and that's
something they get to choose after the WG has expressed its
willingness to adopt the work item.

Best regards,

A

-- 
Andrew Sullivan
[email-masked]
Shinkuro, Inc.

---

From: "Dan Wing" <[email-masked]>
Date: Thu, 29 Oct 2009 09:42:33 -0700

> > jiang sheng's pre condition is quite clear, by including 
> > other author, this draft could be adopted.
> 

Yes, the question at hand is 'shall we adopt this document'.  I
did not ask 'who wants to be an author'.

I have not seen a substantive objection since I asked a week ago
(Oct 22).

-d

---

From: "Dan Wing" <[email-masked]>
Date: Thu, 29 Oct 2009 09:52:43 -0700

(sorry to come back to this Monday post, but I wanted to follow up on this
specific email.)

> From: liu dapeng [mailto:[email-masked]] 
> Sent: Monday, October 26, 2009 8:03 PM
> To: Dan Wing
> Cc: [email-masked]; Iljitsch van Beijnum; 刘大鹏; 曹振; 
> [email-masked]; Behave Chairs; bo zhou

specific text was not cited so I can only guess that you are referring to this
text,

   Based on the survey, this document recommends that all FTP servers
   and client implement EPSV and that IPv6 FTP clients are updated to
   retry with PASV when EPSV fails under the assumptiont that they are
   communicating through an IPv6-to-IPv4 translator.

which originally appeared in
http://tools.ietf.org/html/draft-van-beijnum-behave-ftp64-03, published May
19.  http://tools.ietf.org/html/draft-liu-behave-ftp64-00 was published August
19.  Was there an earlier email where you had suggested that FTP servers retry
with PASV when EPSV fails?

> The original handling method will cause problems and probably does not

Please substantiate how/where it would break, with details.  I have run tests
against public IPv4 FTP servers, published the results of those tests to
BEHAVE, and made Perl code available so others could repeat the tests.  It's
all at ftp://ftpeng.cisco.com/dwing/ftp-epsv.

-d

> > starting with "On the other hand,".  Is that correct?  If 
> that is all that
> > was

---

From: liu dapeng <[email-masked]>
Date: Fri, 30 Oct 2009 01:16:20 +0800

Hi, Dan
thanks for the discussion, please see inline.
> all at ftp://ftpeng.cisco.com/dwing/ftp-epsv.

Actually, I mean the using of only control connection's IP address to
establish data connection when retry with PASV and gets a response
from server. The original document propose the client to test whether
to have IPv4 connection, if it has IPv4 connection, then it recommends
to use its IPv4 address to make the data connection. This may have
potential problems as we discussed before: If the client has an
private IPv4 connection it will not succeed using it to make the data
connection.

BR,
Dapeng

---

From: liu dapeng <[email-masked]>
Date: Fri, 30 Oct 2009 01:34:33 +0800

Hi Dan,

> all at ftp://ftpeng.cisco.com/dwing/ftp-epsv.

It reminds me that there is another issue that we are not very clearly:

when trying with EPSV command, it may result to a long delay from the
server. according to previous discussion we guess that it may caused
by the middle box that does not handling the control channel
correctly, but we can not make sure what exactly happening. Since we
have CNGI (China Next Generation Internet, which is a wide area IPv6
test network) and also have NAT-PT deployed, I am happy to make an
experiment to see what exactly happening. If it is needed, I can also
implement an IPv6 FTP client running code which complies with the
ftp64 document to see whether this solution could really work properly
and to see whether there is other issues that have not been
identified.

BR,
Dapeng

---

From: "Dan Wing" <[email-masked]>
Date: Thu, 29 Oct 2009 11:05:01 -0700

> Sent: Thursday, October 29, 2009 10:35 AM
> To: Dan Wing
> Cc: [email-masked]; [email-masked]; 刘大鹏; bo zhou; 曹振; 
> Behave Chairs
> Subject: Re: [BEHAVE] draft-van-beijnum-behave-ftp64-06 and 
> PASV retrying [was Re: adopt draft-van-beijnum-behave-ftp64-06]
> 
> Hi Dan,
> 
> > specific text was not cited so I can only guess that you 
> are referring to
> > this
> > text,
> >
> > 19.  http://tools.ietf.org/html/draft-liu-behave-ftp64-00 
> was published
> > August
> > 19.  Was there an earlier email where you had suggested 
> that FTP servers
> > retry

You didn't answer that question.

> > Please substantiate how/where it would break, with details. 
>  I have run
> > tests

I still don't understand.  You had written "The original handling method will
cause problems and 
probably does not work."  What, specifically, was the "original handling
method", and what, specifically, is your fix?

Testing is easy, just use the Perl code that I have provided to the community.
EPSV doesn't work with ftp.dell.com and times out:

  > perl ftp-epsv.pl ftp.dell.com
  ftp.dell.com              PASV: Ok   EPSV: Timeout   00:22

That has been known since I posted the results of my testing and Iljitsch
incorporated text into
http://tools.ietf.org/html/draft-van-beijnum-behave-ftp64-03.

-d

---

From: liu dapeng <[email-masked]>
Date: Fri, 30 Oct 2009 02:36:12 +0800

Hi Dan,
Thanks for the discussion,
I guess I reply your question in the previous mail... anyway, please
see inline below.

the email discussion is:

> method", and what, specifically, is your fix?

The draft-van-beijnum-behave-ftp64-04 proposed that:"However, the
server will respond to the PASV command with an IPv4 address that the
client must use to connect to for the data connection.  If the client
has IPv4 reachability, it SHOULD set up a
data connection towards the IPv4 address."
This may have potential problems: If the client has an
private IPv4 connection it will not succeed using it to make the data
connection.

> Testing is easy, just use the Perl code that I have provided to the

But since there is no NAT64 or NAT-PT in the network, is it better to
write a IPv6 FTP client and with NAT64 or NAT-PT deployed in the IPv6
network to make sure the test is comply with the ftp64 document?

> http://tools.ietf.org/html/draft-van-beijnum-behave-ftp64-03.

Yes, I know that this issue has been identified long time before, but
it seems that we do not know very clearly what exactly cause this
problem, right? that is the motivation that I want to do the
experiment.

BR,
Dapeng

---

From: Stig Venaas <[email-masked]>
Date: Thu, 29 Oct 2009 15:47:29 -0700

> Please reply to the list.

I support adopting this. While I'm sure there may be some improvements
possible, I think it's already a very solid document.

Stig

---

From: Zhen Cao <[email-masked]>
Date: Fri, 30 Oct 2009 11:44:49 +0800

> I have not seen a substantive objection since I asked a week ago

Note that i raised some questions and do not think the current draft
is a solid basis, although chairs do not think they are fundamental
issues. I do not know what can be a 'fundamental' issue.  Thanks.

---

From: "Dan Wing" <[email-masked]>
Date: Fri, 30 Oct 2009 08:39:57 -0700

> issues.

Yes, I made note of the comments, and as I indicated in my reply
they can be corrected.  Documents are not perfect -- or complete --
when adopted by the working group.  Once the working group adopts
the document, the working group has change control over the 
document and can direct the authors to make the changes the WG
deems necessary.

> I do not know what can be a 'fundamental' issue.  Thanks.

For example, the technique described in the document will 
not work as expected / desired.

-d

---

From: Tina TSOU <[email-masked]>
Date: Sat, 31 Oct 2009 15:30:57 +0800

Hi,

Iljitsch has done good job. draft-van-beijnum-behave-ftp64 is his own draft, it is up to him to add one more author or not.

In my mind, the draft from Iljitsch includes some content from draft-liu-behave-ftp64.

1, regarding return PASV command, if the response message from the server includes the address and the port, use the IPv6 rather than address of the client to set up the connection.

2, Regarding ALG, draft-van-beijnum-behave-ftp64 seems accepting the concept that first to have FTP client and server to avoid ALG issues, if it is not possible, can then provide how to implement ALG.

There could be something addressed in draft-ietf-behave-ftp64-00. 

1)      Refine the scenario

2)      Describe more details about the ALG part

The WG chair will tell the editor, presumably Iljitsch, who should be the co-author (s) if there is any, based on the WG consensus.

B. R.
Tina
http://tinatsou.weebly.com/contact.html

  ----- Original Message ----- 
  From: Dan Wing 
  To: 'Zhen Cao' 
  Cc: 'Andrew Sullivan' ; [email-masked] 
  Sent: Friday, October 30, 2009 11:39 PM
  Subject: Re: [BEHAVE] adopt draft-van-beijnum-behave-ftp64-06 as WG item

  -d