Skip to main content

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

Yes


No Objection

(Barry Leiba)
(Brian Haberman)
(Joel Jaeggli)
(Kathleen Moriarty)
(Richard Barnes)

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 IESG member
Yes
Yes (2014-10-15 for -00-03) Unknown
I support this work, as long as Pete's issue is resolved.
Martin Stiemerling Former IESG member
Yes
Yes (2014-10-09 for -00-03) Unknown
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 IESG member
Yes
Yes (2014-10-14 for -00-03) Unknown
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 IESG member
Yes
Yes (2014-10-07 for -00-03) Unknown
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 IESG member
No Objection
No Objection (2014-10-16 for -00-03) Unknown
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 IESG member
No Objection
No Objection (2014-10-16 for -00-03) Unknown
I also support Pete's Block.
Barry Leiba Former IESG member
No Objection
No Objection (for -00-03) Unknown

                            
Benoît Claise Former IESG member
No Objection
No Objection (2014-10-16 for -00-03) Unknown
I support Pete's BLOCK.
Brian Haberman Former IESG member
No Objection
No Objection (for -00-03) Unknown

                            
Joel Jaeggli Former IESG member
No Objection
No Objection (for -00-03) Unknown

                            
Kathleen Moriarty Former IESG member
No Objection
No Objection (for -00-03) Unknown

                            
Pete Resnick Former IESG member
(was Block, Abstain) No Objection
No Objection (2014-10-20 for -00-05) Unknown
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 IESG member
No Objection
No Objection (for -00-03) Unknown

                            
Ted Lemon Former IESG member
No Objection
No Objection (2014-10-16 for -00-03) Unknown
I support discussing Pete's block. :)