Mark and Jari,
(copy to the SHIM6 Working Group)
Here are the finals of the document shepherd write-ups for the three
SHIM6 documents that have completed Working Group Last Call and have
been passed to you with a request for publication as Proposed Standard.
regards,
Geoff Huston
------------------------------------------------------------------------
draft-ietf-shim6-proto-08
(1.a) Who is the Document Shepherd for this document?
Geoff Huston
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?
Yes
(1.b) Has the document had adequate review both from key members of
the interested community and others?
Yes, the document has been explicitly called to the attention of
the Working Group on a number of occasions, and review comments
have been incorporated into the document.
Does the Document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?
The Document Shepherd is comfortable with the level of review of
this document.
(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?
The document has been reviewed extensively over the past 15
months and the Document Shepherd is comfortable with the
competence and breadth of review of this document.
(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 interested community has discussed those issues and has
indicated that it still wishes to advance the document, detail
those concerns here.
I do not have specific concerns, but I would like to highlight a
number of matters that have arisen in the Working Group and
elsewhere relating to SHIM6, and the manner of their resolution in
this protocol specification.
The document has attracted comment over middleware checking the
integrity of the TCP header checksum. The Working Group consensus
was to recommend that middleware behavior take into account the
presence of a shim6 payload header and modify their behavior
accordingly. It was not established to what extent this is an
issue. Other alternatives relating to detection of middleware that
performs TCP/UDP checksum validation and additional flags in the
chim6 payload header were canvassed by the Working Group, but
received no clear support.
Working Group review noted that special consideration is required
when the host also implements Bump-In-The-Wire (BITW) IPSEC. The
Working Group position is that in the case of BITW IPSEC it is
mandated that shim6 must either be disabled or implemented using
the same BITW approach to preserve the logical ordering of placing
IPSEC processing immediately "above" SHIM6 in the logical protocol
stack flow.
Review of SHIM6 in other forums, noteably in the NANOG forum has
attracted the comment that there is no mechanism in SHIM6 for
site-based control, and placing this functionality in end hosts
rather than site edges was considered to be a sub-optimal
approach. The response to this is 2-fold: firstly the SHIM6 WG is
not chartered to develop a generic architecture for multi-homing,
but to work specifically on the architecture developed by the
Multi6 Working Group. Secondly, the Working Group has informally
explored extensions to the shim6 approach that may include
interaction with site edge routers, but at this stage the Working
Group sees this initial approach as being within its charter, and
that re-chartering the Working Group to explore such extensions
may be appropriate once this initial "base" specification of the
shim6 approach has been completed.
A similar approach of deferring working on extensions to SHIM6
until the completion of this "base" specification also applies to
the consideration raised about interaction between upper level
protocol behavior and SHIM6. The base specification has the
capability for context forking for individual connections in order
to permit individual connections to function with different
preferences for locator pairs. The manner of interaction between
the upper level protocol and SHIM6 is regarded as an extension to
the "base" specification.
(1.e) How solid is the consensus of the interested community behind
this document? Does it represent the strong concurrence of a few
individuals, with others being silent, or does the interested
community as a whole understand and agree with it?
The document has been reviewed from a range of perspectives and
has generated review comment from these perspectives. The
consensus behind this document appears to be well-founded.
(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?
Yes
Reference [5] (RFC2463) now refers to an obsoleted spec - it
should be replaced with a reference to RFC4443 The update to this
document can be undertaken in the form of a note to the RFC
Editor.
There are a number of document typos. The list is:
page 14: s"[6]."[6]"
page 24: s"bytes.Another"bytes. Another"
page 40: s"field.Identifies"field. Identifies"
page 41: s"pruposes"purposes"
page 54: s"unstrucutred "unstructured"
page 64: s"recieve"receive"
page 70: s"The the"The"
page 72: s"The the"The"
page 82: s"extenson"extension"
page 82: s"porpuses"purposes"
page 88: s"reccomended"recommended"
page 88: s"reccomendation"recommendation"
page 88: s"presudoheader"pseudoheader"
page 88: s"header header"header"
page 92: s"the the"the"
page 94: s"[CGA] namespace registry"CGA Extension Type Values registry"
page 95: s"pruposes"purposes"
page 105: s"Tiemout"Timeout"
page 105: s"Tiemout"Timeout"
page 121: s"crtical"critical"
page 121: s"estbalishment"establishment"
page 121: s"recgnized"recognized"
page 121: s"strcuture"structure"
page 121: s"commnets"comments"
page 121: s"reccomendation"recommendation"
page 122: s"meesages"messages"
page 122: s"retransmision"retransmission"
page 122: s"respon der"responder"
page 122: s"renumberin"renumbering"
page 122: s"synchonized"synchronized"
Additional changes to refer to related shim6 documents in an
informative manner have been proposed in the form of an RFC Editor
Note:
Add the paragraph at the end of section 1 (and immediately before
section 1.1)
"The applicability of the Shim6 protocol is considered in [24]. The
architecture of this approach is described in [25]."
(1.h) Has the document split its references into normative and
informative?
Yes
Are there normative references to documents that are
not ready for advancement or are otherwise in an unclear state?
No
If such normative references exist, what is the strategy for their
completion?
Reference [8] is being submitted to the IESG for publication with
this document.
Reference [9] is being submitted to the IESG for publication with
this document.
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].
No
(1.i) Has the Document Shepherd verified that the document IANA
consideration section exists and is consistent with the body of
the document?
Yes
If the document specifies protocol extensions, are reservations
requested in appropriate IANA registries?
Yes
Are the IANA registries clearly identified?
Yes
If the document creates a new registry, does it define the proposed
initial contents of the registry and an allocation procedure for
future registrations?
Yes
Future registrations are allocated via "Standards Action"
** Code values 5 through 119 of the Shim6 Error Code registry are
undefined. It is suggested that the following addition be made
to the document on page 95:
5 - 119 Allocated using Standards action
Does it suggested a reasonable name for the new registry? See
[I-D.narten-iana-considerations-rfc2434bis].
Yes
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?
N/A
(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?
N/A
(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
This document defines the Shim6 protocol, a layer 3 shim for IPv6
that provides locator agility below the transport protocols. Shim6
provides IPv6 hosts in a multihomed site with failover and load
sharing properties, without assuming that a multihomed site will
have a provider independent IPv6 address prefix which is announced
in the global IPv6 routing table. Shim6-enabled hosts in a
multihomed site will use the Shim6 protocol specified in this
document to setup state with peer hosts, so that the state can
later be used to failover to a different locator pair, should the
original pair stop working, while preserving the integrity of
active transport layer sessions.
Working Group Summary
The document has extensively reviewed by the Working Group. The
Working Group consensus was to recommend publication of this
document as a Proposed Standard.
Document Quality
There are known implementations of this specification, and there
have been no implementation experiences that have implied any
further revision to this specification is required.
Additional note:
The document is being passed to the IESG as part of a set of three
documents that the Working Group has determined by consensus in
the WG Last Calls has requested to be published as Proposed
Standards. The Document Shepherd is aware that there have been
suggestions to publish initially as Experimental, and notes that
the Working Group Last Call specifically noted the intended
request to publish as a Proposed Standard, and this request is
based on that Working Group consensus position.
The specification meets all the criteria of section 4.1.1 of RFC
2026, in that the specification is stable, has resolved design
choices, is believed to be well understood and has received
considerable community interest. The specification has no known
technical omissions.
In addition, there are a number of implementations of the
specification, but little in the way of operational experience,
interoperability between implementations and interaction with
application behavior to report on at this stage.
------------------------------------------------------------------------
draft-ietf-shim6-hba-03
(1.a) Who is the Document Shepherd for this document?
Geoff Huston
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?
Yes
(1.b) Has the document had adequate review both from key members of
the interested community and others?
Yes, the document has been explicitly called to the attention of
the Working Group on a number of occasions, and review comments
have been incorporated into the document.
The document has been reviewed by Eric Rescorla for the Security
Are Directorate in November 2005, and the review comments have
been incorporated into the document.
Does the Document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?
The Document Shepherd is comfortable with the level of review of
this document.
(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?
The document has been reviewed extensively over the past 15
months and the Document Shepherd is comfortable with the
competence and breadth of review of this document.
(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 interested community has discussed those issues and has
indicated that it still wishes to advance the document, detail
those concerns here.
The document references Cryptographic Generated Addresses and the
Working Group was informed of IPR statements by Microsoft and
Ericsson that may relate to HBAs. The Working Group has reached a
consensus view that it is comfortable to proceed with recommending
the publication of this document as a Proposed Standard.
(1.e) How solid is the consensus of the interested community behind
this document? Does it represent the strong concurrence of a few
individuals, with others being silent, or does the interested
community as a whole understand and agree with it?
The document has been reviewed from a range of perspectives and
has generated review comment from these perspectives. The
consensus behind this document appears to be well-founded.
(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.)
The document has involved an extensive consideration of IPR issues
on SHIM6 mailing list and at the WG meetings. At one stage an
individual raised the option of appealing any IESG decision to
publish this document as a proposed standard due to potential IPR
encumbrance. The WG were aware of this and after extensive
consideration of the nature of the IPR statements there was strong
consensus to proceed with a request to publish these documents.
(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?
Yes
Reference 12 has since been published as RFC4982. The update to
this document can be undertaken in the form of a note to the RFC
Editor.
There are a number of document typos. The list is:
page 4: s"future/ premeditated"future / premeditated"
page 5: s"Cryptographic Generated Addresses"Cryptographic Generated Addresses (CGA)"
page 6: s"dirven"driven"
page 6: s". this". This"
page 6: s"present a"presents a"
page 6: s"appraoch"approach"
page 6: s"appraoches"approaches"
page 9: s"trails"trials"
page 11: s"Strcuture"Structure"
page 11: s"Strcuture"Structure"
page 11: s"this not means that"this does not mean that"
page 13: s"[Note:"(Note:"
page 13: s"trivially successful becuase"trivial because of"
page 13: s"step 1]"step 1)"
page 14: s"him to create"it to create"
page 15: s"global IP address"global IP address."
page 15: s"this means that Host2"This means that Host2"
page 16: s"ad identifier"as an identifier"
page 20: s"need to generate"needs to generate"
page 20: s"that the resulting HBA set"where the resulting HBA set"
page 20: s"[6]. addresses"[6] addresses/
page 21: s"attacks to currently"attacks on currently"
(1.h) Has the document split its references into normative and
informative?
Yes
Are there normative references to documents that are
not ready for advancement or are otherwise in an unclear state?
No
If such normative references exist, what is the strategy for their
completion?
Reference [8] is being submitted to the IESG for publication with
this document.
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].
No
(1.i) Has the Document Shepherd verified that the document IANA
consideration section exists and is consistent with the body of
the document?
Yes
If the document specifies protocol extensions, are reservations
requested in appropriate IANA registries?
Yes
Are the IANA registries clearly identified?
Yes
If the document creates a new registry, does it define the proposed
initial contents of the registry and an allocation procedure for
future registrations?
N/A
Does it suggested a reasonable name for the new registry? See
[I-D.narten-iana-considerations-rfc2434bis].
N/A
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?
N/A
(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?
N/A
(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
Hash Based Addresses are intended to provide a secure binding
between the multiple addresses with different prefixes available
to a host within a multihomed site. Information about the
multiple prefixes is included within the addresses by generating
the interface identifiers of the addresses of a host as hashes of
the set of available prefixes and a random number, which are then
appended to the different prefixes. The result is a set of
addresses that are inherently bound together such that given one
valid address out of the group, the prefix set and the random
number, it is possible to determine whether another address is
part of the group by computing the hash and checking against the
interface identifier value.
Working Group Summary
The document has extensively reviewed by the Working Group and by
the Security Area Directorate. The Working Group consensus was to
recommend publication of this document as a Proposed Standard.
Document Quality
There are known implementations of this specification, and there
have been no implementation experiences that have implied any
further revision to this specification is required.
Additional note:
The document is being passed to the IESG as part of a set of three
documents that the Working Group has determined by consensus in
the WG Last Calls has requested to be published as Proposed
Standards. The Document Shepherd is aware that there have been
suggestions to publish initially as Experimental, and notes that
the Working Group Last Call specifically noted the intended
request to publish as a Proposed Standard, and this request is
based on that Working Group consensus position.
The specification meets all the criteria of section 4.1.1 of RFC
2026, in that the specification is stable, has resolved design
choices, is believed to be well understood and has received
considerable community interest. The specification has no known
technical omissions.
In addition, there are a number of implementations of the
specification, but little in the way of operational
experience, interoperability between implementations and
interaction with application behavior to report on at this
stage.
------------------------------------------------------------------------
draft-ietf-shim6-failure-detection-03
(1.a) Who is the Document Shepherd for this document?
Geoff Huston
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?
Yes
(1.b) Has the document had adequate review both from key members of
the interested community and others?
Yes, the document has been explicitly called to the attention of
the Working Group on a number of occasions, and review comments
have been incorporated into the document.
Does the Document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?
The Document Shepherd is comfortable with the level of review of
this document.
(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?
The document has been reviewed extensively over the past 15
months and the Document Shepherd is comfortable with the
competence and breadth of review of this document.
(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 interested community has discussed those issues and has
indicated that it still wishes to advance the document, detail
those concerns here.
No concerns to raise.
(1.e) How solid is the consensus of the interested community behind
this document? Does it represent the strong concurrence of a few
individuals, with others being silent, or does the interested
community as a whole understand and agree with it?
The document has been reviewed from a range of perspectives and
has generated review comment from these perspectives. The
consensus behind this document appears to be well-founded.
(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?
There are a number of document typos. The list is:
page 8: s"rechability"reachability"
page 12: s"to to"to"
page 16: s"options.The"options. The"
page 19: s"messsage"message"
page 20: s"recommeded"recommended"
page 23: s"and and"and"
page 32: s"draft-ietf-dna-protocol-05"draft-ietf-dna-protocol-06"
page 32: s"draft-ietf-shim6-locator-pair-selection-01"draft-ietf-shim6-locator-pair-selection-02"
The Document Shepherd is of the view that the reference:
[I-D.ietf-shim6-proto]
Bagnulo, M. and E. Nordmark, "Shim6: Level 3 multi-homing
Shim Protocol for IPv6", draft-ietf-shim6-proto-08 (work
in progress), April 2007.
should be a normative reference to the shim6 protocol document,
rather than an informative reference.
(1.h) Has the document split its references into normative and
informative?
Yes
Are there normative references to documents that are
not ready for advancement or are otherwise in an unclear state?
No
If such normative references exist, what is the strategy for their
completion?
N/A
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].
No
(1.i) Has the Document Shepherd verified that the document IANA
consideration section exists and is consistent with the body of
the document?
Yes
If the document specifies protocol extensions, are reservations
requested in appropriate IANA registries?
There are no IANA actions required in this document.
Are the IANA registries clearly identified?
N/A
If the document creates a new registry, does it define the proposed
initial contents of the registry and an allocation procedure for
future registrations?
N/A
Does it suggested a reasonable name for the new registry? See
[I-D.narten-iana-considerations-rfc2434bis].
N/A
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?
N/A
(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?
N/A
(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
This document specifies how the level 3 multi-homing shim protocol
(SHIM6) detects failures between two communicating hosts that are
using this protocol. It also specifies an exploration protocol
for identifying a viable pair of interfaces and/or addresses
between SHIM6 hosts.
Working Group Summary
The document has extensively reviewed by the Working Group. The
Working Group consensus was to recommend publication of this
document as a Proposed Standard.
Document Quality
There are known implementations of this specification, and there
have been no implementation experiences that have implied any
further revision to this specification is required.
Additional note:
The document is being passed to the IESG as part of a set of three
documents that the Working Group has determined by consensus in
the WG Last Calls has requested to be published as Proposed
Standards. The Document Shepherd is aware that there have been
suggestions to publish initially as Experimental, and notes that
the Working Group Last Call specifically noted the intended
request to publish as a Proposed Standard, and this request is
based on that Working Group consensus position.
The specification meets all the criteria of section 4.1.1 of RFC
2026, in that the specification is stable, has resolved design
choices, is believed to be well understood and has received
considerable community interest. The specification has no known
technical omissions.
In addition, there are a number of implementations of the
specification, but little in the way of operational
experience, interoperability between implementations and
interaction with application behavior to report on at this
stage.