Subject: [BEHAVE] Minutes from Sept. interim teleconference

From: Dave Thaler <[email-masked]>
Date: Wed, 23 Sep 2009 00:18:13 +0000

Below are the proposed minutes from last week's interim
conf call.  Please send any additions/corrections.
As a reminder, it is also IETF policy to confirm consensus on 
the list, so the WG is invited to review the items listed as 
consensus-among-those-present.

-Dave

BEHAVE Interim meeting minutes, Sept. 17, 2009, 7am-9:10am PDT
Attendance was via WebEx screen sharing and PSTN voice
Chairs: Dan Wing, [email-masked], Dave Thaler, [email-masked]
WebEx recording: https://cisco.webex.com/ciscosales/lsr.php?AT=pb&SP=MC&rID=40376397&rKey=4126d72ee3b4a9cc

Attendees
-----------------
Dan Wing (chair)
Dave Thaler (chair)
Agnes Tow
Bo Zhou
Cameron Byrne
Dan Romascanu
Dean Chung
Fred Baker
Heinrich Haager
Hui Deng
Iljitsch van Beijnum
Jacni Qin
Lin Xiao
Liu Dapeng
Magnus Westerlund
Marcelo Bagnulo
Philip Matthews
Simon Perreault
Teemu Savolainen
Zhen Cao

Notes taken by Dave Thaler

draft-ietf-behave-v6v4-xlate-01: Xing Li
----------------------------------------
Multicast packets reference address format docs
Marcelo - we should do it in a different document, maybe Stig's
Xing - no preference
Magnus - reasonable to push out to a separate doc
Dan - let's talk about this during the DNS64 update on the agenda

Terminology: use of "network-specific prefix (NSP)" vs "LIR prefix"
    The consensus among those present was to use NSP since it applies 
    better to other cases such as home gateways.  The NSP definition 
    still needs some work though.

Terminology: use of "mapped" and "translatable" etc
    The consensus among those present was to not define a new term for 
    normal IPv6 addresses used with stateful translators.
    The term "IPv4-mapped" conflicts with address range, e.g. in sockets API,
    and so another term is needed.

Comments on draft-ietf-behave-v6v4-framework-01: Gang Chen
----------------------------------------------------------
Today there is no generic term for the concept of translation-in-host.
The term "IPv4-adapted-IPv6 implementation" was proposed and discussed.
Fred Baker - not sure why it's useful
Dave - how about changing "implementation" to "host".  Update definition 
    to make it clear it's a term for the host stack, similar to 
    "dual stack host"
Fred/Dan - where would this term be used?
    BIS/BIA update, PNAT
There was no consensus reached about whether adding a term to the
    framework was needed.

Christian Huitema was not able to make it to the interim meeting,
and enough time was requested for discussion of other documents to
fill up the interim meeting, so the discussion on the address-format 
document was deferred to the next interim meeting.

Comments on draft-ietf-behave-v6v4-framework-01: Bo Zhou
--------------------------------------------------------
After some discussion, there was consensus among those present that one 
    can't use "translator" in a definition to distinguish between 
    "Internet" and "a network".
The motivation for wanting to more precisely define the difference seems
    to be something about implementation, although others didn't 
    necessarily agree with this motivation.
Dave - distinction is far more applicable to a deployer than an implementer
Dan - what about just capitalizing "A Network"

Discussion of sentence about "stateful doesn't support IPv4-initiation":
    The concern is this statement doesn't apply to all stateful proposals, 
    e.g. the deprecated NAT-PT.
Dan - change to "<NAT64doc> doesn't support IPv4-initiation"
The consensus among those present was to do that.

Discussion of ALG in framework section 3.1.5:
    Some expressed reservations about not wanting to recommend ALGs.
Dave - add reference that Dan posted to the list - RFC 4924 section 2.3
The consensus among those present was to do that.

draft-ietf-behave-v6v4-xlate-stateful-01: Marcelo Bagnulo
---------------------------------------------------------
Some pending updates still need to be added, specifically around
fragment & MTU handling.
Using the #'s of alternatives from the minutes of the August interim
    meeting, Iljitsch wants 2 but allow people to do 4, but wants more 
    people to speak up.
Dan - chairs can step in and call for consensus.  
ACTION ITEM: Iljitsch to send summary of question to Dan by next week.

Xing - some text should move over to the xlate doc?
Marcelo - anything in common should move, anything specific to stateful 
    should stay
There was agreement among those present on this.  Xing and Marcelo
    will agree over email on which text needs to move.

FTP64 issues: Liu Dapeng
------------------------
The context of the proposal is to introduce FTP client changes that avoid 
    the need for FTP64 in cases where you can change the FTP clients,
    leaving an FTP64 ALG only when you cnanot.   
    There were three sub-topics...

1) How client uses PASV's response messages IPv4 address
The proposal is to just use control channel's IPv4 address.
After some discussion this seemed ok, and Iljitsch agreed to make this change.

2) Which try first: EPSV or PASV?
Proposal is PASV first then fallback to EPSV
This is better if know you're talking to an IPv4 server.
The opposite is better if talking to an IPv6 server.
Dan - if host/app can learn prefixes, it can tell which case and modify 
      behavior 
Dave - don't overconstrain, allow both and leave it up to config or 
       heurtistic like dan said 

3) ALG considerations
Recommend against unless have no choice such as ISP doing translation
And perhaps reference RFC 4924 section 2.3 here too?

draft-ietf-behave-dns64-00: Iljitsch van Beijnum
---------------------------------------------
The only thing needed in DNS64 to make multicast work is a longest prefix 
    match for translation prefixes.
Iljitsch will work with Stig and get text to Andrew by next week or so.

At the conclusion of the meeting, Dan summarized the list of open issues
the chairs need to discuss:
1) IPv4-adapted-ipv6 host terminology
2) IPv4-mapped terminology