Subject: Re: [dtn] DTN WG updated charter milestones

From: "Marc Blanchet" <[email-masked]>
Date: Fri, 04 Oct 2019 15:25:41 -0400

hello,
  seen some support, no opposition, but would be better if we get more 
people agree/disagree so chairs get a better view of the support. Please 
send your support/unsupport/comments.

Marc.

On 18 Sep 2019, at 16:27, Marc Blanchet wrote:

> as it seems that formatting got lost for some/all members, attached is 
> a PDF equivalent
>
> Regards, Marc.
>
> On 18 Sep 2019, at 15:57, Marc Blanchet wrote:
>
>> Hello,
>>  following our discussion during the interim meeting today, I have 
>> grouped the agreed milestones as follows. This email is a call for 
>> comments on these milestones. Please show support or comment by 
>> friday sept 27th, so co-chairs get a good view of the working group. 
>> If agreed, then we will forward this to our AD for consideration.
>>
>> Marc.
>>
>> DTN WG Updated Charter Milestones
>>
>> Bundle Protocol Additional Blocks
>>   Bundle-in-Bundle Encapsulation (D)
>>   Manifest block
>> Neighbor Discovery (X)
>> Naming and Addressing
>>   Naming (X)
>>   Addressing (X)
>>   Registry of Service Identifiers
>> Asynchronous Management
>>   AMA Application Data Model (ADM) (D)
>>   Asynchronous Management Protocol (D)
>>   Asynchronous Management Protocol Agent ADM (D)
>>   Various protocol components agent ADM (D)
>> Security Key Management (D)
>> Additional Convergence Layers (X)
>>
>> Legend:
>> D an active or recent draft exists on this topic
>> X RFCs or draft from dtnrg exists on this topic

---

From: Magnus Westerlund <[email-masked]>
Date: Mon, 7 Oct 2019 08:11:37 +0000

WG,

As AD I would be very hesitant to approve that much work as milestones. I think
you do need a prioritization discussion on which work is most important. What
should be done first, and what can be done after that. 

I would also call to attention the WG's charter (included below) that in one
interpretation is to basically make improved standards track versions of what
existed in the research groups. Another interpretation may allow more work.
Still we need to consider if certain work items should result in a recharter. A
Re-charter can also ensure that the rest of IETF knows what you are up to and
also avoid issues in the future if an AD would object to something being part of
the work of this WG. I personally would prefer to see that the Asynchronous
Management, and Security management would be explicitly included. I think the
naming and addressing, as well as neighbour discovery can be fitted into
existing charter. So can also the Bundle-in-Bundle encapsualtion and the
manifest. 

DTN Charter:

The Delay/Disruption Tolerant Network Working Group (DTNWG) specifies
mechanisms
for data communications in the presence of long delays and/or
intermittent
connectivity. Delay-Tolerant Networking (DTN) protocols
have been the subject of
extensive research and development in the
Delay-Tolerant Networking Research
Group (DTNRG) of the Internet
Research Task Force since 2002.  The key documents
are the DTN
Architecture  (RFC 4838), the Bundle Protocol (RFC 5050), Licklider
Tr
ansmission Protocol (RFC 5326) and convergence layers (RFC 7122,
7242). Multiple
independent implementations exist for these technologies
and multiple deployments
in space and terrestrial environments.  There
is an increase interest in the
commercial world for these technologies,
for similar and different use cases,
such as unmanned air vehicles.  In
this context, there is a need to update the
base specifications, i.e.,
RFC 5050, RFC 7122, RFC 7242, RFC 6257 and RFC
6260,  based on the
deployment and implementation experience as well as the new
use cases. 
Moreover, there is also a need to have standards track documents for
the
market.

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  Agree to a list of use cases for evolving the DTN specifications and
    a list of work items to be worked on.

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

o  Document a registry for DTN Service Identifiers. 

On Fri, 2019-10-04 at 15:25 -0400, Marc Blanchet wrote:
> _______________________________________________
> dtn mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dtn
-- 
Cheers

Magnus Westerlund 

----------------------------------------------------------------------
Network Architecture & Protocols, Ericsson Research
----------------------------------------------------------------------
Ericsson AB                 | Phone  +46 10 7148287
Torshamnsgatan 23           | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden | mailto: [email-masked]
----------------------------------------------------------------------