[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Document Shepherd write-ups for SHIM66 documents



FWIW, I believe anyone reviewing these drafts should be
advised to read draft-ietf-shim6-applicability, even though
it isn't yet ready for approval itself. (I know this
is an Informative reference in the -proto draft, but that
may not be obvious to reviewers.)

    Brian

On 2007-08-20 05:33, Geoff Huston wrote:
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.