Subject: [midcom] Draft minutes from IETF 56

From: Melinda Shore <[email-masked]>
Date: Tue, 01 Apr 2003 12:06:25 -0500

I've appended the draft minutes from the meeting in San
Francisco.  Please give them a read and post any additions,
corrections, etc. to the mailing list.  Many thanks to Tom
Taylor for his excellent notes.

Melinda

-------- 

Draft IETF 56 MIDCOM minutes, reported by Tom Taylor
<[email-masked]>.

MIDCOM met for one hour on Tuesday afternoon, 18 March 2003.  Melinda
Shore <[email-masked]> chaired the meeting.

1. Agenda-bashing
=================

The agenda was accepted as proposed.

2. Status update
================

STUN has now been published as RFC 3489.

The protocol evaluation document is scheduled to be through
WG last call in May 2003, and we appear to be on schedule.

It looks like first draft of the MIDCOM MIB document is
pretty well on schedule (March 2003).

3.  MIDCOM MIB
==============

MIDCOM is operating on the hypothesis that the MIDCOM
transport protocol will be SNMPv3.  A design team consisting
of Mary Barnes <[email-masked]> (Editor), David
Harrington <[email-masked]>, and Martin Stiemerling
<[email-masked]> has begun work on the
MIDCOM MIB.

Mary presented the initial report on the status of the
design team's work.  The team is generally agreed on the
applicability of the NAT MIB to the MIDCOM work.  It has
been looking at other MIBs (listed in Mary's charts) to see
which modules or parts thereof meet the MIDCOM requirements.

One of the charts showed the sets of MIBs potentially
applicable at the middlebox, but also at the MIDCOM policy
decision point (PDP).  Several policy-related MIBs are
applicable at the PDP and are of importance to the
successful operation of MIDCOM, but are outside the scope of
the WG.

Juergen Quittek <[email-masked]> asked what aspects of
the Policy Coordination and Policy MIBs the design team
would tackle.  David Harrington took the floor to respond.
[I missed something here] David recommends using templates
rather than a script base.

Juergen asked whether the diagram (which showed a "MIDCOM
Interface" function sitting atop a number of service
configuration MIBs relating to the actual middlebox device
operation) indicated that the MIDCOM MIB sits on top of the
service configuration MIBs?  Mary Barnes responded that
MIDCOM is viewed as a coordination function amongst these
MIBs.  Subsequent discussion drew a clarification that the
"Application Requests" from the MIDCOM agent to the
middlebox are carried by SNMPv3.

The design team's goal is to make a baseline document
available shortly.  The team needs immediate feedback before
they dig more deeply.

At this point David Harrington took discussion in a new
direction.  He noted that the question has been asked: why
MIDCOM does not use XMLConf (XML-based configuration)
instead of SNMP?  It is clear that operators do not use
SNMPv3 to do configuration now.  There is a concern that
operators won't turn on SNMPv3 SETs to allow MIDCOM to work.
The IESG response to this proposition has been to suggest
that thought be given to the general situation before doing
detailed MIDCOM MIB work.

Based on the outcome of the netconf BOF at this meeting,
prospects look good for XMLConf to go ahead.  Melinda asked
what would make us think that operators will turn on
XMLConf.  Jonathan Rosenberg <[email-masked]>
stated that they would do so because XMLConf would be much
cheaper to run.

David Harrington noted that we could think of the current
work as design of an information model before doing a data
model.  The work won't be wasted if care is taken by the
XMLConf design group to allow reuse of existing information
modelling.

Bert Wijnen <[email-masked]> offered the opinion that
some of the MIDCOM MIB work going forward may be wasted.
Definitely operators are not interested in using
COPS/COPS-PR, and are using CLI rather than SNMP for
configuration.  Maybe 60-70% of the people in the room at
the netconf BOF had read the XMLConf document -- an
amazingly high proportion compared with typical IETF
participation.  There was substantial operator support for
development of an XMLConf approach to configuration.  Bert,
as Operations Area AD, does not require writable objects in
MIBs -- a change in heart from two years ago.  The MIDCOM WG
should take this into account.

Melinda Shore confessed herself a bit surprised.  Bert
responded that an Operations Area open meeting is scheduled
for Thursday.  There will probably be an AD statement on the
configuration topic then.

Jonathan Rosenberg expressed a concern over whether the
MIDCOM information model would be reusable.  Basically we
have a good understanding of the problem now.  He doesn't
want to do work that will be obsolete.  What are the
detailed reasons that operators do not enable SNMPv3 SET?
Bert replied that there was no point in going into the
reasons; we just have to accept the fact.  The operators are
not using it.  In contrast, the cable and ATM worlds do use
it.

Christian Huitema <[email-masked]> reminded the
meeting that the original perceived MIDCOM target was
enabling enterprise applications to run across firewalls.
The focus is on enterprise and real-time operations.  This
is in some contrast to configuration, which is typically a
batch process.  Bert agreed that netconf is addressing a
different environment.  Christian remarked that the main
problem is to convince enterprise network operators to allow
a server to punch holes in the firewall in real time.

Jonathan Rosenberg remarked that SNMP was selected as the
MIDCOM candidate partly because it would be there anyway.
It looks like this premise was dubious.  David Harrington
replied that SNMP would still be there for monitoring.
XMLConf will be there for configuration.  The XMLConf group
would like to reuse the MIB modules which were designed with
config in mind.  The implication is that XMLConf will be
compatibile with SNMPv3.  Jonathan rejoined that we are
still facing a situation of reduced motivation to use
SNMPv3.

Marcus Brunner <...> responded that we already have a pretty
good idea of the information that has to go back and forth
(the semantics).  We can fairly easily create an SNMP module
now, then use the same source for XML.  Juergen Quittek
agreed that it should be easy given the semantics already
defined.  He sees it as worthwhile to do the MIB now.

Brian Carpenter <...> remarked that SNMPv3 SETs won't work
too well in enterprise environments with internal
firewalls/NATs.  There is a chicken-and-egg situation where
MIDCOM would be needed to enable MIDCOM.  David Harrington
noted that SNMPv3 itself will help to some extent.

Brian stated that there is a job of persuasion to do before
operators will allow MIDCOM to run.  Tom Taylor added that
it is clear that as part of the task of persuading operators
to allow MIDCOM to function, someone has to do a good job of
designing the policy controls to keep applications within
their intended limits when MIDCOM is present.

4. Semantics document
     draft-ietf-midcom-semantics-01.txt
======================================

Martin Stiemerling reviewed the latest changes to the MIDCOM
semantics draft.  The main one has been to downgrade the
role of groups.  He has alaso made some revisions to the
conformance statements.

Open issues:
   Is wildcarding of IP addresses needed?
   More details on capability information sent by middlebox during session 
establishment.
   Whether explicit support for other protocols besides UDP and TCP is needed.
   Whether the middlebox should offer a choice of encryption methods for 
authentication during session establishment.
   Fuller security considerations.
   Possible addition of agent-supplied parameters to restrict usage of pinhole?

Martin presented an explanation of the requirement for the
Policy Rule Reserve (PRR) operation.  As subsequent
discussion showed, the rtequirement for address reservation
got confused with the IP wildcarding issue.

Jonathan Rosenberg pointed out that PRR as shown in Martin's
example won't work with early media.  IP wildcards are
essential.  Jonathan was supported by Christian Huitema, who
invoked the principle that one shouldn't embed policy
decisions (prohibition of cones in favour of pinholes) in
the design of the protocol.  Jonathan further noted that
forking could also result in blocked media if wildcarding is
not allowed.

Juergen Quittek advanced the counter-argument that if IP
address wildcarding is allowed, it will always be used, and
there will be no incentive to restrict firewall openings to
the minimum width necessary.  Christian Huitema repeated his
point that this was a policy issue which should not be
settled in advance by the protocol.

Bob Penfield argued that the key point is that the agent
needs to handle the two directions of media flow separately.
Reservation is appropriate for the outgoing direction, but
wildcarding is required for the incoming flow --
particularly since the source of early media can differ from
the source of media sent after answer.

5. Wrapup
=========

The Chair terminated discussion at this point, as the
meeting time had expired.  As usual with MIDCOM, there will
be discussions with the IESG on how to proceed.
_______________________________________________
midcom mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/midcom