Using the Encapsulating Security Payload (ESP) Transport Format with the Host Identity Protocol (HIP)
draft-ietf-hip-esp-06

[Note]: 'After Sam''s discuss is cleared, I need one more position recorded from Dan, Jon or Cullen to have the 2/3 necessary to approve these specs.' added by Mark Townsley

IANA Last Call Comment:

ANA has questions about the actions required of IANA upon
approval of this document.

Approval of this document adds values to a yet-to-be-established
registry. This registry is to be created upon approval of
the document:

draft-ietf-hip-base-06.txt

In that document a new HIP Parameters Namespace will be created
with seven separate namespaces:

- Packet Types
- HIP Version
- Parameter Types
- Group IDs
- Suite IDs
- DI-Types
- Notify Message Types

In the current document, the authors request that "Two new
HIP parameters are defined for setting up ESP transport format associations in HIP communication and for rekeying existing
ones." IANA is unsure if these are to be place in the new HIP
Parameters Namespace.

Are these two new HIP parameters to be place in one of the
seven new HIP Parameter namespaces? If so, which one? If not,
where should the two new HIP parameters be registered.

In addition, the current document notes that the NOTIFY
parameter, also part of the document .
Does IANA have an action with respect to new error parameters
in HIP?

Security Area request (from Sam)

-------- Original Message --------
Subject: draft-ietf-hip-esp-03
Date: Tue, 22 Aug 2006 10:16:54 +0200
From: Mark Townsley
To: hip-chairs@tools.ietf.org, hipsec@ietf.org


The Security Area has asked for the following:

An explicit section describing why the semantics of HIP ESP differ
from IPsec ESP,and explaining how a node can run both IPsec and HIP. 
If a node cannot run HIP and IPsec at the same time in all
configurations of HIP, you are likely to see significant pushback.

Such a section sounds reasonable. Also, is the latter true or false?

Thanks,

- Mark

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?

Gonzalo Camarillo, who is the shepherd for this document and co-chairs
the HIP WG, has reviewed this document and believes it is ready.


(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?

The document has been reviewed thoroughly.


(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?

No, the shepherd does not have any concerns.


(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 those issues have been discussed in the WG and the
WG has indicated that it still wishes to advance the document,
detail those concerns here.

No, the shepherd does not have any concerns.


(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?

The whole WG is behind 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 will
be entered into the ID Tracker.)

No one has expressed discontent with this draft.


(1.g) Has the Document Shepherd 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.

Yes, it does.


(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].

Yes, the references have been separated and there are normative
references to Internet Drafts. The HIP WG will request the publication
of the draft entitled "Host Identity Protocol" at the same time as this
document. They should be processed together by the IESG. The draft
entitled "Host Identity Protocol Architecture" has become RFC 4423.


(1.i) The IESG approval announcement includes a Document
Announcement Write-Up. Please provide such a Document
Announcement Write-Up. 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 memo specifies an Encapsulated Security Payload (ESP) based
mechanism for transmission of user data packets, to be used with the
Host Identity Protocol (HIP).


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?

Consensus was strong on this document.


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?

There are several known implementations of this specification.


Thanks,

Gonzalo
HIP co-chair