Last Modified: 2004-09-29
Done | submit Internet-Drafts of framework, architecture and interfaces documents to IESG for publication as Informational RFCs | |
Done | Submission of STUN document for standards-track publication | |
Done | Submission of pre-midcom document describing protocol for NAT traversal using relay for standards-track publication | |
Done | Submission of document evaluating existing IETF protocols against midcom framework and requirements for an Informational RFC. | |
Done | An analysis of the existing mibs and initial list of mibs (or portions of mibs) that need to be developed submitted to WG | |
Done | Semantics document submitted to IESG for publication as informational RFC | |
Done | Initial mibs ID submitted | |
Jun 04 | Mib documents submitted to IESG |
RFC | Status | Title |
---|---|---|
RFC3303 | I | Middlebox Communication Architecture and framework |
RFC3304 | I | Middlebox Communications (MIDCOM) Protocol Requirements |
RFC3489 | PS | STUN - Simple Traversal of UDP Through Network Address Translators |
Minutes of the midcom session at IETF 61
---------------------------------------- Washington, DC, USA, Tuesday, November 9 at 1300-1400 The meeting proceeded as per agenda from agenda bashing through brief mention of three docs currently in RFQ Editor Queue. The only substantive matters during the course of the meeting were the following: In Juergen's update on MIB progress relative to ~~.mib_03.txt, he reported an Open Issue around session table. He offered to go into details, but there were no takers to drill into the specifics of this despite Juergen's invitation. The item is reportedly in Wes' hands. As Wes was not present, no commitment from him was available at meeting time. Next, Suresh spoke on an Open Issue regarding address tuples in MIDCOM scenarios. When the topology is endpoint-A0 .. A1-middle box-A2 .. A3-endpoint Dispute is wrt input parameters (a0,a3) vs (A0, A1) or (A2, A3) Suresh explains: Semantics I-D (A0, A3), most common case, A1 = A3 -- i.e. a0,a3 and a0, a1 have identical values. A series of questions did not clarify matters. Suresh claims a0,a1 defines session terminal points, chair and others saw issue as a0,a3 as session terminal points. Chair asked Suresh to describe a failure scenario to clarify matters. He provided Twice NAT case as example. Conclusion: is there's no consensus on the semantics here. Item is to be directed to mailing list. Suresh indicated that this issue was not expected to be amenable to consensus in the course of a meeting. It will go to list, and Suresh will initiate thread, including clear scenarios. Idempotency: Lifetime can have I failures. SNMP introduces some wrinkles around e.g. lifetime extension requests. SNMP can re-send extension requests in cases where requests are lost, resulting in longer than intended openings. Recommendation: Reduce retransmit time to below smallest lifetime extension request time. Alternatively, suppress retransmit altogether. This solution places burden on requestor to decide what to do as they will be informed immediately upon message loss. Action items: Adding section 7.2 Final decision on session table vs smnp notification mib Add further recommendation on avoiding I problems (see above) Change from A0,A3 semantics. Proposal was to do this by next mtg. But Chair says this is too long. Let's get this resolved ASAP. Conclusion is Doc is to be set by next mtg. Suresh will get his notes out to list w/in the next couple of weeks. It was observed that only a couple of people had read the MIB doc. |