Depth-First Forwarding (DFF) in Unreliable Networks
RFC 6971

Approval announcement
Draft of message to be sent after approval:

From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
Cc: RFC Editor <rfc-editor@rfc-editor.org>
Subject: Document Action: 'Depth-First Forwarding in Unreliable Networks (DFF)' to Experimental RFC (draft-cardenas-dff-14.txt)

The IESG has approved the following document:
- 'Depth-First Forwarding in Unreliable Networks (DFF)'
  (draft-cardenas-dff-14.txt) as Experimental RFC

This document has been reviewed in the IETF but is not the product of an
IETF Working Group.

The IESG contact person is Ted Lemon.

A URL of this Internet Draft is:
http://datatracker.ietf.org/doc/draft-cardenas-dff/


Technical Summary 

  This document specifies the "Depth-First Forwarding" (DFF) protocol 
  for IPv6 networks, a data forwarding mechanism that can increase 
  reliability of data delivery in networks with dynamic topology 
  and/or lossy links. The protocol operates entirely on the 
  forwarding plane, but may interact with the routing plane. DFF 
  forwards data packets using a mechanism similar to a "depth-first 
  search" for the destination of a packet. The routing plane may be 
  informed of failures to deliver a packet or loops. This document 
  specifies the DFF mechanism both for IPv6 networks (as specified in 
  RFC2460) and in addition also for LoWPAN "mesh-under" networks (as 
  specified in RFC4944). 

Working Group Summary 

  This document was not adopted in a Working Group.  It might have
  been an appropriate work item for the 6lowpan working group.  Reviews
  should be requested on the 6lowpan, manet and roll mailing lists.

Document Quality 

  There are currently two known implementations of the protocol.  One 
  is used on top of IEEE 802.11 and the other on top of IEEE 
  802.15.4. The authors, through this publication hope to elicit 
  further implementation and experimentation with this protocol and 
  concept. 

  Thomas Clausen has reviewed nearly every draft of this document and 
  provided detailed comments and critiques, which have been addressed 
  by the authors. 

Personnel 

  Document Shepherd: Geoff Mulligan 
  Responsible AD: Ted Lemon

RFC Editor Note

The author has requested the following change to address a concern raised during the GEN-ART review that got missed in subsequent updates:

OLD:
If no Processed Tuple (henceforth denoted the "current tuple")
     exists in the Processed Set, with:
     +  P_orig_address = the Originator Address of the current Packet;
        AND;
     +  P_seq_number = the sequence number of the current Packet.

NEW:
If no Processed Tuple (henceforth denoted the "current tuple")
     exists in the Processed Set, where both of the following
conditions are true:
     +  P_orig_address = the Originator Address of the current Packet;
        AND;
     +  P_seq_number = the sequence number of the current Packet.

Additionally, one of the authors' addresses has changed:

Sandra C├ęspedes
scespedes@icesi.edu.co
Icesi University
Calle 18 #122-135, Pance
Cali,  Colombia
Tel +57 (2) 5552334

Also, please add Abdussalam Baryun (University of Glamorgan) to the acknowledgements.   He reviewed the document during IETF last call, but was accidentally left out of the acknowledgments.