Skip to main content

Failure Detection and Locator Pair Exploration Protocol for IPv6 Multihoming
RFC 5534

Revision differences

Document history

Date Rev. By Action
2015-10-14
13 (System) Notify list changed from shim6-chairs@ietf.org,draft-ietf-shim6-failure-detection@ietf.org to (None)
2012-08-22
13 (System) post-migration administrative database adjustment to the No Record position for Cullen Jennings
2012-08-22
13 (System) post-migration administrative database adjustment to the No Objection position for David Ward
2012-08-22
13 (System) post-migration administrative database adjustment to the No Objection position for Dan Romascanu
2012-08-22
13 (System) post-migration administrative database adjustment to the No Objection position for Magnus Westerlund
2012-08-22
13 (System) post-migration administrative database adjustment to the No Objection position for Lars Eggert
2012-08-22
13 (System) post-migration administrative database adjustment to the No Objection position for Russ Housley
2009-06-19
13 Cindy Morgan State Changes to RFC Published from RFC Ed Queue by Cindy Morgan
2009-06-19
13 Cindy Morgan [Note]: 'RFC 5534' added by Cindy Morgan
2009-06-18
13 (System) RFC published
2009-03-26
13 Cindy Morgan State Changes to RFC Ed Queue from Approved-announcement sent by Cindy Morgan
2009-03-25
13 (System) IANA Action state changed to No IC from In Progress
2009-03-25
13 (System) IANA Action state changed to In Progress
2009-03-25
13 Cindy Morgan IESG state changed to Approved-announcement sent
2009-03-25
13 Cindy Morgan IESG has approved the document
2009-03-25
13 Cindy Morgan Closed "Approve" ballot
2009-02-17
13 Cullen Jennings [Ballot Position Update] Position for Cullen Jennings has been changed to Undefined from Discuss by Cullen Jennings
2008-07-25
13 Cullen Jennings [Ballot discuss]
If shim6 proto becomes experimental, then this needs to be experimental.
2008-07-25
13 Cullen Jennings [Ballot Position Update] Position for Cullen Jennings has been changed to Discuss from No Objection by Cullen Jennings
2008-07-25
13 Cullen Jennings [Ballot discuss]
If shim6 proto becomes experimental, then this needs to be experimental.
2008-07-25
13 Mark Townsley Status date has been changed to 2009-10-1 from
2008-06-24
13 Lars Eggert [Ballot Position Update] Position for Lars Eggert has been changed to No Objection from Discuss by Lars Eggert
2008-06-24
13 (System) New version available: draft-ietf-shim6-failure-detection-13.txt
2008-06-19
13 David Ward [Ballot Position Update] Position for David Ward has been changed to No Objection from Discuss by David Ward
2008-06-06
12 (System) New version available: draft-ietf-shim6-failure-detection-12.txt
2008-03-17
13 Cullen Jennings [Ballot Position Update] Position for Cullen Jennings has been changed to No Objection from Undefined by Cullen Jennings
2008-03-17
13 Cullen Jennings [Ballot Position Update] Position for Cullen Jennings has been changed to Undefined from Discuss by Cullen Jennings
2008-02-13
13 (System) Sub state has been changed to AD Follow up from New Id Needed
2008-02-13
11 (System) New version available: draft-ietf-shim6-failure-detection-11.txt
2008-01-24
13 Amy Vezza State Changes to IESG Evaluation::Revised ID Needed from IESG Evaluation - Defer by Amy Vezza
2008-01-24
13 Russ Housley [Ballot Position Update] Position for Russ Housley has been changed to No Objection from Discuss by Russ Housley
2008-01-24
13 Lars Eggert
[Ballot discuss]
[This is an update to the original placeholder DISCUSS for Bernard's
tsv-dir review that rolls in my comments on the document.]


Section 3.3., …
[Ballot discuss]
[This is an update to the original placeholder DISCUSS for Bernard's
tsv-dir review that rolls in my comments on the document.]


Section 3.3., paragraph 6:
> Forced Bidirectional Communication (FBD), described later in this
> specification.  In addition, implementations MAY employ the following
> additional mechanisms:

  DISCUSS: All of the MAYs below are referring to techniques that are
  basically research ideas that are neither fully specified nor
  experimentally vetted - permitting them to be used is thus not
  appropriate. (See the comments marked with "MAY" below.)


Section 4.3., paragraph 0:
> 4.3.  Exploration Order

  DISCUSS: The specification of the probing algorithm needs to be made
  more precise. It remains unclear how the various timers control the
  transmission of the probe packets across all interfaces, how backoff
  is handled and retries are scheduled. Suggest to look at the ICE or
  DHCP specs for examples.


Section 7., paragraph 2:
> Keepalive Interval                          Not specified here

  DISCUSS: Where is it specified then? It's a critical parameter.
2008-01-24
13 Lars Eggert
[Ballot comment]
Section 3.3., paragraph 7:
> o  Positive feedback from upper layer protocols.  For instance, TCP
>    can indicate to the IP layer …
[Ballot comment]
Section 3.3., paragraph 7:
> o  Positive feedback from upper layer protocols.  For instance, TCP
>    can indicate to the IP layer that it is making progress.  This is
>    similar to how IPv6 Neighbor Unreachability Detection can in some
>    cases be avoided when upper layers provide information about
>    bidirectional connectivity [RFC2461].

  This is a pretty large architectural change. No transport protocol had
  to indicate to the network layer "that it is making progress" in order
  to sustain connectivity. It's also unclear what "progress" is - TCP
  connections can be idle for days, with no packets going back and
  forth. This is a feature.


Section 3.3., paragraph 9:
> o  Negative feedback from upper layer protocols.  It is conceivable
>    that upper layer protocols give an indication of a problem to the
>    multihoming layer.  For instance, TCP could indicate that there's
>    either congestion or lack of connectivity in the path because it
>    is not getting ACKs.

  TCP knows how to deal with congestion or transient lack of
  connectivity internally. TCP has no notion of indicating to the
  network layer that it should do something about the connectivity, and
  it's unclear when this new option should be used rather than reacting
  to connectivity events through congestion control.


Section 3.3., paragraph 10:
> o  ICMP error messages.  Given the ease of spoofing ICMP messages,
>    one should be careful to not trust these blindly, however.  Our
>    suggestion is to use ICMP error messages only as a hint to perform
>    an explicit reachability test or move an address pair to a lower
>    place in the list of address pairs to be probed, but not as a
>    reason to disrupt ongoing communications without other indications
>    of problems.

  If I understand this correctly, this proposed that SHIM6 hijack the
  ICMP messages that are generated in response to transport sessions.
  This is problematic, because it will prevent the transport protocols
  from reacting to these ICMP messages in the currently-specified way.
  If both SHIM6 and the transport protocol act on ICMP messages, i.e.,
  if they're not intercepted but snooped, there is a potential for
  problematic interactions between the SHIM6 response mechanism to an
  ICMP message and the transport protocol response mechanism.


Section 3.5., paragraph 1:
> Efficient congestion
> control over multiple paths is a considered research at the time this
> specification is written.

  Yes, multipath congestion control is research, and because SHIM6
  prevents transports from being aware about the actual paths that are
  available or being used (because it overloads addresses), it
  effectively prevents the use of any future multipath congestion
  control transports.


Section 1., paragraph 0:
> 1.  To avoid the other side from concluding there is a reachability
>    failure, it's necessary for a host implementing the failure
>    detection mechanism to generate periodic keepalives when there is
>    no other traffic.

  Many transport protocols went to great lengths in order to not needing
  to send keepalives when there is no payload data to be exchanged.
  Introducing keepalives at the SHIM6 layer basically eliminates the
  benefits of that design choice. Why does SHIM6 exchange keepalives to
  test connectivity if the transport protocols don't have any data to
  exchange? Also, there's already the issue with battery drain caused by
  NAT keepalives (cf. the SAFE BOF); this mechanism exacerbates this
  problem.


Section 1., paragraph 2:
>    The interval after which keepalives are sent is named Keepalive
>    Interval.  This document doesn't specify a value for Keepalive
>    Interval, but recognizes that an often used approach is sending
>    keepalives at one-half to one-third of the Keepalive Timeout
>    interval, so that multiple keepalives are generated and have time
>    to reach the correspondent before it times out.  An upper bound
>    on this interval would be (Keepalive Timeout - 2) seconds, so
>    that one keepalive has time to reach the other side, assuming a
>    maximum one-way delay of 2 seconds.

  A path that includes two GSM access links can easily have a
  propagation delay > 2 seconds. Also, if this document doesn't specify
  the intervals, which document is?


Section 6., paragraph 1:
> Section 7 provides some suggested defaults for these timeout values.
> Experience from the deployment of the SHIM6 protocol is needed in
> order to determine what values are most suitable.  The setting of
> these values is also related to various parameters in transport
> protocols, such as TCP keepalive interval.

  (From Bernard's tsv-dir review.) Negotiation of a static SHIM6
  Keepalive timeout, is allowed, if different from the default value.
  However, this relationship is not explored.  The TCP keepalive
  interval is generally kept quite large, partly out of a desire not to
  tear down idle TCP connections due to a transient failure.  The SHIM6
  keepalive interval during idle is not defined in the Failure Detection
  document, but my impression was that it could be much shorter and
  this would seem to collide with the philosophy of TCP keepalives.  So
  I'm not clear what the above sentence means.


Section 4.2., paragraph 6:
> Upon changing to a new address pair, the network path traversed most
> likely has changed, so that the ULP SHOULD be informed.  This can be
> a signal for the ULP to adapt due to the change in path so that, for
> example, TCP could initiate a slow start procedure, although it's
> likely that the circumstances that led to the selection of a new path
> already caused enough packet loss to trigger slow start.

  There is currently no clear approach for how transport protocols
  should react to connectivity change indications. Suggest to remove
  everything after and including the "for example".


Section 4.2., paragraph 7:
> Similarly, one can also envision that applications would be able to
> tell the IP or transport layer that the current connection in
> unsatisfactory and an exploration for a better one would be
> desirable.  This would require an inter-layer communication mechanism
> to be developed, however.  In any case, this is another issue that we
> treat as being outside the scope of pure address exploration.

  One can envision this, but it's completely unclear what
  "unsatisfactory" and "better" means in this regard. Also, the SHIM6
  mechanism selects *a* path, but doesn't attempt to select one
  according to a specific set of criteria. Not sure if this paragraph is
  helpful - remove?


Section 4.3., paragraph 5:
> Section 7 suggests default values for the timers associated with the
> exploration process.  The value Initial Probe Timeout (0.5 seconds)
> specifies the interval between initial attempts to send probes;
> Number of Initial Probes (4) specifies how many initial probes can be
> sent before the exponential backoff procedure needs to be employed.
> This process increases the time between every probe if there is no
> response.  Typically, each increase doubles the time but this
> specification does not mandate a particular increase.

  (From Bernard's tsv-dir review.) Interactions of SHIM6 with congestion
  control.  Section 4.3 of the Failure Detection document talks about
  exploration timeout values.  Exploration can be kicked off if no
  inbound traffic is received within Send Timeout (default = 10
  seconds). The first observation is that the Send Timeout should
  probably depend on the RTO estimate, as it does in SCTP.  Otherwise we
  could have a  network with a high RTO and SHIM6 exploration could
  commence after RTO is  backed off only a few times.  This would be
  undesirable from a congestion  control point of view. The suggested
  value of the Initial Probe Timeout (500ms) is less than RTOmin and 4
  probes can be sent before initiating exponential backoff.  This seems
  like it could violate "conservation of packets".  Why doesn't
  exponential backoff begin immediately? Instead of a static default
  Initial Probe Timeout value, might it make sense to base this on RTO
  estimates?  Again, in SCTP these issues  are handled due to
  integration with the transport layer.


Section 7., paragraph 4:
> Alternate values of the Send Timeout may be selected by a host and
> communicated to the peer in the Keepalive Timeout Option.

  Guidance is needed on appropriate and inappropriate values for the
  send timeout.
2008-01-24
13 Lars Eggert
[Ballot discuss]
Section 3.3., paragraph 6:
>    Forced Bidirectional Communication (FBD), described later in this
>    specification.  In addition, implementations MAY employ the …
[Ballot discuss]
Section 3.3., paragraph 6:
>    Forced Bidirectional Communication (FBD), described later in this
>    specification.  In addition, implementations MAY employ the following
>    additional mechanisms:

  DISCUSS: All of the MAYs below are referring to techniques that are
  basically research ideas that are neither fully specified nor
  experimentally vetted - permitting them to be used is thus not
  appropriate. (See the comments marked with "MAY" below.)


Section 4.3., paragraph 0:
> 4.3.  Exploration Order

  DISCUSS: The specification of the probing algorithm needs to be made
  more precise. It remains unclear how the various timers control the
  transmission of the probe packets across all interfaces, how backoff
  is handled and retries are scheduled. Suggest to look at the ICE or
  DHCP specs for examples.


Section 7., paragraph 2:
> Keepalive Interval                          Not specified here

  DISCUSS: Where is it specified then? It's a critical parameter.
2008-01-24
13 Dan Romascanu
[Ballot comment]
It would be appropriate to include in Section 9 a recommendation that failure detections and switch-over events to a backup path be communicated …
[Ballot comment]
It would be appropriate to include in Section 9 a recommendation that failure detections and switch-over events to a backup path be communicated via asynchronous notifications to managament systems (if available) and recorded in events logs.
2008-01-24
13 Dan Romascanu [Ballot Position Update] Position for Dan Romascanu has been changed to No Objection from Discuss by Dan Romascanu
2008-01-23
10 (System) New version available: draft-ietf-shim6-failure-detection-10.txt
2008-01-14
13 Magnus Westerlund [Ballot Position Update] Position for Magnus Westerlund has been changed to No Objection from Discuss by Magnus Westerlund
2008-01-08
13 Mark Townsley Moved up 2 weeks at Jari's request.
2008-01-08
13 Mark Townsley Telechat date was changed to 2008-01-24 from 2008-01-10 by Mark Townsley
2007-12-20
13 Russ Housley State Changes to IESG Evaluation - Defer from Waiting for AD Go-Ahead by Russ Housley
2007-12-20
13 Cullen Jennings [Ballot discuss]
If shim6 proto becomes experimental, then this needs to be experimental.
2007-12-20
13 Cullen Jennings [Ballot Position Update] Position for Cullen Jennings has been changed to Discuss from No Objection by Cullen Jennings
2007-12-20
13 Magnus Westerlund
[Ballot discuss]
The main SHIM6 protocol document discusses a bit about firewalls. I think this discussion is even more relevant in the context of REAP. …
[Ballot discuss]
The main SHIM6 protocol document discusses a bit about firewalls. I think this discussion is even more relevant in the context of REAP. If a firewall isn't SHIM6 and REAP compliant then you get very interesting cases, especially if you actually managed to get into SHIM6 mode. Sure, the intention is that shouldn't happen. But I am worried over the inconsistencies that are likely to occur because PROBE and keep-alive packets are not having a transport layer and the actual data packets do have. As I see it both the case of data getting through but not REAP and the  inverse may happen. I would like to have some discussion on these failure cases.
2007-12-20
13 Magnus Westerlund [Ballot Position Update] New position, Discuss, has been recorded by Magnus Westerlund
2007-12-20
13 Jon Peterson [Ballot Position Update] New position, No Objection, has been recorded by Jon Peterson
2007-12-20
13 Chris Newman [Ballot Position Update] New position, No Objection, has been recorded by Chris Newman
2007-12-19
13 Ross Callon [Ballot Position Update] New position, No Objection, has been recorded by Ross Callon
2007-12-19
13 David Ward
[Ballot discuss]
The semantics of the protocol and state machinery is less robust than what is defined for BFD. It is unclear why something less …
[Ballot discuss]
The semantics of the protocol and state machinery is less robust than what is defined for BFD. It is unclear why something less robust is required for this application vs reusing BFD machinery.
2007-12-19
13 David Ward [Ballot Position Update] New position, Discuss, has been recorded by David Ward
2007-12-19
13 Lisa Dusseault [Ballot Position Update] New position, No Objection, has been recorded by Lisa Dusseault
2007-12-19
13 Sam Hartman [Ballot Position Update] New position, No Objection, has been recorded by Sam Hartman
2007-12-19
13 Ron Bonica [Ballot comment]
I support Dan's comment on managability, but will let him hold the discuss
2007-12-19
13 Russ Housley
[Ballot comment]
From the SecDir by Steve Kent:
  >
  > This discussion does a good job of exploring the DoS concerns
  > …
[Ballot comment]
From the SecDir by Steve Kent:
  >
  > This discussion does a good job of exploring the DoS concerns
  > related to use of REAP with SHIM6. However, I would like to see a
  > paragraph or two explaining why the designers of REAP chose to not
  > use a protocol like IPsec to provide security for REAP. I am not
  > saying the choice made here is bad, but rather that it would be
  > useful to capture the rationale behind the choice.
  >
  I saw a response, and there seemed to be agreement that the
  requested paragraph seems like a good thing.  Where is it?
2007-12-19
13 Russ Housley
[Ballot discuss]
I have not seen a response to the Gen-ART Review by Eric Gray.
  The rewiew deserves a response.  It can be found …
[Ballot discuss]
I have not seen a response to the Gen-ART Review by Eric Gray.
  The rewiew deserves a response.  It can be found at:
 
    http://www.alvestrand.no/ietf/gen/reviews/
    draft-ietf-shim6-failure-detection-09-gray.txt

  I am especially concerned about this part of the review:
  >
  > I looked through RFC 2461 for some time and still am not sure I've
  > discovered what "valid in the sense of RFC 2461" actually means.
  >
  > Is it valid if it has a valid prefix, if it is within its valid
  > lifetime, both, neither?  Could you summarize, please?
  >
  > I did note that "tentative in the sense of RFC 2462" is far easier
  > to determine (the phrase "tentative address" is explicitly defined
  > there).
2007-12-19
13 Russ Housley [Ballot Position Update] New position, Discuss, has been recorded by Russ Housley
2007-12-19
13 Ron Bonica [Ballot Position Update] New position, No Objection, has been recorded by Ron Bonica
2007-12-19
13 Dan Romascanu
[Ballot discuss]
The document has no analysis or information related to the operational impact or manageability of the protocol. I would have expected as a …
[Ballot discuss]
The document has no analysis or information related to the operational impact or manageability of the protocol. I would have expected as a minimum that the document includes some information about possible impact on hosts and network behavior like levels of traffic, whether any parameters on hosts running the protocol are configurable and how, observability of status and performance parameters, any alarms reporting or logging.
2007-12-19
13 Dan Romascanu [Ballot Position Update] New position, Discuss, has been recorded by Dan Romascanu
2007-12-19
13 Tim Polk [Ballot Position Update] New position, No Objection, has been recorded by Tim Polk
2007-12-19
13 Mark Townsley [Ballot Position Update] New position, Yes, has been recorded for Mark Townsley
2007-12-19
13 Mark Townsley Ballot has been issued by Mark Townsley
2007-12-19
13 Cullen Jennings [Ballot Position Update] New position, No Objection, has been recorded by Cullen Jennings
2007-12-18
13 Tim Polk
[Ballot comment]
Section 4.3 Exploration Order, first sentence of paragraph 2 is slightly mangled:

  Nodes first consult the RFC 3484 default address selection rules …
[Ballot comment]
Section 4.3 Exploration Order, first sentence of paragraph 2 is slightly mangled:

  Nodes first consult the RFC 3484 default address selection rules
  [RFC3484] Section 4 rules to determine what combinations of addresses
  are allowed from a local point of view, as this reduces the search
  space.

The address selection rules in RFC 3484 are specified in sections 5 and 6; section 4
is "Candidate Source Addresses".  I believe deleting "Section 4 rules" following the
[RFC3484] reference is a complete fix.
2007-12-17
13 Lars Eggert
[Ballot discuss]
This is a placeholder DISCUSS until we're clear that the issues from Bernard Abobas tsv-dir review have been addressed: http://www1.ietf.org/mail-archive/web/ietf/current/msg49109.html

(I may add …
[Ballot discuss]
This is a placeholder DISCUSS until we're clear that the issues from Bernard Abobas tsv-dir review have been addressed: http://www1.ietf.org/mail-archive/web/ietf/current/msg49109.html

(I may add to this DISCUSS based on my own IESG review.)
2007-12-17
13 Lars Eggert [Ballot Position Update] New position, Discuss, has been recorded by Lars Eggert
2007-12-16
13 Jari Arkko [Ballot Position Update] New position, Recuse, has been recorded by Jari Arkko
2007-12-16
13 Jari Arkko Created "Approve" ballot
2007-12-03
13 Mark Townsley Placed on agenda for telechat - 2007-12-13 by Mark Townsley
2007-11-09
13 (System) State has been changed to Waiting for AD Go-Ahead from In Last Call by system
2007-11-09
13 Samuel Weiler Request for Last Call review by SECDIR Completed. Reviewer: Stephen Kent.
2007-11-07
13 Amanda Baber IANA Last Call comments:

As described in the IANA Considerations section, we understand this document
to have NO IANA Actions.
2007-10-26
13 Samuel Weiler Request for Last Call review by SECDIR is assigned to Stephen Kent
2007-10-26
13 Samuel Weiler Request for Last Call review by SECDIR is assigned to Stephen Kent
2007-10-26
13 Amy Vezza Last call sent
2007-10-26
13 Amy Vezza State Changes to In Last Call from Last Call Requested by Amy Vezza
2007-10-25
13 Mark Townsley Last Call was requested by Mark Townsley
2007-10-25
13 Mark Townsley State Changes to Last Call Requested from Publication Requested by Mark Townsley
2007-10-25
13 (System) Ballot writeup text was added
2007-10-25
13 (System) Last call text was added
2007-10-25
13 (System) Ballot approval text was added
2007-08-22
13 Jari Arkko [Note]: 'Please also read draft-ietf-shim6-applicability
Mark is handling this for Jari as he is an author' added by Jari Arkko
2007-08-16
13 Jari Arkko
(1.a)  Who is the Document Shepherd for this document?
 
          Geoff Huston
         
      …
(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 revieweed 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 Multihoming
              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 multihoming 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 implemtation 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 behaviour to report on at this
        stage.
2007-07-11
09 (System) New version available: draft-ietf-shim6-failure-detection-09.txt
2007-07-10
13 Jari Arkko [Note]: 'Mark is handling this for Jari as he is an author' added by Jari Arkko
2007-07-10
13 Jari Arkko State Changes to Publication Requested from AD is watching by Jari Arkko
2007-07-10
13 Jari Arkko Waiting for document writeup from the chairs
2007-07-10
13 Jari Arkko State Change Notice email list have been change to shim6-chairs@tools.ietf.org,draft-ietf-shim6-failure-detection@tools.ietf.org from shim6-chairs@tools.ietf.org
2007-07-10
13 Jari Arkko Intended Status has been changed to Proposed Standard from None
2007-06-27
13 (System) State Changes to AD is watching from Dead by system
2007-06-22
08 (System) New version available: draft-ietf-shim6-failure-detection-08.txt
2007-06-16
13 (System) State Changes to Dead from AD is watching by system
2007-06-16
13 (System) Document has expired
2006-12-13
07 (System) New version available: draft-ietf-shim6-failure-detection-07.txt
2006-10-19
13 Mark Townsley Draft Added by Mark Townsley in state AD is watching
2006-09-26
06 (System) New version available: draft-ietf-shim6-failure-detection-06.txt
2006-06-29
05 (System) New version available: draft-ietf-shim6-failure-detection-05.txt
2006-06-26
04 (System) New version available: draft-ietf-shim6-failure-detection-04.txt
2005-12-21
03 (System) New version available: draft-ietf-shim6-failure-detection-03.txt
2005-10-27
02 (System) New version available: draft-ietf-shim6-failure-detection-02.txt
2005-10-10
01 (System) New version available: draft-ietf-shim6-failure-detection-01.txt
2005-07-12
00 (System) New version available: draft-ietf-shim6-failure-detection-00.txt