[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