Minutes for BEHAVE at interim-2012-behave-2
minutes-interim-2012-behave-2-1

Meeting Minutes Behavior Engineering for Hindrance Avoidance (behave) WG
Title Minutes for BEHAVE at interim-2012-behave-2
State Active
Other versions plain text
Last updated 2012-03-25

Meeting Minutes
minutes-interim-2012-behave-2

   Minutes of Behave interim meeting February 16, 2012

Attendees
=========
Dave Thaler (notetaker)
Dan Wing
Andrew Sullivan
Arifumi
Gang Chen
Jouni Korhonen
Marc Petit-Huguenin
MED
Simon Perrault
Suhas Nandakumar
Teemu Savolainen
Reinaldo Penno
Cathy Zhou
Kengo Naito
Marc Blanchet
JF Tremblay
Linfeng John Zheng
Xing Li
Dan Romascanu
Senthil Sivakumar
Tine Tsou

===

Simon Perrault - NAT MIB
---
CGN (with LSN requirements)
NAT64
no DNS64 because no DNS server MIB
"4008 is inadequate in many ways"
    terminology
    no search, alarms
    TCP/UDP only
    not implementable on many implmentations according to vendors
current draft is about ds-lite, which will move to softwires
discussion with vendors requires face-to-face time
some design team discussion
Dan: would like to see bis version, doesn't support pools on public side
Reinaldo: have implemented RFC 4008 and extended considerably.  Supports new
    MIB for CGN/NAT realities
Should 4008bis obsolete or update RFC 4008
PROPOSED CONSENSUS: 4008bis obsoletes not updates RFC 4008
    (2 people for, none against)
    only 1 person spoke up (Reinaldo) as representing an implementation or 
    possibility
Should NAT64 additions be in separate doc or same doc
PROPOSED CONSENSUS: No preference, up to authors as to whether NAT64 objects
    are in same doc
Simon: Should 4008bis include CGN features or be in a separate draft?
Reinaldo: CGN in same draft as NAT64 might not work?
Thaler: separate CGN from 4008bis
Marc Blanchet: keep drafts separate and combine at last minute as needed

===
Reinaldo - 4787/5382/5508bis (TCP/UDP/ICMP)
---
requirement for endpoint-independent filtering (EIF) generates derived 
    requirements
some are updates to values or clarifications
some are brand new
example: creating TCP state for track sequence numbers have per-TCP session 
    state even when mapping is static, if implementation does that then 
    need to mitigate security state attack
If endpoint-independent mapping (EIM) exists for TCP, can a UDP packet use 
    the mapping?
Senthil: TCP reset handling is ambiguous
Address Pooling Paired - can you use ports from another IP when you're out 
    of ports?
transitory (half open/closed) idle-timeout: RFC requires 4 minute min.
Reinaldo proposed allowing it to be set lower because some implementations 
    provide such a knob.
Dan: which of these issues cause interop problems if we don't clarify them?
    or are these just quality of implementation issues?
Dave: sounds like quality of implementation
Reinaldo: document the security issues
Dave: For example, bar for changing the MUST NOT (4 minutes) is higher 
    because it was a consensus document
Simon: many items came from list discussion on CGN requirements to not forget 
    about them
Arifumi: transitory idle timeout related to time-wait state
ACTION: chairs to review document and send questions for the WG to discuss 
    to the list

===
Senthil - CGN logging

Main feedback was to define a transport protocol to carry the info
no answer from the list on preference on which protocol
so planning to use IPFIX (one person in meeting last IETF suggested syslog 
    though)
IEs are not well defined, so making clarifications
barring any feedback, will use binary
Simon: can you estimate log size?
Senthil: about 30 bytes per mapping in a normal case
Dan: how compressable is it?
Senthil: don't know
Dave: this is about on-the-wire not a log-on-disk
Dan: there's been complaints about lots of data storage per subscriber but 
    haven't seen anyone talking about compression
Dan: how many NAT records can fit in the same message on the wire?
ACTION: Senthil to add to doc how many NAT records can fit in the same 
    message on the wire
Suhas: a lot of duplicated information?

===
Suhas - TURN URI

Context is RTCWeb
TURN server may be hard-coded in every RTCWeb client (browser) OR provisioned
    in javascript to the client
Dave: we got pushback against URI before.  So why URI and not something else 
    like a JSON structure?
Marc: URI wasn't standardized before because there was no use case where URI
    was needed at the time
ACTION: authors to get rtcweb chairs to comment on URI vs. JSON object vs.
    whatever
Dan: haven't seen discussion on the Behave WG list, and if past experience
    is an indicator, there probably won't be

===
Chairs planning for another interim in 2 weeks or so (sometime around March 2)