Draft minutes from San Diego

Many thanks to Eric Burger for taking minutes at IETF 60.  Please
post any corrections, etc. to the mailing list.

Thanks,

Melinda

Minutes of the midcom session at IETF60
---------------------------------------

San Diego, California, USA, Thursday August 5 2004, 15:30-17:30

midcom minutes 4 August 2004

Eric Burger, scribe

AGENDA ITEM: Document Status

Protocol evaluation is in RFC Editor's queue.
The semantics document has been accepted by the IESG and
will shortly enter the RFC Editor's queue.

AGENDA ITEM: Midcom MIB - Juergen Quittek

The document is draft-ietf-midcom-mib-02

Issue #1: MIB Structure Changes
Have a semantics table + add on tables

One thought: merge Firewall Configuration table and
Capabilities table.

Should we remove Session Table?
. Session table is a hack to implement session model in SNMP, which has 
no
concept of session.
. Two existing MIBs can do what Session Table does (Target MIB and/or
Notification MIB)
General consensus from floor to remove Session Table


Issue #2: How to integrate MIDCOM MIB into Firewall Configuraiton
. All MIDCOM rules have same precedence
. MIDCOM rules only have "allow" rules, overlapping rules result in 
opening
of all requested ports, which satisfies all clients
. Firewall people do not see world this way, but can live with it

Q: So if I have rule, "open for source address *" and "open for source
address foo", is there any conflict?
A: No: both clients' requests satisfied

Consistent behavior with IPSP MIB


Issue #3: Notification Subscription
Lots of hacks to make Session Table work, like BITS object
Resolution: Target MIB / Notification MIB just works


Issue #4: Idempotency
Losing SNMP message means policies can remain active longer than 
requested
lifetime.
Currently using remaining lifetime to support failover (surviving 
controller
sees how much time is left).
But SNMP stack semantics imposes problems, based on long timeouts for
retransmissions.
Need to store total lifetime.
So, should we store total lifetime at client and server?

No preference from room.

Also have other Idempoency problems with Session Table, but they would 
go
away if use Notification MIB.


Issue #5: MaxIdleTime
For default value, should we use native NAT value (presumably 
provisioned at
NAT) or impose one?  If we use native NAT value, we will need a way for 
the
midcom client to determine value of timer

Tom T: Midcom has adequate provision for limiting lifetime of sessions. 
Thus
MaxIdleTime is a nuisance for implementers and client applications

Bob P: Wants to have MaxIdleTime, and have the default be native NAT 
value.
"midcom is a guest of the NAT."  Clients will expect NAT to behave like 
NAT
in "default" situations.

Suresh: Agrees with Bob

Melinda: Applications tend to only set value in special cases

Vote:
  Use box native MaxIdleTime: 4
  No MaxIdleTime: 2
  Do not care: everyone

Will take to the list.


Issue #6: MaxIdleTime for PRR
Should we have MaxIdleTime for Policy Reserve Rule?

Suresh: This is important because PRR allocates bindings
Melinda: Why is it important to have parameter in addition to normal
lifetime parameter?
Suresh: Because it is a property
Bob: Can have multiple PRR/PER updates, e.g., do PRR with minimum set, 
then
set MaxLifeTime later

Vote:
  Mandatory to be in PRR: 0
  Optional to be in PRR: 3
  Not in PRR: 3

Will take to the list.


Issue #7: Naming Conflict
MIDCOM: "internal/inside" & "external/outside"
NAT: "privateSource/privateDestination" & 
"publicSource/publicDestination"

Melinda: NAT MIB will be published first. Its terminology wins.
Jon P: Does not really matter what we call objects



Other issues:

Any use for midcomRuleNatService?  No discussion
Missing midcomInsideInterface and midcomOutsideInterface.  No discussion

RuleLifetime & RuleMaxIdletim: What happens if different rules for 
policy
rules use the same resource?

Suresh: Several clients send policy requests that map to overlapping
resources.  Do we take maximum of MaxIdleTimes?  If so, the clients 
will not
know what the actual value is.  Thus we need some reporting.


August is holiday season.  Thus next revision will be in September.  
Because
of that, August is a good time to review the documents.

Plea from Melinda to review the documents in August!