Meeting date : 5/17/2012 Attendees --------- Dave Thaler Dean Cheng Jouni Korhonen Marc Blanchet Muthu Arul Ram Mohan R Senthil Sivakumar Simon Perreault Teemu Savolainen Tina Tsou Wes Eddy Notetaker: Senthil Sivakumar - Agenda bashing - no comments - Recharter discussion - Dave -------------------------------------- Dave Thaler showed approved SUNSET4 charter and proposed BEHAVE recharter (http://www.ietf.org/mail-archive/web/behave/current/msg10377.html), with a couple of open questions that will be discussed by the BEHAVE & SUNSET4 chairs and ADs on an upcoming conf call. He observed that one BEHAVE chair (Dave), one SUNSET4 chair (Marc), and one AD (Wes) was at this interim meeting. Senthil - CGN MIB is strongly dependent on the NAT MIB, so it might be helpful to keep them in the same WG. Marc - CGN MIB should be where it is (currently behave), unless decided otherwise. - NAT64 heuristic discovery - Teemu -------------------------------------- Teemu presented updates and open items on draft-ietf-behave-nat64-discovery-heuristic. Dave: Heterogeneous hosts could send PTR queries and hence PTR records may have to be present. Action - Teemu to check on list with Cameron etc about whether NAT64 operator on network allowing heterogenous hosts SHOULD have a PTR record Simon - Echo requests to do the connectivity check is not fool proof, so some other mechanism like STUN should be suggested. Dave - Leave the actual protocol/tool to do the connectivity check open. Action - Teemu - Remove the ICMPv6-specific text to do the connectivity checks, and leave as implementation-specific, since implementations already have various ways to do this. Dave - Are there any special needs for the two addresses that are requested from IANA? Teemu - The only requirement is no synthesis is needed on these addresses. That is, the 2 addresses don't been to be routable but shouldn't be in a set that a DNS64 would filter. Action - Teemu to add some text to IANA Considerations around the requirement on the two IPv4 addresses requested. WGLC will start once the above changes are made to the draft. NAT MIB - Simon ------------------------ Simon presented status of the draft-ietf-behave-nat-mib. Currently the proposed recharter has separate milestones (with same date) for NAT64 MIB vs CGN MIB. It was observed that the CGN MIB was potentially in the overlap area between SUNSET4 and BEHAVE. This is another topic for the respective chairs and ADs to discuss. Currently draft-ietf-behave-nat-mib only contains generic MIB content, no NAT64 or CGN MIB content yet. - Discussion around two documents on MIB vs one. One for CGN and one for generic NAT. - Dave - it is easier to claim conformance if there are two documents instead of one. - Marc - let the editors decide what is the best way forward. - Simon - need more input from WG. IPFIX IE's for logging - Senthil ------------------------------------------- Senthil presented history and status of draft-sivakumar-behave-nat-logging. Draft-00 was IPFIX specific, whereas later drafts were more agnostic. The proposed charter item is IPFIX specific so -00 is the most relevant version. Senthil - if draft-sivakumar-behave-nat-logging-00 shall be considered for the milestone item. Dave - Yes, at first glance. It seems reasonable to ask for WG adoption (once the proposed charter is approved). Senthil - Should this draft be focusing only on IPFIX. Simon, Dave - yes - it should target IPFIX and the IEs. Senthil - if the formats/messages to be defined by the draft. Dave - It should be up to the implementation to decide those, the goal should be two devices can interoperate when using these IPFIX IEs (the sender and the receiver). Senthil - What is in scope: CGN, NAT44, NAT64, DS-lite, PCP, others? Dave - NAT44, NAT64 and CGN are in scope and the others are not. Senthil to post a draft -04 with these changes incorporated. Dave expects that version to be the one we ask the WG to adopt to meet the new milestone. Consent freshness - Muthu ------------------------------------- draft-muthu-behave-consent-freshness is a proposal to use STUN for verifying consent to accept traffic, and later revoking said consent, sort of like an ICMP error. Currently being discussed in rtcweb WG. Dave - Does your consent freshness proposal require STUN to run even after the session establishment, even between hosts with direct connectivity between them? Normally it's just for ICE negotiation. Muthu - Yes. Dave - it is still not clear where this document will find its home. RADIUS extensions - Dean ----------------------------------- Dean presented status of draft-cheng-behave-cgn-cfg-radius-ext Senthil - how does port forwarding work in this model without the external address? Dean - It should work the same way PCP works. Senthil & Dean to discuss offline. Dean - Asking to adopt the document Dave - to discuss further with Dan, ADs and SUNSET4 chairs when they have the conference call about division of responsibility between the WGs