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

• Ready for external review (00-03)
• Approve (00-05)
• Ready for external review (01-00)
• Approve (01-02)

Note: This ballot was opened for revision 00-03 and is now closed.

Ballot question: "Is this charter ready for external review?"

(Jari Arkko; former steering group member) Yes

I support this work, as long as Pete's issue is resolved.

(Martin Stiemerling; former steering group member) Yes

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.

(Spencer Dawkins; former steering group member) Yes

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.

(Stephen Farrell; former steering group member) Yes

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.

(Adrian Farrel; former steering group member) No Objection

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.

(Alia Atlas; former steering group member) No Objection

I also support Pete's Block.

(Barry Leiba; former steering group member) No Objection

(Benoît Claise; former steering group member) No Objection

I support Pete's BLOCK.

(Brian Haberman; former steering group member) No Objection

(Joel Jaeggli; former steering group member) No Objection

(Kathleen Moriarty; former steering group member) No Objection

(Pete Resnick; former steering group member) (was Block, Abstain) No Objection

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.

(Richard Barnes; former steering group member) No Objection

(Ted Lemon; former steering group member) No Objection

I support discussing Pete's block. :)