Mobile Node Identifier Option for Mobile IPv6 (MIPv6)
RFC 4283

Sent follow-up message to MIP6 list:

To: mip6@ietf.org
From: Margaret Wasserman
Subject: draft-ietf-mip6-mn-ident-option-02.txt
Cc:
Bcc:
X-Attachments:


Hi All,

This is a follow-up message regarding draft-ietf-mip6-mn-ident-option-02.txt.

I have attached the IESG review comments on this document.  The comments marked "discuss" are blocking issues that need to be resolved before the document will be approved for publication.  There are also non-blocking comments (marked "comment") that should be considered by the WG but will not block publication.

There was one "discuss" registered on this document (by Sam Hartman) that should probably be discussed and resolved by the WG.

Raj and Gopal, do you know when we should expect an update to the document that addresses this concern and fixes the other minor issues included in the comments?

Thanks,
Margaret

Sam Hartman:
Discuss:
[2005-03-01] This document fails to explain how the identity option interacts with
the IKE identity payloads or really how it interacts at all with the
base MIPV6 spec.

This needs to be explained.  IT may have been the intent that this
option not be used with base MIPV6 but for example only used with the
authentication option and other extensions.  If so, that needs to be
explained and there needs to be at least one such use that is
standards track if this is going to be published as standards track.


In addition, this specification does not make any particular form of
the identity option mandatory to implement.  To create interoperable
implementations, this specification needs to
specify a mandatory to implement form of the option.

Scott Hollenbeck:
Comment:
[2005-02-25] RFC 2119 should be added as a normative reference.  It's mentioned in section 2, but not cited.

Russ Housley:
Comment:
[2005-03-01]
  In the Abstract: s/Mobile IP6/Mobile IPv6/

[Ballot comment]
Reviewed by Michael Patton, Gen-ART

Summary: This draft is basically ready for publication as a Proposed
Standard RFC, but has two minor organizational improvements
that I recommend be done before publication.

BTW, whatever formatter was used forced a break at every section.
This was a little excessive.  I assume this will be cleaned up in the
RFC process and doesn't actually require any action other than having
the authors watch for it in the final RFC.


Section 3.1 says "defined in Section 3".  But 3.1, which is PART OF 3,
is where it's really defined.  So that makes it (at least sort of)
circular.  What you mean to say is that the suboption being defined in
3.1 USES the format of the general option as in the preceding part of
section 3 ...  I don't think what you have is actually broken, just
that it could be written better.  It's probably not necessary to
correct this, just a suggestion for a place that could use improvement
if work is being done.  In fact, the best thing (also see next
paragraph) might be to separate the general MN stuff from the MN-NAI
specific stuff in different sections.

Some of the Security Considerations are general to any MN usage and
some are specific to MN-NAI.  I would prefer to see these split into
distinct subsections so that what applies to other MN subtypes is
clearer.

IANA Last Call Comments:
Upon approval of this document the IANA will register MN-ID-OPTION-TYPE
in the Mobility Options  located at the following:

In this draft, the suggested value is 7, however this value has already been assigned.  At the time of approval the next available value will be assigned.

For the subtype registry, should this be created at the same location above?

[Ballot discuss]
This document fails to explain how the identity option interacts with
the IKE identity payloads or really how it interacts at all with the
base MIPV6 spec.

This needs to be explained.  IT may have been the intent that this
option not be used with base MIPV6 but for example only used with the
authentication option and other extensions.  If so, that needs to be
explained and there needs to be at least one such use that is
standards track if this is going to be published as standards track.


In addition, this specification does not make any particular form of
the identity option mandatory to implement.  To create interoperable
implementations, this specification needs to
specify a mandatory to implement form of the option.

From:
To: , ,
 
Cc: ,
Date: Mon, 14 Feb 2005 02:06:49 -0600
Subject: Request to progress I-D: draft-ietf-mip6-mn-ident-option-02.txt


Hello,

The following I-D has completed WG last call and we would like to
request the ADs to review the I-D and progress it forward. Details
below:

WG: MIP6
Title: Mobile Node Identifier Option for Mobile IPv6
I-D: draft-ietf-mip6-mn-ident-option-02.txt

Status requested: 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. The chairs have reviewed it not only for technical correctness
but also for spelling and grammar.

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?

Yes. The I-D has been reviewed sufficiently by WG
members. As WG chairs, we do not have any concerns about the depth or
breadth of reviews that this I-D has had. The I-D is fairly
straightforward and does not have a great deal of complexity.

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 I-D proposes the use of identifiers such as NAI, FQDN etc. in
the mobility header of MIP6 signaling messages. There is not a need
for broader review at this time. Especially since a similar concept is
used today in MIP4.
 
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.

No specific concerns/issues. It should be noted that this I-D is
needed by 3GPP2 for Revision D of the TIA-835 specification which is
currently being worked on.
 
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?

The WG as a whole understands the need for this I-D and there is
strong support for standardizing it.

6) Has anyone threatened an appeal or otherwise indicated extreme
  discontent?  If so, please summarize what are they upset about.

There have been no appeals against this I-D.
 
7) Have the chairs verified that the document adheres to _all_ of the
  ID nits?  (see http://www.ietf.org/ID-nits.html).

Yes.
 
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.)

The document includes 3 normative references. Of these 2 are already
RFCs. The 3rd is a reference to RFC2486bis (Radext WG) which is
currently in state: AD Followup.

9) For Standards Track and BCP documents, the IESG approval
  announcement includes a writeup section with the following
  sections:

  - Technical Summary

  Mobile IPv6 defines a new Mobility header which is used by mobile
  nodes, correspondent nodes, and home agents in all messaging related
  to the creation and management of bindings.  Mobile IPv6 nodes need
  the capability to identify themselves using an identity other than
  the default home IP address.  Some examples of identifiers include
  NAI, FQDN, IMSI, MSISDN, etc.  This document defines a new mobility
  option that can be used by Mobile IP6 entities to identify themselves
  in messages containing a mobility header.

  - Working Group Summary

  The working group has discussed the need for such an identifier at
  several WG meetings as well as on the mailing list. The need for
  alternate identifiers such as NAI, IMSI etc. arises from the
  deployment needs of Mobile IPv6 by 3GPP2. 3GPP2 specification
  835-Rev D is currently being worked on and this feature has been
  identified as a necessity for incorporating Mobile IPv6 in the
  standard. WG LC has been completed. No major issues were identified
  during the last call process.

  - Protocol Quality

  No known implementations of the protocol exist at this
  time. However there exist plans to implement this protocol since it
  is required for deployment in 3GPP2 based networks. Revision D of
  TIA 835 specifies the need for such an identifier to be included in
  the mobility header of the registration messages.
 
-Chairs