Enhanced Route Optimization for Mobile IPv6
draft-ietf-mipshop-cga-cba-03

IANA Additional comments:

> TDB0 CGA Paramters [RFC-mipshop-cga-cba-02]
> TBD1 CGA Parameters Request [RFC-mipshop-cga-cba-02]
> TBD2 Signature [RFC-mipshop-cga-cba-02]
> TBD3 Permanent Home Keygen Token [RFC-mipshop-cga-cba-02]
> TBD4 Care-of Test Init [RFC-mipshop-cga-cba-02]
> TBD5 Care-of Test [RFC-mipshop-cga-cba-02]

TBD0 should be "TBD0 CGA Parameters". Note the flipped letters in "TBD"
and the additional "a" in "Parameters".

Version 03 will be published soon.

IANA Additional comments:

> TDB0 CGA Paramters [RFC-mipshop-cga-cba-02]
> TBD1 CGA Parameters Request [RFC-mipshop-cga-cba-02]
> TBD2 Signature [RFC-mipshop-cga-cba-02]
> TBD3 Permanent Home Keygen Token [RFC-mipshop-cga-cba-02]
> TBD4 Care-of Test Init [RFC-mipshop-cga-cba-02]
> TBD5 Care-of Test [RFC-mipshop-cga-cba-02]

TBD0 should be "TBD0 CGA Parameters". Note the flipped
letters in "TBD" and the additional "a" in "Parameters".

version 03 of the Internet draft will be pubshed shortly
according to the comments from the IETF Last Call.

IANA Last Call Comments:

Upon approval of this document, the IANA will make the
following assignments in the "Mobile IPv6 parameters
- per [RFC3775]" registry located at

http://www.iana.org/assignments/mobility-parameters

Action #1:
Upon approval of this document, the IANA will make the
following assignments in the "Mobile IPv6 parameters
- per [RFC3775]" registry located at

http://www.iana.org/assignments/mobility-parameters
sub-registry "Mobility Options - per [RFC3775]"


TDB0 CGA Paramters [RFC-mipshop-cga-cba-02]
TBD1 CGA Parameters Request [RFC-mipshop-cga-cba-02]
TBD2 Signature [RFC-mipshop-cga-cba-02]
TBD3 Permanent Home Keygen Token [RFC-mipshop-cga-cba-02]
TBD4 Care-of Test Init [RFC-mipshop-cga-cba-02]
TBD5 Care-of Test [RFC-mipshop-cga-cba-02]

Action #2:
Upon approval of this document, the IANA will make the
following assignments in the "Mobile IPv6 parameters
- per [RFC3775]" registry located at

http://www.iana.org/assignments/mobility-parameters
sub-registry "Status Codes - per [RFC3775]"

(from range above 128)
TBDa Permanent home keygen token unavailable [RFC-mipshop-cga-cba-02]
TBDb CGA and signature verification failed [RFC-mipshop-cga-cba-02]
TBDc Permanent home keygen token exists [RFC-mipshop-cga-cba-02]
TBDd Non-null home nonce index expected [RFC-mipshop-cga-cba-02]

Action #3:
Upon approval of this document, the IANA will make the
following assignments in the "CGA Message Type Name Space
per [RFC3972]" registry located at

http://www.iana.org/assignments/cga-message-types
sub-registry "CGA Extension Type Values - per [RFC3972]"

0x5F27 0586 8D6C 4C56 A246 9EBB 9B2A 2E13 [RFC-mipshop-cga-cba-02]

We understand the above to be the only IANA Action for this document.

PROTO Write-up

(1.a) Who is the Document Shepherd for this document? Has the
Document Shepherd personally reviewed this version of the
document and, in particular, does he or she believe this
version is ready for forwarding to the IESG for publication?

Vijay Devarapalli is the Document Shepherd for this document.
I have reviewed the document and it is ready for forwarding
to the IESG for publication.

(1.b) Has the document had adequate review both from key WG members
and from key non-WG members? Does the Document Shepherd have
any concerns about the depth or breadth of the reviews that
have been performed?

This document has been reviewed by numerous folks, including
folks who are proficient in IP Mobility and Security. The
protocol enhancements described in this document were first
done in the IRTF research group, MOBOPTS. Once they were
considered mature, the document was brought to the MIPSHOP WG
for standardization in the IETF. This document went through a
WG last call in the MIPSHOP WG. I have no concerns about the
depth or breadth of the reviews that have been performed.

(1.c) Does the Document Shepherd have concerns that the document
needs more review from a particular or broader perspective,
e.g., security, operational complexity, someone familiar with
AAA, internationalization or XML?

None.

(1.d) Does the Document Shepherd have any specific concerns or
issues with this document that the Responsible Area Director
and/or the IESG should be aware of? For example, perhaps he
or she is uncomfortable with certain parts of the document, or
has concerns whether there really is a need for it. In any
event, if the WG has discussed those issues and has indicated
that it still wishes to advance the document, detail those
concerns here.

None.

(1.e) 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?

There is strong WG consensus in advancing this document.

(1.f) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in
separate email messages to the Responsible Area Director. (It
should be in a separate email because this questionnaire is
entered into the ID Tracker.)

No.

(1.g) Has the Document Shepherd personally verified that the
document satisfies all ID nits? (See
http://www.ietf.org/ID-Checklist.html and
http://tools.ietf.org/tools/idnits/). Boilerplate checks are
not enough; this check needs to be thorough. Has the document
met all formal review criteria it needs to, such as the MIB
Doctor, media type and URI type reviews?

The document meets all the requirements. There is a minor nit
in RFC 2119 boilerplate that was reported by the idnits tool.
This will be fixed in the subsequent revision.

(1.h) Has the document split its references into normative and
informative? Are there normative references to documents that
are not ready for advancement or are otherwise in an unclear
state? If such normative references exist, what is the
strategy for their completion? Are there normative references
that are downward references, as described in [RFC3967]? If
so, list these downward references to support the Area
Director in the Last Call procedure for them [RFC3967].

The document splits the references into normative and
Informative references. There are no normative references
that could of concern.

(1.i) Has the Document Shepherd verified that the document IANA
consideration section exists and is consistent with the body
of the document? If the document specifies protocol
extensions, are reservations requested in appropriate IANA
registries? Are the IANA registries clearly identified? If
the document creates a new registry, does it define the
proposed initial contents of the registry and an allocation
procedure for future registrations? Does it suggested a
reasonable name for the new registry? See
[I-D.narten-iana-considerations-rfc2434bis]. If the document
describes an Expert Review process has Shepherd conferred with
the Responsible Area Director so that the IESG can appoint the
needed Expert during the IESG Evaluation?

The IANA considerations section exists and is consistent
with the body of the document. The document requests
reservations in the appropriate IANA registries. The IANA
registries that need to be modified are clearly identified.
This document does not create a new registry. However the
IANA considerations section could do a better job by
listing all the new mobility options that need to be
assigned. This will be fixed in the next revision.

(1.j) Has the Document Shepherd verified that sections of the
document that are written in a formal language, such as XML
code, BNF rules, MIB definitions, etc., validate correctly in
an automated checker?

Does not apply.

(1.k) The IESG approval announcement includes a Document
Announcement Write-Up. Please provide such a Document
Announcement Writeup? Recent examples can be found in the
"Action" announcements for approved documents. The approval
announcement contains the following sections:

Technical Summary
Relevant content can frequently be found in the abstract
and/or introduction of the document. If not, this may be
an indication that there are deficiencies in the abstract
or introduction.

This document specifies Enhanced Route Optimization, an amendment to
route optimization in base Mobile IPv6. Enhanced Route Optimization
secures a mobile node's home address against impersonation through an
interface identifier that is cryptographically and verifiably bound
[6] to the public component of the mobile node's public/private-key
pair. Enhanced Route Optimization further allows mobile and
correspondent nodes to resume bidirectional communications in
parallel with pursuing a care-of address test. The latency of the
home and care-of address tests are therefore eliminated in most
cases. The use of cryptographically generated home addresses also
mitigates the threat of impersonators that can interpose on the home
address test and thereby facilitate longer binding lifetimes. This
leads to increased security and a reduction in signaling overhead.

Working Group Summary
Was there anything in WG process that is worth noting? For
example, was there controversy about particular points or
were there decisions where the consensus was particularly
rough?

None.

Document Quality
Are there existing implementations of the protocol? Have a
significant number of vendors indicated their plan to
implement the specification? Are there any reviewers that
merit special mention as having done a thorough review,
e.g., one that resulted in important changes or a
conclusion that the document had no substantive issues? If
there was a MIB Doctor, Media Type or other expert review,
what was its course (briefly)? In the case of a Media Type
review, on what date was the request posted?

There is no information currently available on implementations
or any vendors plans. The quality of the document is good.

Personnel
Who is the Document Shepherd for this document? Who is the
Responsible Area Director?

Document shepherd: Vijay Devarapalli
Responsible AD: Jari Arkko/Mark Townsley (Jari is one of the authors
of the document).