Subject: RE: [Mip6] FW: Request to progress MIP6 WG I-D: draft-ietf-mip6-ikev2-ipsec-06.txt

From: "Soliman, Hesham" <[email-masked]>
Date: Wed, 14 Jun 2006 15:43:48 -0700

Hi Raj, authors, 

How was the issue I raised about the tunnel mode resolved in the draft?
A quick glance tells me nothing changed.

Hesham

 > -----Original Message-----
 > From: Basavaraj Patil [mailto:[email-masked]] 
 > Sent: Wednesday, June 14, 2006 5:32 PM
 > To: [email-masked]
 > Subject: [Mip6] FW: Request to progress MIP6 WG I-D: 
 > draft-ietf-mip6-ikev2-ipsec-06.txt
 > 
 > 
 > FYI,
 > 
 > ------ Forwarded Message
 > > From: Basavaraj Patil <[email-masked]>
 > > Date: Wed, 14 Jun 2006 16:30:40 -0500
 > > To: ext Jari Arkko <[email-masked]>, 
 > <[email-masked]>
 > > Cc: "W. Mark Townsley" <[email-masked]>, Gopal Dommety
 > > <[email-masked]>, ext Vijay Devarapalli 
 > <[email-masked]>,
 > > <[email-masked]>
 > > Conversation: Request to progress MIP6 WG I-D:
 > > draft-ietf-mip6-ikev2-ipsec-06.txt
 > > Subject: Request to progress MIP6 WG I-D: 
 > draft-ietf-mip6-ikev2-ipsec-06.txt
 > > 
 > > 
 > > 
 > > Hi Jari,
 > > 
 > > The MIP6 WG I-D "Mobile IPv6 Operation with IKEv2 and the revised
 > > IPsec architecture" draft has completed a second WG last 
 > call and is
 > > now ready to be progressed towards standards track. Rev 06 
 > of the I-D
 > > has incorporated all the comments that have been received 
 > during the
 > > last call and prior to it.
 > > 
 > > We would like to request you to process this I-D and 
 > progress it towards
 > > publication as a standards track RFC.
 > > 
 > > Below is the template that was completed when we submitted 
 > the WG LC
 > > the 1st time and sent it to the IESG (Margaret). Pretty 
 > much all the
 > > statements are valid even now.
 > > 
 > > -Raj
 > > 
 > > ==================================================
 > > 
 > >> The MIP6 WG I-D "Mobile IPv6 Operation with IKEv2 and the revised
 > >> IPsec", I-D: draft-ietf-mip6-ikev2-ipsec-04.txt has 
 > completed WG last
 > >> call and has been revised following the comments received.
 > >> It is ready for AD review and forwarded through the IETF 
 > process for
 > >> publication.
 > >> 
 > >> Intended status for this I-D: Standards track
 > >> 
 > >> 
 > >> 1) Have the chairs personally reviewed this version of 
 > the ID and do
 > >>   they believe this ID is sufficiently baked to forward 
 > to the IESG
 > >>   for publication?
 > >> 
 > >> Yes.
 > >> 
 > >> 
 > >> 2) Has the document had adequate review from both key WG 
 > members and
 > >>   key non-WG members? Do you have any concerns about the depth or
 > >>   breadth of the reviews that have been performed?
 > >> 
 > >> The I-D has been reviewed sufficiently by WG members as well as
 > >> experts in the area of IPsec and security.
 > >> 
 > >> 3) Do you have concerns that the document needs more review from a
 > >>   particular (broader) perspective (e.g., security, operational
 > >>   complexity, someone familiar with AAA, etc.)?
 > >> 
 > >> No. The document does not need further reviews.
 > >>   
 > >> 4) Do you have any specific concerns/issues with this 
 > document that
 > >>   you believe the ADs and/or IESG should be aware of? For example,
 > >>   perhaps you are uncomfortable with certain parts of the 
 > document,
 > >>   or whether there really is a need for it, etc., but at the same
 > >>   time these issues have been discussed in the WG and the WG has
 > >>   indicated it wishes to advance the document anyway.
 > >> 
 > >> There are no specific concerns with this document.
 > >>   
 > >> 5) How solid is the WG consensus behind this document?  Does it
 > >>   represent the strong concurrence of a few individuals, 
 > with others
 > >>   being silent, or does the WG as a whole understand and 
 > agree with
 > >>   it?
 > >> 
 > >> Strong WG consensus. Base MIP6 specs (RFCs 3775/3776) 
 > specified the
 > >> use of IKE (v1) as the means to establish the IPsec SA. 
 > This I-D is
 > >> specifying the use of IKEv2 for establishing the MN-HA IPsec SA.
 > >> 
 > >> 
 > >> 6) Has anyone threatened an appeal or otherwise indicated extreme
 > >>   discontent?  If so, please summarize what are they upset about.
 > >> 
 > >> No.
 > >>   
 > >> 7) Have the chairs verified that the document adheres to 
 > _all_ of the
 > >>   ID nits?  (see http://www.ietf.org/ID-nits.html).
 > >> 
 > >> Yes. No Nits found. It has been run through the nits 
 > checker available
 > >> at the tools.ietf web site.
 > >>   
 > >> 8) Does the document a) split references into 
 > normative/informative,
 > >>   and b) are there normative references to IDs, where the 
 > IDs are not
 > >>   also ready for advancement or are otherwise in an unclear state?
 > >>   (Note: the RFC editor will not publish an RFC with normative
 > >>   references to IDs, it will delay publication until all 
 > such IDs are
 > >>   also ready for publication as RFCs.)
 > >> 
 > >> Yes. 
 > >> 
 > >> 9) For Standards Track and BCP documents, the IESG approval
 > >>   announcement includes a writeup section with the following
 > >>   sections:
 > >> 
 > >>   - Technical Summary
 > >> 
 > >>   This document describes Mobile IPv6 operation with the revised
 > >>   IPsec architecture and IKEv2.
 > >> 
 > >>   - Working Group Summary
 > >> 
 > >>   The document has been discussed in the WG at several IETF
 > >>   meetings. It has also been reviewed sufficiently by WG 
 > members as
 > >>   well as security experts. There is consensus in 
 > publishing this I-D
 > >>   as a proposed standard. This specification is required 
 > in view of
 > >>   IKEv2 becoming the revised mechanism for setting up IPsec SAs.
 > >> 
 > >>   - Protocol Quality
 > >> 
 > >> 
 > >> 
 > >>     - is the protocol already being implemented?
 > >> 
 > >>        Yes.
 > >> 
 > >> 
 > >>     - have a significant number of vendors indicated they plan to
 > >>       implement the spec?
 > >> 
 > >>       There are some vendors who have at least indicated that they
 > >>       will implement this spec.
 > >>  
 > >>     - are there any reviewers (during the end stages) that merit
 > >>       explicit mention as having done a thorough review 
 > that resulted
 > >>       in important changes or a conclusion that the 
 > document was fine
 > >>       (except for maybe some nits?)
 > >> 
 > >>       The acknowledgement section captures this adequately.
 > >> 
 > >> -Basavaraj
 > >> 
 > >> 
 > 
 > ------ End of Forwarded Message
 > 
 > 
 > _______________________________________________
 > Mip6 mailing list
 > [email-masked]
 > https://www1.ietf.org/mailman/listinfo/mip6
 > 

_______________________________________________
Mip6 mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mip6

---

From: Basavaraj Patil <[email-masked]>
Date: Thu, 15 Jun 2006 14:47:19 -0500

Based on the discussion about whether to include tunnel mode specification
by a small handful of people, the final conclusion was to include text that
specifies how to send BU messages in tunnel mode.

-Raj