[IESG-AGENDA-DIST] Summarized Agenda for the 2011-03-17 IESG Teleconference
IESG Secretary <iesg-secretary@ietf.org> Thu, 10 March 2011 23:21 UTC
Return-Path: <wwwrun@core3.amsl.com>
X-Original-To: iesg-agenda-dist@ietf.org
Delivered-To: iesg-agenda-dist@core3.amsl.com
Received: by core3.amsl.com (Postfix, from userid 30) id 754833A69B6; Thu, 10 Mar 2011 15:21:41 -0800 (PST)
From: IESG Secretary <iesg-secretary@ietf.org>
To: iesg-agenda-dist@ietf.org
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0
Message-Id: <20110310232142.754833A69B6@core3.amsl.com>
Date: Thu, 10 Mar 2011 15:21:42 -0800
Subject: [IESG-AGENDA-DIST] Summarized Agenda for the 2011-03-17 IESG Teleconference
X-BeenThere: iesg-agenda-dist@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Distribution of IESG agendas <iesg-agenda-dist.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/iesg-agenda-dist>, <mailto:iesg-agenda-dist-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/iesg-agenda-dist>
List-Post: <mailto:iesg-agenda-dist@ietf.org>
List-Help: <mailto:iesg-agenda-dist-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/iesg-agenda-dist>, <mailto:iesg-agenda-dist-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 10 Mar 2011 23:21:42 -0000
INTERNET ENGINEERING STEERING GROUP (IESG) Summarized Agenda for the 2011-03-17 IESG Teleconference This agenda was generated at 2011-03-10 15:20:15 PST Up-to-date web version of this agenda can be found at: http://datatracker.ietf.org/iesg/agenda/ 1. Administrivia 1.1 Roll Call 1.2 Bash the Agenda 1.3 Approval of the Minutes of Past Telechats 1.4 List of Remaining Action Items from Last Telechat OUTSTANDING TASKS Last updated: March 7, 2011 o Jari Arkko to add guidance on multi-Area work to the wiki. o Tim Polk to draft text for the wiki regarding Last Call processes that include IPR. o Adrian Farrel and Stewart Bryant to review the -bis draft for RFC 4020 Allocation procedures. o Alexey Melnikov and Michelle Cotton to follow up with Larry Masinter regarding the tracking of pending media type/charset/URI registrations. o Ralph Droms to generate a liaison from the IESG to IEEE 802.1 on the TRILL working group recharter. 2. Protocol Actions 2.1 WG Submissions 2.1.1 New Items o draft-ietf-httpbis-content-disp-06 Use of the Content-Disposition Header Field in the Hypertext Transfer Protocol (HTTP) (Proposed Standard) Note: Mark Nottingham (HTTPBIS chair) is the document shepherd Token: Alexey Melnikov o draft-ietf-ancp-protocol-15 Protocol for Access Node Control Mechanism in Broadband Networks (Proposed Standard) Note: Matthew Bocci (matthew.bocci@alcatel-lucent.com) is the document shepherd. Token: Ralph Droms o draft-ietf-sidr-res-certs-21 A Profile for X.509 PKIX Resource Certificates (Proposed Standard) Note: Sandra Murphy (Sandra.Murphy@sparta.com) is the document shepherd. Token: Stewart Bryant o draft-ietf-sidr-cp-16 Certificate Policy (CP) for the Resource PKI (RPKI (BCP) Note: Sandra Murphy (Sandra.Murphy@cobham.com ) is the document shepherd. Token: Stewart Bryant o draft-ietf-sidr-iana-objects-01 RPKI Objects issued by IANA (Proposed Standard) Note: Chris Morrow (christopher.morrow@gmail.com) is the document shepherd. Token: Stewart Bryant o draft-ietf-intarea-server-logging-recommendations-03 Logging recommendations for Internet facing servers (BCP) Note: Julien Laganier (julien.ietf@gmail.com) is the document shepherd Token: Jari Arkko o draft-ietf-ipsecme-failure-detection-06 A Quick Crash Detection Method for IKE (Proposed Standard) Note: Paul Hoffman (paul.hoffman@vpnc.org) is the document shepherd. Token: Sean Turner o draft-ietf-mip4-gre-key-extension-04 GRE Key Extension for Mobile IPv4 (Proposed Standard) Note: Pete McCann (mccap@petoni.org) is the document shepherd. Token: Jari Arkko 2.1.2 Returning Items o draft-ietf-isis-genapp-04 Advertising Generic Information in IS-IS (Proposed Standard) Token: Stewart Bryant o draft-ietf-geopriv-rfc3825bis-17 Dynamic Host Configuration Protocol Options for Coordinate-based Location Configuration Information (Proposed Standard) Note: The Document Shepherd for this document is Richard Barnes (rbarnes@bbn.com). Token: Robert Sparks 2.2 Individual Submissions 2.2.1 New Items o draft-holsten-about-uri-scheme-06 The 'about' URI scheme (Proposed Standard) Token: Alexey Melnikov 2.2.2 Returning Items o draft-bryan-metalinkhttp-22 Metalink/HTTP: Mirrors and Hashes (Proposed Standard) Note: Lars, please review the updated version to see if it addresses your concern Token: Alexey Melnikov Was deferred by Alexey Melnikov on 2011-02-17 3. Document Actions 3.1 WG Submissions 3.1.1 New Items o draft-ietf-v6ops-v6-in-mobile-networks-03 Mobile Networks Considerations for IPv6 Deployment (Informational) Note: Fred Baker (fred@cisco.com) is the document shepherd. Token: Ron Bonica o draft-ietf-morg-multimailbox-search-07 IMAP4 Multimailbox SEARCH Extension (Experimental) Note: Julian Reschke is the Document Shepherd. Token: Peter Saint-Andre o draft-ietf-hip-cert-11 Host Identity Protocol Certificates (Experimental) Note: Gonzalo Camarillo (Gonzalo.Camarillo@ericsson.com) is the document shepherd. Token: Ralph Droms Was deferred by Russ Housley on 2011-03-03 o draft-ietf-sidr-arch-12 An Infrastructure to Support Secure Internet Routing (Informational) Note: Sandra Murphy (Sandra.Murphy@cobham.com ) is the document shepherd. Token: Stewart Bryant o draft-ietf-netext-pmip6-lr-ps-05 PMIPv6 Localized Routing Problem Statement (Informational) Note: Basavaraj Patil (basavaraj.patil@nokia.com) is the document shepherd. Token: Jari Arkko 3.1.2 Returning Items NONE 3.2 Individual Submissions Via AD 3.2.1 New Items o draft-zhu-mobility-survey-03 A Survey of Mobility Support In the Internet (Informational) Note: AD Review: I was asked to AD sponsor this draft to an RFC. Sorry for the extremely long time this has taken to get to my review. But I have now reviewed it. Abstract from draft-zhu-mobility-survey: à Over the last two decades many efforts have been devoted toà developing solutions for mobility support over the global Internet,à which resulted in a variety of proposed solutions.à In this draft weà conducted a systematic survey of the previous efforts to gain anà overall understanding on the solution space of mobility support.à This draft reports our finding and identifies remaining issues inà providing ubiquitous and efficient global scale mobility support. The document is well written and a pleasure to read. It is a relevant overview of the mobility protocol design space, and its analysis is useful for thinking about the deployment issues that we've seen in this space. As far as I can tell, the document includes most of the relevant work (some exceptions noted below), and I have no major technical comments. I have sent the draft forward to IETF Last Call, and hope that you can work on the remaining issues during the last call, and get more suggestions and additional material from the last call reviewers. Technical: > 4.12. IKEv2 Mobility and Multihoming Protocol (MOBIKE)>>>à à MOBIKE is an extension to Internet Key Exchange (IKEv2) to support>à à mobility and multihoming.à The main purpose of MOBIKE is to allow>à à roaming devices to keep the existing IKE and IPsec SAs despite of IP>à à address changes.à The mobility support in MOBIKE allows both parties>à à to move, but it does not provide a rendezvous mechanism.à In other>à à words, simultaneous movement of both parties is not supported. Hmm. While this is true, part of the simultaneous mobility support is always in a stable anchor point, even in Mobile IP. If you assume mobike device 1 = host and mobike device 2 = gateway, then the situation really is equivalent to mobile IP mobile node - home agent arrangement. Home agent stays put, but mobiles can move around and everything still works. Also, I think it would be useful to state something about multihoming support in some of these protocols. Some do support this, for instance Mobike and more recently, also Mobile IP. A feature matrix for the different protocols is not so interesting, but it would be useful to understand what scope the different protocols have. > The reachability>à à information of the user's machine is published in DNS, and only>à à accessible to the subscriber.>à "published in DNS" and "only accessible to the subscriber" do not appear to be compatible statements. Can you expand on this a bit? >à à BTMM has millions of subscribers, which is perhaps the first large->à à scale commercial host mobility support in Internet as of today. I wonder if the use of Mobile IP in CDMA/3GPP2 networks exceeds this. Please check. Also, since you are missing GTP which is essentially a non-IETF variant of PMIP, you should probably include GTP and note that that network-based mobility support is extremely widely used (to the order of a billion data users). > The second approach to mobility support is to provide a mapping> between a mobile's stable identifier and its dynamically changing IP> address.à Instead of notifying the world on every movement, a mobile> only needs to update a single binding location about its location> changes.à In this approach, if one level of indirection at IP layer> is used, as in the case of Mobile IP, it has a potential side effect> of introducing triangle routing; otherwise, if the two end nodes are> aware of each other's movement, it means that both ends have to> support the same mobility protocol.>> Yet there is the third case in which the protocols combine the above> approaches, in the hope of keeping the pros and eliminating some cons> of the two.à WINMO is a typically protocol in this case.>à This is a very nice classification. But I have a question. How would you classify designs that include support for route optimization, such as Mobile IP? They do not impact routers, but still there's a need to update more than a single entity about a new location? Also, in Section 5.2 you talk about mobility aware entities, but this does not take into account whether the CNs are aware in route optimization mode. Missing: It might be valuable to describe the limited mobility support in transport layer solutions (SCTP and MP-TCP) as well. That is, they allow a single connection to stay up even as you move around, but do not by themselves allow simultaneous mobility of both parties. What about SHIM6? I would talk about GTP (a network-based mobility protocol) as well. What about mentioning application layer mobility designs (e.g., start from the paper by Henning on SIP mobility)? It might be useful to have at least some pointers to various optimization efforts that the community has spent quite a lot of time on. It felt that FMIP was the only one that was mentioned in addition to the general idea of route optimization in Mobile IP.à Look for pointers from the MIPSHOP WG's page, RFC 4651, etc. Editorial: > Xing, W., Karl, H., and A. Wolisz, "M-SCTP: Design and> Prototypical Implementaion of An End-to-End Mobility> Concept"Typo >à à LISP-Mobility [LISP-Mobility & l t ; h t t p ://tools.ietf.org/html/draft-zhu-mobility-survey-03#ref-LISP-Mobility>] is a relatively new design, in which>à à the designer hopes to utilize LISP[LISP], which is designed for>à à routing scalability, to support mobility as well. This sentence could probably be simplified a bit. Jari Token: Jari Arkko o draft-herzog-static-ecdh-05 Use of static-static Elliptic-Curve Diffie-Hellman key agreement in Cryptographic Message Syntax (Informational) Note: Jonathan Herzog (jherzog@ll.mit.edu) is the document Shepherd. Token: Tim Polk o draft-meadors-multiple-attachments-ediint-11 Multiple Attachments for EDI-INT (Informational) Token: Alexey Melnikov o draft-mrw-nat66-10 IPv6-to-IPv6 Network Prefix Translation (Experimental) Token: Ron Bonica o draft-zhu-mobileme-doc-05 Understanding Apple's Back to My Mac (BTMM) Service (Informational) Token: Lars Eggert 3.2.2 Returning Items NONE 3.3 IRTF and Independent Submission Stream Documents 3.3.1 New Items NONE 3.3.2 Returning Items NONE 3.3.3 For Action o draft-hu-flow-label-cases-03 Survey of proposed use cases for the IPv6 flow label (Informational) Note: ISE submission Token: Jari Arkko 4. Working Group Actions 4.1 WG Creation 4.1.1 Proposed for IETF Review NONE 4.1.2 Proposed for Approval o Verification Involving PSTN Reachability (vipr) Token: Robert Sparks o Address Resolution for Massive numbers of hosts in the Data center (armd) Token: Ron Bonica 4.2 WG Rechartering 4.2.1 Under Evaluation for IETF Review o Softwires (softwire) Token: Ralph Droms o Secure Inter-Domain Routing (sidr) Token: Stewart Bryant 4.2.2 Proposed for Approval NONE 5. IAB News We Can Use 6. Management Issues 6.1 IESG statement on MIME type registrations from other SDOs in the standards tree with no drafts (Alexey Melnikov) 7. Working Group News
- [IESG-AGENDA-DIST] Summarized Agenda for the 2011… IESG Secretary