Subject: Re: [IPFIX] [new-work] WG Review: Recharter of Behavior Engineering forHindrance Avoidance (behave)

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Tue, 22 May 2012 14:21:10 +0200

Hi, 

Two comments: 

1. If I got it right, Information Elements will be defined specifically
to meet logging requirements. It would be good to be explicit on this in
the deliverables list as well. 

2. It is not clear what the plans are concerning the MIB module(s). Will
there be two separate MIB modules to be used as needed with the existing
MIB module defined in RFC 4008? Or eventually there will be one MIB
module that updates the one defined in 4008 and adds NAT64 and CGNs
capabilities. 

Thanks and Regards,

Dan

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of IESG Secretary
> Sent: Tuesday, May 15, 2012 8:53 PM
> To: [email-masked]
> Subject: [new-work] WG Review: Recharter of Behavior Engineering
> forHindrance Avoidance (behave)
> 
> A modified charter has been submitted for the Behavior Engineering for
> Hindrance Avoidance (behave) working group in the Transport Area of
the
> IETF.  The IESG has not made any determination as yet.  The modified
> charter is provided below for informational purposes only.  Please
send
> your comments to the IESG mailing list ([email-masked]) by Tuesday, May
> 22, 2012.
> 
> Behavior Engineering for Hindrance Avoidance (behave)
> -----------------------------------------------------
> Current Status: Active
> Last updated: 2012-05-10
> 
>  Chairs:
>      Dan Wing <[email-masked]>
>      Dave Thaler <[email-masked]>
> 
>  Transport Area Directors:
>      Wesley Eddy <[email-masked]>
>      Martin Stiemerling <[email-masked]>
> 
>  Transport Area Advisor:
>      Wesley Eddy <[email-masked]>
> 
>  Mailing Lists:
>      General Discussion: [email-masked]
>      To Subscribe:       https://www.ietf.org/mailman/listinfo/behave
>      Archive:            http://www.ietf.org/mail-archive/web/behave
> 
> Description of Working Group
> 
> The working group creates documents to enable IPv4/IPv4 and IPv6/IPv4
> NATs to function in as deterministic a fashion as possible.
> 
> To support deployments where communicating hosts require using
> different address families (IPv4 or IPv6), address family translation
> is
> needed to establish communication. In BEHAVE's specification work on
> this topic it will coordinate with the V6ops WG on requirements and
> operational considerations.
> 
> "An IPv4 network" or "an IPv6 network" in the descriptions below refer
> to a network with a clearly identifiable administrative domain (e.g.,
> an
> enterprise campus network, a mobile operator's cellular network, a
> residential subscriber network, etc.). It will also be that network
> that
> deploys the necessary equipment for translation.
> 
> BEHAVE will finish four scenarios: (1) An IPv6 network to IPv4
> Internet, (2) an IPv6 Internet to an IPv4 network, (3) an IPv6 network
> to an IPv4 network, and (4) an IPv4 network to an IPv6 network.
> 
> Specifically, BEHAVE will update the NAT MIB (RFC 4008) to be
> consistent with the management aspects of its IPv6/IPv4 NAT solutions,
> and specify IPFIX information elements to meet logging requirements,
> reusing existing elements, if possible.
> 
> In addition, when a NAT (such as a NAT64 in the "An IPv6 network to
> IPv4 Internet" scenario) serves multiple subscribers, inter-subscriber
> fairness issues arise.  As such, BEHAVE will complete its work on
> Carrier Grade NAT requirements for such scenarios, and update the NAT
> MIB as needed to meet such requirements.  BEHAVE will not, however,
> standardize IPv4-specific behavioral mechanisms.
> 
> The following scenarios remain in scope for discussion, but will not
be
> solved by BEHAVE:
> 
> * An IPv4 network to IPv6 Internet, i.e. perform translation between
> IPv4 and IPv6 for packets in uni- or bi-directional flows that are
> initiated from an IPv4 host towards an IPv6 host. The translator
> function is intended to service a specific IPv4 network using either
> public or private IPv4 address space.
> 
> * IPv4 Internet to an IPv6 network, i.e. perform translation between
> IPv4 and IPv6 for packets in uni- or bi-directional flows that are
> initiated from an IPv4 host towards an IPv6 host. The translator
> function is intended to service a specific IPv6 network where selected
> IPv6 hosts and services are to be reachable.
> 
> This group will also provide reviews of any work by the MBoneD WG on
> multicast translation, including control traffic (IGMP and MLD),
> Single
> Source Multicast (SSM) and Any Source Multicast (ASM).
> 
> If the WG deems it necessary, BEHAVE will revise RFCs previously
> published by BEHAVE.
> 
> Goals and Milestones
> 
> Done	Submit BCP that defines unicast UDP behavioral requirements for
>         NATs to IESG
> Done	Submit a BCP that defines TCP behavioral requirements for NATs
>         to IESG
> Done	Submit a BCP that defines ICMP behavioral requirements for NATs
>         to IESG
> Done	Submit informational that discusses current NAT traversal
>         techniques used by applications
> Done	Submit BCP that defines multicast UDP
> Done	Submit revision of RFC 3489 to IESG behavioral requirements for
>         NATs to IESG
> Done	Submit informational document for rfc3489bis test vectors
> Done	Submit experimental document that describes how an application
>         can determine the type of NAT it is behind
> Done	Submit BCP document for DCCP NAT behavior
> Done	Determine relative prioritization of the four translation cases.
>         Documented in IETF74 minutes.
> Done	Determine what solutions(s) and components are needed to solve
>         each of the four cases. Create new milestones for the
>         solution(s) and the components. Documented in IETF74 minutes.
> Done	Submit to IESG: relaying of a TCP bytestream (std)
> Done	Submit to IESG: relay protocol (std)
> Done	Submit to IESG: TURN-URI document (std)
> Done	Submit to IESG: IPv6 relay protocol (std)
> Done	Submit to IESG: framework for IPv6/IPv4 translation (info)
> Done	Submit to IESG: stateless IPv6/IPv4 translation (std)
> Done	Submit to IESG: stateful IPv6/IPv4 translation (std)
> Done	Submit to IESG: DNS rewriting for IPv6/IPv4 translation (std)
> Done	Submit to IESG: IPv6 prefix for IPv6/IPv4 translator (std)
> Done	Determine need and scope of multicast 6/4 translation
> Done	Submit to IESG: FTP ALG for IPv6/IPv4 translation (std)
> Jul 2012  Submit to IESG: large scale NAT requirements (BCP)
> Done	Submit to IESG: Analysis of NAT-PT considerations with IPv6/IPv4
>         translation (info)
> Jul 2012  Submit to IESG: avoiding NAT64 with dual-stack host for
>           local networks (std)
> Done    Submit to IESG: host-based NAT46 translation for IPv4-only
>         applications to access IPv6-only servers (std)
> Nov 2012  Submit to IESG: updates to NAT MIB for NAT64 (std)
> Nov 2012  Submit to IESG: updates to NAT MIB for CGNs (std)
> Nov 2012  Submit to IESG: IPFIX information elements (std)
> _______________________________________________
> new-work mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/new-work

---

From: Benoit Claise <[email-masked]>
Date: Thu, 24 May 2012 17:05:51 +0200

Hi Dan, Wes,

> the deliverables list as well.
Isn't it: Nov 2012 Submit to IESG: IPFIX information elements (std)?
> module that updates the one defined in 4008 and adds NAT64 and CGNs
If you're concerned about two deliverables

While there is apparently one entry in the charter text:

I have the same concern.

Regards, Benoit.
>>       Dan Wing<[email-masked]>
>>       Dave Thaler<[email-masked]>
>>
>>       Wesley Eddy<[email-masked]>
>>       Martin Stiemerling<[email-masked]>
>>
>>   Transport Area Advisor:
>>       Wesley Eddy<[email-masked]>
>>
>>   Mailing Lists: