Skip to main content

Delay/Disruption Tolerant Networking
charter-ietf-dtn-02

Revision differences

Document history

Date Rev. By Action
2024-03-18
02 Liz Flynn Responsible AD changed to Erik Kline from Zaheduzzaman Sarker
2021-12-17
02 Cindy Morgan New version available: charter-ietf-dtn-02.txt
2021-12-17
01-04 Cindy Morgan State changed to Approved from External Review (Message to Community, Selected by Secretariat)
2021-12-17
01-04 Cindy Morgan IESG has approved the charter
2021-12-17
01-04 Cindy Morgan Closed "Approve" ballot
2021-12-17
01-04 Cindy Morgan WG action text was changed
2021-12-17
01-04 Cindy Morgan Added milestone "Key Management Protocol", due July 2024, from current group milestones
2021-12-17
01-04 Cindy Morgan Added milestone "Delay-Tolerant Management Protocols", due March 2024, from current group milestones
2021-12-17
01-04 Cindy Morgan Added milestone "Neighbor/Peer Discovery Protocol Specification", due November 2023, from current group milestones
2021-12-17
01-04 Cindy Morgan Added milestone "QoS/Flow Extension Block", due July 2023, from current group milestones
2021-12-17
01-04 Cindy Morgan Added milestone "Bundle-in-Bundle Encapsulation", due July 2023, from current group milestones
2021-12-17
01-04 Cindy Morgan Added milestone "Bundle Progress Signalling", due March 2023, from current group milestones
2021-12-17
01-04 Cindy Morgan Added milestone "Naming and Addressing Architecture Document", due March 2023, from current group milestones
2021-12-17
01-04 Cindy Morgan Added milestone "Delay-Tolerant Management Architecture", due July 2022, from current group milestones
2021-12-17
01-04 Cindy Morgan New version to move milestones out of charter text and into milestone area
2021-12-17
01-04 Cindy Morgan New version available: charter-ietf-dtn-01-04.txt
2021-12-17
01-03 Zaheduzzaman Sarker New version available: charter-ietf-dtn-01-03.txt
2021-12-02
01-02 Francesca Palombini [Ballot Position Update] New position, No Objection, has been recorded for Francesca Palombini
2021-12-01
01-02 Benjamin Kaduk
[Ballot comment]
    This architecture will define a standard model
    for the forwarding process of a Bundle Process Agent, providing an
  …
[Ballot comment]
    This architecture will define a standard model
    for the forwarding process of a Bundle Process Agent, providing an
    informational reference point for further specifications.

There seems to be some mismatch between "standard model" and
"informational reference point".  If it's not intended to be in a
standards-track document, perhaps "reference model" would avoid the
difficulty?

  * The definition of architecture and protocols in the areas of Operations,
  Administration and Management (OAM), and Key Management

(nit) I think "an architecture" is needed here.

    Additional extensions to the Bundle Protocol, additional Security Context
    definitions for BPSec, and new Convergence Layer adaptors will be
    considered on a case-by-case basis by the working group.

Can we say anything about what factors will go into these considerations
(other than, presumably, WG interest)?  Will the reponsible AD need to
be involved in the decision to undertake such work?
2021-12-01
01-02 Benjamin Kaduk [Ballot Position Update] New position, No Objection, has been recorded for Benjamin Kaduk
2021-12-01
01-02 Roman Danyliw [Ballot Position Update] New position, No Objection, has been recorded for Roman Danyliw
2021-12-01
01-02 Robert Wilton [Ballot Position Update] New position, No Objection, has been recorded for Robert Wilton
2021-11-30
01-02 Erik Kline [Ballot Position Update] New position, No Objection, has been recorded for Erik Kline
2021-11-30
01-02 Éric Vyncke
[Ballot comment]
I am puzzled by merging two different aspects in a single category: "Operations, Administration and Management (OAM), and Key Management". The first one …
[Ballot comment]
I am puzzled by merging two different aspects in a single category: "Operations, Administration and Management (OAM), and Key Management". The first one is clearly OPS but the second one is probably more in SEC area.

What is the meaning of QoS and QoS indication in such networks ?

Should there be a collaboration with intarea WG about the tunnels ?

While there is a "Management Architecture and Protocols" milestone, there are none about "operations and administration" (to fully fit the OAM category).

Some nits ?:
- s/in production by government and commercial organizations world-wide./in production by governments and commercial organizations world-wide./
- s/Operations, Administration and Management/Operations, Administration, and Management/
- s/best practices learned from existing deployment./best practices learned from existing deployments./
2021-11-30
01-02 Éric Vyncke [Ballot Position Update] New position, No Objection, has been recorded for Éric Vyncke
2021-11-29
01-02 Murray Kucherawy [Ballot Position Update] New position, No Objection, has been recorded for Murray Kucherawy
2021-11-29
01-02 Zaheduzzaman Sarker [Ballot Position Update] New position, Yes, has been recorded for Zaheduzzaman Sarker
2021-11-26
01-02 Martin Vigoureux [Ballot Position Update] New position, No Objection, has been recorded for Martin Vigoureux
2021-11-18
01-02 Martin Duke [Ballot Position Update] New position, No Objection, has been recorded for Martin Duke
2021-11-11
01-02 Cindy Morgan Telechat date has been changed to 2021-12-02 from 2021-09-09
2021-11-11
01-02 Cindy Morgan Created "Approve" ballot
2021-11-11
01-02 Cindy Morgan Closed "Ready for external review" ballot
2021-11-11
01-02 Cindy Morgan State changed to External Review (Message to Community, Selected by Secretariat) from Start Chartering/Rechartering (Internal Steering Group/IAB Review)
2021-11-11
01-02 Cindy Morgan WG new work message text was changed
2021-11-11
01-02 Cindy Morgan WG review text was changed
2021-11-11
01-02 Cindy Morgan WG review text was changed
2021-11-11
01-02 Cindy Morgan WG review text was changed
2021-11-09
01-02 Alvaro Retana [Ballot Position Update] Position for Alvaro Retana has been changed to Yes from Block
2021-11-09
01-02 Zaheduzzaman Sarker New version available: charter-ietf-dtn-01-02.txt
2021-11-02
01-01 Robert Wilton [Ballot comment]
Clearing my block based on the proposed latest charter text.
2021-11-02
01-01 Robert Wilton [Ballot Position Update] Position for Robert Wilton has been changed to No Objection from Block
2021-10-30
01-01 Zaheduzzaman Sarker New version available: charter-ietf-dtn-01-01.txt
2021-09-09
01-00 Robert Wilton
[Ballot block]
Sorry for putting a block on this charter, but the charter for this WG seems to be moving significantly into the network management …
[Ballot block]
Sorry for putting a block on this charter, but the charter for this WG seems to be moving significantly into the network management space.

In particular, this work seems to be predicated on the assumption that it better to define a custom management protocol and data modelling language for the DTN use case rather than reusing, or extending, the existing network management work defined in NETMOD and NETCONF WGs.  This may be the right answer, but it not intuitively obvious to me that this is the case (some further details provided in the comment section).

(1) There needs to be more discussion with relevant WGs (NETCONF, NETMOD, CORE) to understand whether the existing network management protocols and data modelling language could cover the DTN use case, or be reasonably extended to do so.

(2) If there is consensus that the existing IETF management stack can be reasonably extended to cover the DTN use case, then there should be discussion about where that work is done, which would depend on the specific nature of the work.

(3) Otherwise, if the consensus is that an entirely separate management stack is appropriate, then I think that the solution needs to be tightly constrained to the DTN use case, and not framed as a generic asynchronous management architecture.

Rob
2021-09-09
01-00 Robert Wilton
[Ballot comment]
Looking at the charter, and specifically at draft-ietf-dtn-ama-01, Asynchronous Management Architecture (which is in DTN WGLC), it seems to be built on …
[Ballot comment]
Looking at the charter, and specifically at draft-ietf-dtn-ama-01, Asynchronous Management Architecture (which is in DTN WGLC), it seems to be built on the following assumptions:
- network management is generally synchronous

- A different data modelling language (i.e., not YANG) is required to model asynchronous management data

- There are no efficient encodings of management data modelled in YANG.


But I don't think that these assumptions necessarily hold:
- NMDA, RFC 8342, was architected with a goal of supporting an eventual consistency model (specifically, supporting a temporal separation between sending the desired configuration to a device and the device enacting that configuration)

- In addition to NETCONF, there are also the RESTCONF and CoAP management interface protocols that could be considered.

- YANG Push, RFC 8641, allows for subscriptions to be notified of when data changes, or periodic updates.  I.e., entirely push rather than pull.

- YANG just models data and that should have no bearing on whether the protocol mechanisms used to move that data are synchronous or asynchronous.

- The CBOR and CBOR SID encodings of YANG data encode the data in a compact binary format.
2021-09-09
01-00 Robert Wilton Ballot comment and discuss text updated for Robert Wilton
2021-09-09
01-00 Robert Wilton
[Ballot block]
Sorry for putting a block on this charter, but the charter for this WG seems to be moving significantly into the network management …
[Ballot block]
Sorry for putting a block on this charter, but the charter for this WG seems to be moving significantly into the network management space.

In particular, this work seems to be predicated on the assumption that it better to define a custom management protocol and data modelling language for the DTN use case rather than reusing, or extending, the existing network management work defined in NETMOD and NETCONF WGs.  This may be the right answer, but it not intuitively obvious to me that this is the case (some further details provided in the comment section).

(1) There needs to be more discussion with relevant WGs (NETCONF, NETMOD, CORE) to understand whether the existing network management protocols and data modelling language could cover the DTN use case, or be reasonably extended to do so.
(2) If there is consensus that the existing IETF management stack can be reasonably extended to cover the DTN use case, then there should be discussion about where that work is done, which would depend on the specific nature of the work.
(3) Otherwise, if the consensus is that an entirely separate management stack is appropriate, then I think that the solution needs to be tightly constrained to the DTN use case, and not framed as a generic asynchronous management architecture.

Rob
2021-09-09
01-00 Robert Wilton
[Ballot comment]
Looking at the charter, and specifically at draft-ietf-dtn-ama-01, Asynchronous Management Architecture (which is in DTN WGLC), it seems to be built on …
[Ballot comment]
Looking at the charter, and specifically at draft-ietf-dtn-ama-01, Asynchronous Management Architecture (which is in DTN WGLC), it seems to be built on the following assumptions:
- network management is generally synchronous
- A different data modelling language (i.e., not YANG) is required to model asynchronous management data
- There are no efficient encodings of management data modelled in YANG.

But I don't think that these assumptions necessarily hold:
- NMDA, RFC 8342, was architected with a goal of supporting an eventual consistency model (specifically, supporting a temporal separation between sending the desired configuration to a device and the device enacting that configuration)
- In addition to NETCONF, there are also the RESTCONF and CoAP management interface protocols that could be considered.
- YANG Push, RFC 8641, allows for subscriptions to be notified of when data changes, or periodic updates.  I.e., entirely push rather than pull.
- YANG just models data and that should have no bearing on whether the protocol mechanisms used to move that data are synchronous or asynchronous.
- The CBOR and CBOR SID encodings of YANG data encode the data in a compact binary format.
2021-09-09
01-00 Robert Wilton [Ballot Position Update] New position, Block, has been recorded for Robert Wilton
2021-09-08
01-00 Warren Kumari [Ballot Position Update] New position, No Objection, has been recorded for Warren Kumari
2021-09-08
01-00 Benjamin Kaduk [Ballot Position Update] New position, No Objection, has been recorded for Benjamin Kaduk
2021-09-08
01-00 Roman Danyliw [Ballot Position Update] New position, No Objection, has been recorded for Roman Danyliw
2021-09-08
01-00 Martin Duke
[Ballot comment]
For the Addressing, OAM, and Key Management work, it would be good to have a sentence or two about what is currently being …
[Ballot comment]
For the Addressing, OAM, and Key Management work, it would be good to have a sentence or two about what is currently being done in deployed networks for these areas. Presumably *something* is happening, even if it's manual assignment and sneakernet configuration, and it would help to establish the need for the work if we understood the status quo.
2021-09-08
01-00 Martin Duke [Ballot Position Update] New position, No Objection, has been recorded for Martin Duke
2021-09-08
01-00 Martin Vigoureux [Ballot Position Update] New position, No Objection, has been recorded for Martin Vigoureux
2021-09-07
01-00 Alvaro Retana
[Ballot block]
Even though the charter explicitly excludes Routing in DTN, the text gives the impression that this WG will eventually do the work.  Given …
[Ballot block]
Even though the charter explicitly excludes Routing in DTN, the text gives the impression that this WG will eventually do the work.  Given that there is no routing work at the moment, I see no need to include the related text in the charter. 

When candidate solutions exist, we can then discuss the proper place to work on them.  Disclaimer: I am partial to doing routing work in the Routing Area.

If routing-related topics do come up, I would appreciate coordination with both the manet and rtgwg WGs.  manet works on ad-hoc networks, which have a strong relationship with disruption-tolerant networks.  rtgwg is chartered with the dispatch-like function of discussing where routing work should be done (if it doesn't clearly fit in an existing WG).
2021-09-07
01-00 Alvaro Retana
[Ballot comment]
(1) "The Working Group has submitted...for publication as standards track RFCs."

The publication of this work will soon result in this text becoming …
[Ballot comment]
(1) "The Working Group has submitted...for publication as standards track RFCs."

The publication of this work will soon result in this text becoming stale. So instead, simply mention the WG has produced these documents.


(2) "The definition of protocols and best practices in the areas of Operations, Administration and Management (OAM), and Key Management"

Because of the nature of the networks, AMP is strongly related to ad-hoc networks. Therefore, please coordinate with the manet WG.


(3) s/Network (DTN)/Networking (DTN)


(4) s/future work items/work items
The items are now current. ;-)
2021-09-07
01-00 Alvaro Retana [Ballot Position Update] New position, Block, has been recorded for Alvaro Retana
2021-09-06
01-00 Lars Eggert [Ballot Position Update] New position, No Objection, has been recorded for Lars Eggert
2021-09-02
01-00 Zaheduzzaman Sarker [Ballot Position Update] New position, Yes, has been recorded for Zaheduzzaman Sarker
2021-09-01
01-00 Éric Vyncke
[Ballot comment]
This WG is one of the most fascinating IMHO.

Glad to read "Multiple independent implementations exist for these technologies and multiple deployments in …
[Ballot comment]
This WG is one of the most fascinating IMHO.

Glad to read "Multiple independent implementations exist for these technologies and multiple deployments in space and terrestrial environments,": this is useful to make a decision on the rechartering.

Some questions:

1/ for the work item "An architecture for Naming, Addressing and Forwarding", the description is mainly/only about naming. Suggest to add a little more on addressing and forwarding.

2/ I wonder why OAM and key management are put in the same bullet as the problems and use cases for OAM & key management are probably different.

3/ protocol extensions, it is unclear to me what is the intend here. E.g., about tunneling, is it to tunnel bundles over an underlay or is it to tunnel other protocols over a DTN underlay? The list of work items makes it a little clearer though but consistency among the work item lists and the 3 work categories would be a plus.

4/ is there any chance to have another name for 'neighbor discovery' as it collides with IPv6 NDP ;-)

Finally, I would like to have a mention of cross-WG last calls somewhere in the charter as there are potential overlaps (e.g., other WG have experiences members on tunneling, ops, data models, naming).
2021-09-01
01-00 Éric Vyncke [Ballot Position Update] New position, No Objection, has been recorded for Éric Vyncke
2021-08-27
01-00 Erik Kline
[Ballot comment]
[nit]

* The final sentence of the first paragraph is seems like a bit of a
  run-on sentence.

  Suggest:

    …
[Ballot comment]
[nit]

* The final sentence of the first paragraph is seems like a bit of a
  run-on sentence.

  Suggest:

    - s/and multiple/with multiple/
    - s/, and the technology/. The technology/

[ comment ]

* For OAM and key management one customary chunk of text is usually
  a list of working groups whose advice and reviews might play an
  important role.


  WRT OAM for DTN there might not be such a working group, but it seems
  like for key management there ought to be expertise in one or more
  SEC area groups?
2021-08-27
01-00 Erik Kline [Ballot Position Update] New position, No Objection, has been recorded for Erik Kline
2021-08-25
01-00 Cindy Morgan Telechat date has been changed to 2021-09-09 from 2014-10-30
2021-08-25
01-00 Zaheduzzaman Sarker WG action text was changed
2021-08-25
01-00 Zaheduzzaman Sarker WG review text was changed
2021-08-25
01-00 Zaheduzzaman Sarker WG review text was changed
2021-08-25
01-00 Zaheduzzaman Sarker Created "Ready for external review" ballot
2021-08-25
01-00 Zaheduzzaman Sarker State changed to Start Chartering/Rechartering (Internal Steering Group/IAB Review) from Draft Charter
2021-08-25
01-00 Zaheduzzaman Sarker State changed to Draft Charter from Approved
2021-08-25
01-00 Zaheduzzaman Sarker New version available: charter-ietf-dtn-01-00.txt
2021-03-10
01 Amy Vezza Responsible AD changed to Zaheduzzaman Sarker from Magnus Westerlund
2019-03-27
01 Amy Vezza Responsible AD changed to Magnus Westerlund from Spencer Dawkins
2018-01-30
01 Amy Vezza Responsible AD changed to Spencer Dawkins from Martin Stiemerling
2015-10-14
01 (System) Notify list changed from marc.blanchet@viagenie.ca, Fred.L.Templin@boeing.com, dtn@ietf.org to Fred.L.Templin@boeing.com
2014-11-07
01 Cindy Morgan New version available: charter-ietf-dtn-01.txt
2014-11-07
00-06 Cindy Morgan State changed to Approved from IESG review
2014-11-07
00-06 Cindy Morgan IESG has approved the charter
2014-11-07
00-06 Cindy Morgan Closed "Approve" ballot
2014-11-07
00-06 Cindy Morgan Closed "Ready for external review" ballot
2014-11-07
00-06 Cindy Morgan WG action text was changed
2014-11-07
00-06 Cindy Morgan New version to fix line breaks.
2014-11-07
00-06 Cindy Morgan New version available: charter-ietf-dtn-00-06.txt
2014-11-07
00-05 Cindy Morgan WG action text was changed
2014-10-30
00-05 Alia Atlas [Ballot Position Update] New position, No Objection, has been recorded for Alia Atlas
2014-10-30
00-05 Spencer Dawkins [Ballot comment]
Thank you for confirming with CCSDS!
2014-10-30
00-05 Spencer Dawkins [Ballot Position Update] New position, Yes, has been recorded for Spencer Dawkins
2014-10-30
00-05 Stephen Farrell
[Ballot comment]

As I said in the previous round of charter review: this is IMO the wrong
target but has rough consensus so I hope …
[Ballot comment]

As I said in the previous round of charter review: this is IMO the wrong
target but has rough consensus so I hope it works out for 'em.
2014-10-30
00-05 Stephen Farrell [Ballot Position Update] New position, Yes, has been recorded for Stephen Farrell
2014-10-30
00-05 Jari Arkko [Ballot Position Update] New position, Yes, has been recorded for Jari Arkko
2014-10-30
00-05 Benoît Claise
[Ballot comment]
No objection to the content.
However, be consistent with DTN. What does it stand for?
In the charter title: Delay Tolerant Networking
First …
[Ballot comment]
No objection to the content.
However, be consistent with DTN. What does it stand for?
In the charter title: Delay Tolerant Networking
First charter sentence: The Delay/Disruption Tolerant Network Working Group (DTNWG)
Second charter sentence: Delay-Tolerant Networking (DTN) protocols
2014-10-30
00-05 Benoît Claise [Ballot Position Update] New position, No Objection, has been recorded for Benoit Claise
2014-10-30
00-05 Joel Jaeggli [Ballot Position Update] New position, No Objection, has been recorded for Joel Jaeggli
2014-10-29
00-05 Richard Barnes [Ballot Position Update] New position, No Objection, has been recorded for Richard Barnes
2014-10-29
00-05 Kathleen Moriarty [Ballot Position Update] New position, No Objection, has been recorded for Kathleen Moriarty
2014-10-29
00-05 Ted Lemon [Ballot Position Update] New position, No Objection, has been recorded for Ted Lemon
2014-10-29
00-05 Adrian Farrel [Ballot Position Update] New position, No Objection, has been recorded for Adrian Farrel
2014-10-29
00-05 Barry Leiba [Ballot Position Update] New position, No Objection, has been recorded for Barry Leiba
2014-10-29
00-05 Martin Stiemerling [Ballot Position Update] New position, Yes, has been recorded for Martin Stiemerling
2014-10-29
00-05 Brian Haberman [Ballot Position Update] New position, No Objection, has been recorded for Brian Haberman
2014-10-29
00-05 Pete Resnick [Ballot Position Update] New position, No Objection, has been recorded for Pete Resnick
2014-10-29
00-05 Martin Stiemerling Created "Approve" ballot
2014-10-29
00-05 Martin Stiemerling State changed to IESG review from External review
2014-10-20
00-05 Amy Vezza Telechat date has been changed to 2014-10-30 from 2014-10-16
2014-10-20
00-05 Amy Vezza State changed to External review from Internal review
2014-10-20
00-05 Amy Vezza WG review text was changed
2014-10-20
00-05 Pete Resnick
[Ballot comment]
The latest version makes it clear that the use cases work items need not be a document, but makes it clear that the …
[Ballot comment]
The latest version makes it clear that the use cases work items need not be a document, but makes it clear that the other two items are documents. That satisfies me.
2014-10-20
00-05 Pete Resnick [Ballot Position Update] Position for Pete Resnick has been changed to No Objection from Block
2014-10-20
00-05 Martin Stiemerling New version available: charter-ietf-dtn-00-05.txt
2014-10-16
00-04 Martin Stiemerling
Changed charter milestone "Submit DTN Revision Problem Statement, Use Cases, Requirements and Development Strategy document (informational) to IESG. ", set description to "Use Cases for …
Changed charter milestone "Submit DTN Revision Problem Statement, Use Cases, Requirements and Development Strategy document (informational) to IESG. ", set description to "Use Cases for evolving the DTN specifications and list of work items to be worked on."
2014-10-16
00-04 Martin Stiemerling New version available: charter-ietf-dtn-00-04.txt
2014-10-16
00-03 Alia Atlas [Ballot comment]
I also support Pete's Block.
2014-10-16
00-03 Alia Atlas [Ballot Position Update] New position, No Objection, has been recorded for Alia Atlas
2014-10-16
00-03 Benoît Claise [Ballot comment]
I support Pete's BLOCK.
2014-10-16
00-03 Benoît Claise [Ballot Position Update] New position, No Objection, has been recorded for Benoit Claise
2014-10-16
00-03 Ted Lemon [Ballot comment]
I support discussing Pete's block. :)
2014-10-16
00-03 Ted Lemon [Ballot Position Update] New position, No Objection, has been recorded for Ted Lemon
2014-10-16
00-03 Adrian Farrel
[Ballot comment]
I don't object to this being taken on as IETF work if there is a critical mass of people willing to do the …
[Ballot comment]
I don't object to this being taken on as IETF work if there is a critical mass of people willing to do the work. I leave it to the responsible AD to make that judgement.

I am nervous about the scope of update to 5050. There is certainly text in the charter that makes it clear that updates are in scope:

  In this context, there is a need to
  update the base specifications, i.e., RFC 5050, [snip]
  based on the deployment and implementation experience
  as well as the new use cases

That would be fine, but my nervousness is that changes, updates, and improvements to 5050 will be resisted because of the existing implementations and deployments. I suppose I am old and cynical (and probably tired), but all too often the objective "move this work onto the Standards Track" outweighs any attempt to improve the work.

If this could be resolved by tightening the text in the charter I would not object.
2014-10-16
00-03 Adrian Farrel [Ballot Position Update] New position, No Objection, has been recorded for Adrian Farrel
2014-10-16
00-03 Joel Jaeggli [Ballot Position Update] New position, No Objection, has been recorded for Joel Jaeggli
2014-10-15
00-03 Richard Barnes [Ballot Position Update] New position, No Objection, has been recorded for Richard Barnes
2014-10-15
00-03 Jari Arkko [Ballot comment]
I support this work, as long as Pete's issue is resolved.
2014-10-15
00-03 Jari Arkko [Ballot Position Update] New position, Yes, has been recorded for Jari Arkko
2014-10-15
00-03 Kathleen Moriarty [Ballot Position Update] New position, No Objection, has been recorded for Kathleen Moriarty
2014-10-15
00-03 Pete Resnick
[Ballot block]
Martin asked that I update my position to supply the suggested text, and to explicitly say "Block" so that we can discuss this …
[Ballot block]
Martin asked that I update my position to supply the suggested text, and to explicitly say "Block" so that we can discuss this on the call.

I do not understand the "Problem Statement/etc." work item for this WG. This work is the result of an IRTF RG doing a lot of work and research and there are already existing experimental protocol documents. Coming up with a new "Problem Statement/etc." document seems like a perfect way for this WG to rathole and waste an incredible amount of time. If you're going to update the protocol documents to conform to implementation experience, there's no need to re-explore what problem you're trying to solve. Unless there's a darn good reason to take on that work item, I really think it needs to be removed. Suggest:

OLD
  Therefore, the purpose of the working group is to document the new
  use cases and requirements and to update the base specifications. The
  group shall not endeavour to change the underlying architecture or
  the bundle protocol principle.

  Work items are:

  o An informational "DTN Revision Problem Statement, Use Cases,
    Requirements and Development Strategy" document

  o Updates to RFC5050, convergence layer RFCs, security(RFC6257), as
    standard track documents.

  o A registry for DTN Service Identifiers

  The DTNWG must reach rough consensus on the "DTN Revision Problem
  Statement, Use Cases, Requirements and Development Strategy" document
  before the working group is permitted to work on any updates to the
  protocol specifications.

NEW
  Therefore, the purpose of this working group is to update the base
  specifications in light of implementation experience. The group shall
  do a review of deployment problems and lessons learned, come to
  consensus on the issues to be addressed in the base protocol
  documents, and update the specifications accordingly. The group shall
  not endeavour to change the underlying architecture or the bundle
  protocol principle.

  Work items are:

  o Updates to RFC5050, convergence layer RFCs, security(RFC6257), as
    standard track documents.

  o A registry for DTN Service Identifiers

END
2014-10-15
00-03 Pete Resnick [Ballot Position Update] Position for Pete Resnick has been changed to Block from Abstain
2014-10-15
00-03 Brian Haberman [Ballot Position Update] New position, No Objection, has been recorded for Brian Haberman
2014-10-14
00-03 Spencer Dawkins
[Ballot comment]
I''m broudly a "yes", but I'm trusting Martin to come up with text that basically says that the working group needs to decide …
[Ballot comment]
I''m broudly a "yes", but I'm trusting Martin to come up with text that basically says that the working group needs to decide what's the document needs to contain, rather than figure that out along the way. I don't know that the working list needs to be another document, but I do think life would be better for the working group if people weren't popping up with "and we could add this" during working group last call.

I think that's roughly consistent with what Martin thinks he's doing with the charter. If people think that's not what's happening, we'll talk, of course.
2014-10-14
00-03 Spencer Dawkins Ballot comment text updated for Spencer Dawkins
2014-10-14
00-03 Spencer Dawkins
[Ballot comment]
I''m broudly a "yes", but I'm trusting Martin to come up with text that basically says that the working group needs to decide …
[Ballot comment]
I''m broudly a "yes", but I'm trusting Martin to come up with text that basically says that the working group needs to decide what's the document needs to contain, rather than figure that out along the way. I don't know that the working list needs to be another document, but I do think life would be better if people weren't popping up with "and we could add this" during working group last call.

I think that's roughly consistent with what Martin thinks he's doing with the charter. If people think that's not what's happening, we'll talk, of course.
2014-10-14
00-03 Spencer Dawkins [Ballot Position Update] New position, Yes, has been recorded for Spencer Dawkins
2014-10-12
00-03 Pete Resnick
[Ballot comment]
[Note to IESG: Yet another thing to consider about the charter tooling: What is the right ballot position to take for this ballot? …
[Ballot comment]
[Note to IESG: Yet another thing to consider about the charter tooling: What is the right ballot position to take for this ballot? I picked "Abstain" only because it's really not the case that I have "No Objection", but there's no effective difference between the positions.]

I will not block external review on this basis, but I would really like to hear an explanation before the end of external review:

I do not understand the "Problem Statement/etc." work item for this WG. This work is the result of an IRTF RG doing a lot of work and research and there are already existing experimental protocol documents. Coming up with a new "Problem Statement/etc." document seems like a perfect way for this WG to rathole and waste an incredible amount of time. If you're going to update the protocol documents to conform to implementation experience, there's no need to re-explore what problem you're trying to solve. Unless there's a darn good reason to take on that work item, I really think it needs to be removed.
2014-10-12
00-03 Pete Resnick [Ballot Position Update] New position, Abstain, has been recorded for Pete Resnick
2014-10-10
00-03 Barry Leiba [Ballot Position Update] New position, No Objection, has been recorded for Barry Leiba
2014-10-09
00-03 Martin Stiemerling
[Ballot comment]
An editorial request from one of the BOF chairs:

The base RFCs should be listed in increasing number order (i.e., as RFC5050, …
[Ballot comment]
An editorial request from one of the BOF chairs:

The base RFCs should be listed in increasing number order (i.e., as RFC5050, RFC6257, RFC6260, RFC7122, RFC7242).

I will fix this before sending the charter out.
2014-10-09
00-03 Martin Stiemerling Ballot comment text updated for Martin Stiemerling
2014-10-07
00-03 Martin Stiemerling Notification list changed to marc.blanchet@viagenie.ca, Fred.L.Templin@boeing.com, dtn@ietf.org from marc.blanchet@viagenie.ca, Fred.L.Templin@boeing.com
2014-10-07
00-03 Stephen Farrell
[Ballot comment]

As some of you may know I think this charter is aiming for the wrong
target, but I already raised that point on …
[Ballot comment]

As some of you may know I think this charter is aiming for the wrong
target, but I already raised that point on the list and it was discussed
and I and a few others are in the rough and there're a bunch of folks
who want to pursue this, so in the end I'm a yes for forming this wg
with this charter.
2014-10-07
00-03 Stephen Farrell [Ballot Position Update] New position, Yes, has been recorded for Stephen Farrell
2014-10-07
00-03 Martin Stiemerling Notification list changed to marc.blanchet@viagenie.ca, Fred.L.Templin@boeing.com
2014-10-07
00-03 Martin Stiemerling [Ballot Position Update] New position, Yes, has been recorded for Martin Stiemerling
2014-10-07
00-03 Martin Stiemerling Placed on agenda for telechat - 2014-10-16
2014-10-07
00-03 Martin Stiemerling WG action text was changed
2014-10-07
00-03 Martin Stiemerling WG review text was changed
2014-10-07
00-03 Martin Stiemerling Created "Ready for external review" ballot
2014-10-07
00-03 Martin Stiemerling State changed to Internal review from Informal IESG review
2014-10-07
00-03 Martin Stiemerling New version available: charter-ietf-dtn-00-03.txt
2014-10-07
00-02 Martin Stiemerling New version available: charter-ietf-dtn-00-02.txt
2014-10-07
00-01 Martin Stiemerling Added charter milestone "Submit DTN Revision Problem Statement, Use Cases, Requirements and Development Strategy document (informational) to IESG. ", due April 2015
2014-10-07
00-01 Martin Stiemerling New version available: charter-ietf-dtn-00-01.txt
2014-10-07
00-00 Martin Stiemerling Initial review time expires 2014-10-14
2014-10-07
00-00 Martin Stiemerling State changed to Informal IESG review from Not currently under review
2014-10-07
00-00 Martin Stiemerling New version available: charter-ietf-dtn-00-00.txt