Subject: [midcom] Fwd: RE: midcom minutes

From: Melinda Shore <[email-masked]>
Date: Fri, 04 Jan 2002 15:09:50 -0500

Many, many thanks to Tom and to Brian.  Please post comments
to the mailing list.

Melinda

>From: "Tom-PT Taylor" <[email-masked]>
>To: "'Melinda Shore'" <[email-masked]>
>Cc: "Brian Stucker" <[email-masked]>
>Subject: RE: midcom minutes
>Date: Thu, 3 Jan 2002 17:47:22 -0500 
>X-Mailer: Internet Mail Service (5.5.2653.19)
>
>Here are the draft minutes.  I had help in fleshing those out, from Brian Stucker. 
>
>Draft MIDCOM Minutes 
>Recorded by Tom Taylor and Brian Stucker 
>
>MIDCOM met 7:30-10:00pm Monday, December 10.  Melinda Shore <[email-masked]> was Chair. 
>
>1. Agenda 
>   ====== 
>
>The proposed agenda was accepted without change. 
>
>2. Alternative Midcom Approach 
>   (draft-shore-friendly-midcom-00.txt) 
>   ==================================== 
>Melinda Shore presented the advantages of using an approach based on the RSVP model. 
>Open issues: 
> - doesn't function with mediated signalling (gatekeeper, proxy) 
> - keying 
> - protocol selection. 
>
>Question: how open is the Working Group to changing its model? 
>
>Christian Huitema <[email-masked]> expressed his opposition to the proposal.  The Working Group has had one year of discussion and has arrived at a consensus on requirements.  We cannot throw that away.  Addressing the proposed use of RSVP as a model, he pointed out that RSVP could never solve the issue of authentication along the path.  Moreover, RSVP requires that both ends be aware of each other.
>
>Jonathan Rosenberg <[email-masked]> argued that Melinda was working on a new problem, which should be addressed by a new BOF.  There is no single solution to all cases, and her proposal would present issues for third party control.
>
>Cedric Aoun <[email-masked]> pointed out that route discovery is important, and needs to be part of the MIDCOM solution. 
>
>Melinda responded that the solutions proposed up to now all involve putting routing information into the agents, and this is a problem.
>
>Further discussion supported the view that Melinda was proposing a new problem which should be handled by a separate Working Group.  There was some argument over whether this effort should be sequential or parallel.  Scott Bradner, Transport Area Director, provided a final view of consensus: to continue along the lines already established by the Working Group.
>
>3. Rechartering 
>   ============ 
>
>Melinda Shore suggested the next step: we need comparison documents for protocol selection.  Cedric Aoun <[email-masked]> reminded the group of the existence of an analysis of COPS (draft-aoun-midcom-cops-00.txt) and Megaco (draft-sct-midcom-megaco-00.txt).  He wondered if discovery could be added as a work item.  Cullen Jennings <[email-masked]> opposed this broadening of the effort.  The Chair ruled that the Working Group has not done requirements and framework for discovery, so it is out of scope.
>
>3.1 Pre-MIDCOM 
>    ---------- 
>
>Leslie Daigle discussed IAB concerns with the pre-MIDCOM work.  At the time of the MIDCOM meeting the IAB was divided and had no consensus position.  MIDCOM was to be a topic for the IAB meeting the next day, and they might be able to report an outcome at the IAB plenary Thursday night.  The fundamental issue is that the workarounds go around the intended architecture.  The key points the WG should be aware of are to recognize that pre-MIDCOM is a short term fix, and to make sure it doesn't get in the way of the target architecture.  One major concern is that even pre-MIDCOM solutions will take ages to deploy, and will be around forever once they are deployed.
>
>Rohan Mahy <[email-masked]> asked if the IAB is concerned with operation in the here and now?  The response was that the concern is whether the pre-MIDCOM effort will lead to a fix whose cost and lifetime don't merit the effort.  The IAB wants to make sure the right 20% of functionality doesn't get done.
>
>Christian Huitema asked if the IAB had a concern that ultimate MIDCOM as opposed to pre-MIDCOM could block IPv6 address deployment.  Leslie Daigle was unable to speak for the IAB at this point.  Rohan Mahy asked if SHIPWORM (draft-ietf-ngtrans-shipworm-03.txt) is a concern to IAB.  The answer was that SHIPWORM will be discussed.
>
>Eliot Lear <[email-masked]> expressed the suspicion that TURN will take longer to implement than people expect.  The weighing of concerns may be better done in the IRTF or IAB than in the IETF.  Jonathan Rosenberg restated the IAB concern: make sure not too much effort goes into the short-term solution.  There is an upper bound to the WG's effort on this item.
>
>Brian Carpenter <[email-masked]> noted that SHIPWORM has the useful property that it preserves layer separation, thereby reducing complexity.  We should bear the same principle in mind for other work.
>
>The Chair brought the meeting back to the basic question: how does the WG go forward? 
>
>Pete Cordell <[email-masked]> asked if the IAB would decide within the week.  The response was that it is hard to assign a probability that the IAB would reach a position quickly.
>
>Allison Mankin, Transport Area Director, reported that there had been some IESG soul-searching on the question of whether the WG should have been given the-Midcom task.  The bce of IESG opinion is still that it will have worthwhile results.  The Area Directors are looking for the room's opinion: keep pre-MIDCOM in the Working Group or move it out (e.g. relegate to individual RFCs or various other solns). Scott Bradner noted that multiple standards-track RFCs for this problem might not be viewed favourably.
>
>Jonathan expressed fear that if we defer the work application intelligence will continue to be added in NATs and firewalls rather than in a more suitable location.
>
>By show of hands, there was not overwhelming consensus to keep the pre-MIDCOM work item.  The Chair ruled that meeting would continue its agenda on the assumption we keep pre-MIDCOM in the WG, but the decision will be verified on the list.  She noted that the pre-MIDCOM work item has proved more difficult than expected -- the original milestone date was October.
>
>4. MIDCOM-Unaware NAT/Firewall Traversal 
>   (draft-sen-midcom-fw-nat-00.txt) 
>   ===================================== 
>
>Mary Barnes <[email-masked]> presented. 
>
>Benefits 
>-------- 
> - works for enterprise networks 
> - minimizes the impact and knowledge required in clients 
> - additions to SIP are limited to a new lightweight SIP PING method and a new Proxy-Require tag 
> - existing rather than a new protocol is used between the Media Proxy  and the SIP proxies 
> - network configuration for this solution is simple 
> - Media Proxy has additional potential uses beyond NAT passage 
> - NAT bindings are not carried in signalling messages. 
>
>Issues 
>------ 
> - solution is SIP-specific 
> - expensive in terms of network resources 
> - requires the use of symmetric RTP 
> - impacts enterprise firewall policy. 
>
>The Nortel IPR claim associated with this draft was noted in subsequent discussion. 
>
>5. Traversal of non-Protocol Aware Firewalls & NATS 
>   (draft-davies-fw-nat-traversal-01.txt) 
>   ========================================== 
>
>Steve Davies <[email-masked]> presented. 
>
>Benefits 
>-------- 
>
>The primary argument offered was that FANTOM is consistent with the long-term MIDCOM solution.  The first slide showed the similarity of the FANTOM arch to the expected MIDCOM final result.  Steve argued from that similarity that the short and long-term protocols should be the same, implying an easy transition.  He stated that the FANTOM solution can be deployed anywhere, and can work with all firewall/NAT combinations.
>
>Issues 
>------ 
>Requires additional media hops.  Midcom will fix that. 
>
>An associated IPR claim was noted in subsequent discussion. 
>
>
>6. STUN and TURN 
>   (draft-rosenberg-midcom-stun-00.txt) 
>   (draft-rosenberg-midcom-turn-00.txt) 
>   ==================================== 
>
>Jonathan Rosenberg presented. 
>
>STUN Benefits 
>------------- 
>
> - avoid media triangulation 
> - simpler servers 
> - additional uses -- discovery, allocation, diagnostics 
> - new function, useful even after Midcom 
> - covers items where Midcom has issues: NAT upgrade, virus vulnerability of controller, configuration complexity (residential case)
>
> - IF deployed in symmetric-based enterprise, the advance to full Midcom is easier. 
>
>STUN Issues 
>----------- 
> - does not handle the symmetric case 
> - vulnerable in a residential environment to virus infections which turn off NAT operation. 
>
>TURN Benefits 
>------------- 
> - simplicity 
> - limited feature set helps deal with IT concerns 
>
>TURN Issues 
>----------- 
> - can't run servers -- allows only one inbound association 
> - can't send to arbitrary places from the same socket 
> - association is initiated by the server rather than the client, reversing the usual client-server approach. 
>
>Jonathan indicated that in his view these outweigh the benefits of TURN. 
> - limitations, but may be useful in specific situations 
>
>7. Discussion 
>   ========== 
>
>7.1 IPR 
>------- 
>Scott Bradner clarified the IETF position on IPR.  Disclosure is not an issue: in the case of the Sen and Davies drafts, it has been made as required.  The decision on adoption  of the technology is up to the Working Group.
>
>The Chair asked the authors of the various drafts whether they have IPR disclosures to make. 
>Jonathan Rosenberg and Rohan Mahy said they had none.  Mary Barnes referred to the statement in the Semn draft.  Christian Huitema indicated the possibility that CalTech may have revealed prior art on its web page two years ago.
>
>7.2 Decision Rules 
>------------------ 
>
>The Chair asked what decision rules the group should use to pick a pre-MIDCOM solution.  There was agreement that the group should not make an arbitrary choice, and a suggestion that STUN should be part of the final solution.  The group needs requirements against which to judge the proposals.
>
>The point was made that identification of different network environments means different solutions have to be combined.  Another speaker countered that applications inherit an even more complex environment as a result of making these distinctions.
>
>The Chair suggested that this was a matter of refining scope more than requirements.  One question was whether pre-MIDCOM should deal with NATs only, or also firewalls?
>
>The Chair summed up by noting that the MIDCOM framework and requirements are going to the IESG for comment.  They will be input to the rechartering discussion.  It is probable that pre-Midcom will remain with the Working Group.  Pre-MIDCOM seems to include STUN plus whatever falls out of the scope definition.

_______________________________________________
midcom mailing list
[email-masked]
http://www1.ietf.org/mailman/listinfo/midcom

---

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 04 Jan 2002 20:59:45 -0500

Comments on a few points:

>>By show of hands, there was not overwhelming consensus to keep the
>>
> pre-MIDCOM work item.  The Chair ruled that meeting would continue its
> agenda on the assumption we keep pre-MIDCOM in the WG, but the decision
> will be verified on the list.  She noted that the pre-MIDCOM work item
> has proved more difficult than expected -- the original milestone date
> was October.

My recollection was that two questions were asked - the first, whether 
people wanted a pre-midcom work item to be done, to which there was good 
consensus. The second question was whether people thought it had to be 
done in the midcom group, and there was not strong consensus on that item.

>>- vulnerable in a residential environment to virus infections which
>>
> turn off NAT operation. 

This is backwards, my point was that stun is nicely immune to viruses, 
since it is not a general allocation protocol as midcom is.

>>- association is initiated by the server rather than the client,
>>
> reversing the usual client-server approach. 

The last point was not an issue, it was merely a statement of fact, and 
in fact a benefit (this was how we prevent users from running servers).

>>The Chair summed up by noting that the MIDCOM framework and
>>
> requirements are going to the IESG for comment.  They will be input to
> the rechartering discussion.  It is probable that pre-Midcom will remain
> with the Working Group.  Pre-MIDCOM seems to include STUN plus whatever
> falls out of the scope definition.

More specifically, I recall consensus that stun was a good thing, in 
addition to a symmetric solution, either turn/fantom/sen. In particular, 
I recall that both Paul Francis and Steve Davies spoke in favor of 
moving forward with stun in addition to some kind of symmetric solution. 
I hope Paul or Steve will correct me if they believe I have 
misrepresented their statements.

-Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.            72 Eagle Rock Avenue
Chief Scientist                         First Floor
dynamicsoft                             East Hanover, NJ 07936
[email-masked]                 FAX: (973) 952-5050
http://www.jdrosen.net                  PH:  (973) 952-5000
http://www.dynamicsoft.com