Delay/Disruption Tolerant Networking
charter-ietf-dtn-02
Yes
No Objection
Note: This ballot was opened for revision 01-00 and is now closed.
Ballot question: "Is this charter ready for external review?"
Alvaro Retana (was Block) Yes
Zaheduzzaman Sarker Yes
Erik Kline No Objection
[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?
Lars Eggert No Objection
Martin Duke No Objection
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.
Robert Wilton (was Block) No Objection
Clearing my block based on the proposed latest charter text.
Roman Danyliw No Objection
Warren Kumari No Objection
Éric Vyncke No Objection
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).
(Benjamin Kaduk; former steering group member) No Objection
(Martin Vigoureux; former steering group member) No Objection