Subject: Re: [dtn] Pete Resnick's Abstain on charter-ietf-dtn-00-03: (with COMMENT)

From: Stephen Farrell <[email-masked]>
Date: Sun, 12 Oct 2014 22:07:59 +0100

On 12/10/14 17:29, Jari Arkko wrote:
> Pete, all,
> 
>> 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.
> 
> +1 to that
> 
> Can we “just do it”? :-)
> 
> Or perhaps the working group needs to be have a list of intended 
> changes and updates before it produces the actual protocol RFC
> from the original IRTF RFCs. But I’m not sure we need a problem
> statement, and in particular do not need a hard rule about not
> being able to produce the protocol work before completing the
> problem statement.
> 
> But I could be misunderstanding what the goal of the problem 
> statement work is.

AFAIK the intent is to agree which items from the potentially
long list of (IMO mainly minor) changes to RFC5050 etc to consider
in scope and which of the potentially major changes are really
needed or not. (An example of the latter is key management.) There
are various opinions as to how much is needed in the first round
of work. So less a problem statement than agreeing the details
of the scope, which details would be too voluminous to capture in
a charter. I think its fair enough to charter the WG before all
of that is tied down myself.

S.

> Jari

---

From: "Pete Resnick" <[email-masked]>
Date: Sun, 12 Oct 2014 09:18:50 -0700

Pete Resnick has entered the following ballot position for
charter-ietf-dtn-00-03: Abstain

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

The document, along with other ballot positions, can be found here:
http://datatracker.ietf.org/doc/charter-ietf-dtn/

----------------------------------------------------------------------
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.

---

From: Jari Arkko <[email-masked]>
Date: Sun, 12 Oct 2014 09:29:52 -0700

Pete, all,

+1 to that

Can we “just do it”? :-)

Or perhaps the working group needs to be have a list of intended changes and updates before it produces the actual protocol RFC from the original IRTF RFCs. But I’m not sure we need a problem statement, and in particular do not need a hard rule about not being able to produce the protocol work before completing the problem statement.

But I could be misunderstanding what the goal of the problem statement work is.

Jari

---

From: Jari Arkko <[email-masked]>
Date: Sun, 12 Oct 2014 16:20:07 -0700

> of work.

That sounds reasonable. Maybe say this in the charter?

Jari

---

From: Martin Stiemerling <[email-masked]>
Date: Mon, 13 Oct 2014 23:23:23 +0200

> That sounds reasonable. Maybe say this in the charter?

Just for the record about the long list (starting from slide 7):
http://www.ietf.org/proceedings/90/slides/slides-90-dtnwg-5.pdf

I am twisting my head for text for this, but right now it is too late.

   Martin

---

From: "Burleigh, Scott C (312G)" <[email-masked]>
Date: Mon, 13 Oct 2014 21:45:38 +0000

Harping on this somewhat: as mentioned on slide 16, for nearly all of the items in this long list we have got at least draft text and, in many cases, running prototype code.  I feel the length of the list is less an indicator of how much work there is to do than an indicator of the degree of detail in which we understand the issues.

Scott

-----Original Message-----
From: dtn [mailto:[email-masked]] On Behalf Of Martin Stiemerling
Sent: Monday, October 13, 2014 2:23 PM
To: Jari Arkko; Stephen Farrell
Cc: [email-masked]; Pete Resnick; [email-masked]; [email-masked]; The IESG
Subject: Re: [dtn] Pete Resnick's Abstain on charter-ietf-dtn-00-03: (with COMMENT)

Am 13.10.14 um 01:20 schrieb Jari Arkko:
>
>> AFAIK the intent is to agree which items from the potentially long 
>> list of (IMO mainly minor) changes to RFC5050 etc to consider in 
>> scope and which of the potentially major changes are really needed or 
>> not. (An example of the latter is key management.) There are various 
>> opinions as to how much is needed in the first round of work.
>

   Martin

_______________________________________________
dtn mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dtn

---

From: Jari Arkko <[email-masked]>
Date: Mon, 13 Oct 2014 15:45:18 -0700

> I am twisting my head for text for this, but right now it is too late.

Well, just for clarification - I think it would be useful to say what Stephen said above in the charter. That is, “The working group agrees a list of changes that the new RFCs should have from the original DTN RG RFCs.”

*Not* that the list of changes itself should be in the charter.

Jari

---

From: Marc Blanchet <[email-masked]>
Date: Mon, 13 Oct 2014 15:53:46 -0700

> Well, just for clarification - I think it would be useful to say what Stephen said above in the charter. That is, “The working group agrees a list of changes that the new RFCs should have from the…

being the guilty guy who has proposed this "two phase commit" process (sorry), I think this discussion is in agreement with the discussions we had about it. So this text above or something similar is fine, at least from my point of view.

Regards, Marc.

---

From: "Templin, Fred L" <[email-masked]>
Date: Mon, 13 Oct 2014 22:59:26 +0000

> From: dtn [mailto:[email-masked]] On Behalf Of Marc Blanchet
> Sent: Monday, October 13, 2014 3:54 PM
> To: Jari Arrko
> Cc: Pete Resnick; Martin Stiemerling; Templin, Fred L; The IESG; Scott Burleigh; [email-masked]; Stephen Farrell
> > Well, just for clarification - I think it would be useful to say what Stephen said above in the charter. That is, "The working group
> agrees a list of changes that the new RFCs should have from the original DTN RG RFCs."
> 
> being the guilty guy who has proposed this "two phase commit" process (sorry), I think this discussion is in agreement with the
> discussions we had about it. So this text above or something similar is fine, at least from my point of view.

I concur.

Thanks - Fred
[email-masked]

---

From: "Ivancic, William D. (GRC-LCA0)" <[email-masked]>
Date: Tue, 14 Oct 2014 12:49:00 +0000

My understanding is that the Problems Statement is not to define the
problem that delay/disconnection/disruption tolerant networking is to
address but rather to identify the deployment problems and lessons learned
(e.g. Time-sync, CRC checks, no way to remove routing loops, what is
default expectations placed on forwarding agents, what does bundle
lifetime mean and how should it be used, security being way to
complicated, etcetera).

Will

******************************
William D. Ivancic
Phone 216-433-3494
Mobile 440-503-4892
http://roland.grc.nasa.gov/~ivancic

---

From: Marc Blanchet <[email-masked]>
Date: Tue, 14 Oct 2014 08:10:49 -0700

Le 2014-10-14 à 05:49, Ivancic, William D. (GRC-LCA0) <[email-masked]> a écrit :

> problem that delay/disconnection/disruption tolerant networking

right. we do not intend to rehash the general problem.

> is to

yes, together some use cases/scenarios that will help shape which feature are needed/to be changed/...

Marc.

---

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 14 Oct 2014 15:24:12 +0000

> From: Marc Blanchet [mailto:[email-masked]]
> Sent: Tuesday, October 14, 2014 8:11 AM
> To: William Ivancic
> Cc: Pete Resnick; The IESG; Templin, Fred L; [email-masked]

I can volunteer to head this up as long as it will not unduly hold up work from
going forward, i.e., this should not be seen as a vector for delaying actual work.

Thanks - Fred

---

From: Pete Resnick <[email-masked]>
Date: Tue, 14 Oct 2014 12:21:55 -0500

This all seems fine, but gathering a set of deployment experience 
together in order to decide which things will be changed in the protocol 
document does not seem to me to be a separate Problem Statement document 
to be published. Sure, you could track discussion of those things in a 
draft, or you could use a wiki or an issue tracker, but either way that 
sounds to me like an internal work product, not a publishable document.

So, in terms of charter text, I 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

On 10/14/14 10:24 AM, Templin, Fred L wrote:
>> Le 2014-10-14 à 05:49, Ivancic, William D. (GRC-LCA0)<[email-masked]>  a écrit :
>>
>>      
>>> On 10/12/14 12:18 PM, "Pete Resnick"<[email-masked]>  wrote:
>>>
>>>        

-- 
Pete Resnick<http://www.qualcomm.com/~presnick/>
Qualcomm Technologies, Inc. - +1 (858)651-4478

---

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 14 Oct 2014 17:40:34 +0000

> From: Pete Resnick [mailto:[email-masked]]
> Sent: Tuesday, October 14, 2014 10:22 AM
> To: Templin, Fred L
> Cc: Marc Blanchet; William Ivancic; The IESG; [email-masked]

Works for me; I see no point in publishing a document that isn't needed.

Thanks - Fred

---

From: Marc Blanchet <[email-masked]>
Date: Tue, 14 Oct 2014 12:08:28 -0700

Le 2014-10-14 à 10:21, Pete Resnick <[email-masked]> a écrit :

> This all seems fine, but gathering a set of deployment experience together in order to decide which things will be changed in the protocol document does not seem to me to be a separate Problem Statement document to be published. Sure, you could track discussion of those things in a draft, or you could use a wiki or an issue tracker, but either way that sounds to me like an internal work product, not a publishable document.

I half agree and half disagree.  I think the document is not only about deployment experience, but also about which problems we are trying to solve, which use cases are being considered (unmanned air vehicles on earth and space communications are different, to say the least). So I see value of this document being published.  I see less value for the "tracking" part of the working group work to be published.

> So, in terms of charter text, I suggest:

I agree with your changes, with my own addition below. 

Marc.

>   not endeavour to change the underlying architecture or the bundle

 - "Use Cases and Requirements to Revise DTN Specifications" Informational Document.

---

From: Pete Resnick <[email-masked]>
Date: Tue, 14 Oct 2014 14:25:59 -0500

On 10/14/14 2:08 PM, Marc Blanchet wrote:
> I half agree and half disagree.  I think the document is not only 
> about deployment experience, but also about which problems we are 
> trying to solve, which use cases are being considered (unmanned air 
> vehicles on earth and space communications are different, to say the 
> least). So I see value of this document being published.  I see less 
> value for the "tracking" part of the working group work to be published.
>
> [...]

So unless this is explained quite a bit more, this is a sure way to get 
me to Block for the Approval ballot.

Are you saying that you've got a bunch of protocol documents right now 
for which you don't know the applicable use cases? And that updates to 
those protocols are likely be affected by the particular applicability 
the WG chooses to address? This is starting to seem like a much broader 
scope of work than I understood from the BoF or the discussion so far, 
and seems rather questionable to me. Re-thinking the entire project does 
not seem like the right approach at this point. If any particular spec 
needs an applicability statement, that can be put in the intro or an 
early section, just the way that the LTP documents do. But having a work 
item for the WG to come up with a new applicability statement for all of 
the work seems like a really bad idea.

pr

---

From: Marc Blanchet <[email-masked]>
Date: Tue, 14 Oct 2014 12:36:57 -0700

Le 2014-10-14 à 12:25, Pete Resnick <[email-masked]> a écrit :

> So unless this is explained quite a bit more, this is a sure way to get me to Block for the Approval ballot.
> 
> Are you saying that you've got a bunch of protocol documents right now for which you don't know the applicable use cases?

no. I did not say that. I said that there is value in documenting them.

> And that updates to those protocols are likely be affected by the particular applicability the WG chooses to address? This is starting to seem like a much broader scope of work than I understood from the BoF or the discussion so far, and seems rather questionable to me. Re-thinking the entire project does not seem like the right approach at this point. If any particular spec needs an applicability statement, that can be put in the intro or an early section, just the way that the LTP documents do. But having a work item for the WG to come up with a new applicability statement for all of the work seems like a really bad idea.

sorry, I guess I was not clear.  Timing is for example a topic that needs to be revisited. However, timing shall be solved differently if the use case is on earth or in space. Therefore, having documented use cases would provide appropriate background for the changes to be made to the specifications. We can also put them in the intro of the documents. I thought it would be better to be documented in a separate document, but I'm far from sticky on this. Looks to me as good engineering practice, not more. 

Maybe what we could do is to do what you suggested: have an internal document by some means (wiki, draft, etc...) and when the document is done, we will revisit if there is a good value in publishing it or not.  I'm just expecting that there will be some value about it.

Marc.

> 
> pr
> -- 
> Pete Resnick <http://www.qualcomm.com/~presnick/>

---

From: Wesley Eddy <[email-masked]>
Date: Tue, 14 Oct 2014 21:16:51 -0400

> the work seems like a really bad idea.

Actually, I think it's the opposite of that.

There are a bunch of use cases being mentioned that would seemingly
require major work which has not been proposed.  There is no key
management document, no default routing mechanism, no default
forwarding logic, addressing scheme, configuration means, etc.

IMO, those are the useful pieces that need to be worked, and the
naked Bundle Protocol is not actually all that important in
comparison, because it's just an envelope and not actually an
interoperability spec (since interop requires addressing, etc.).

I had guessed that the point of the problem statement would be
to identify these things so that the necessary core could at
least be included in standards work.

-- 
Wes Eddy
MTI Systems

---

From: "Burleigh, Scott C (312B)" <[email-masked]>
Date: Wed, 15 Oct 2014 18:04:59 +0000

Wes, that's a valid point of view, but I disagree.

While the work items you call out are surely needed for broad adoption and large-scale deployment of DTN, I think we don't have to be quite so ambitious in the initial work plan for this WG.  There would be benefit to industry from just standardizing the core bundle protocol and the bundle security protocol; that's all that is needed for simple, private, stand-alone DTN-based networks that could address some specific use cases.  For example, DTN will be fully operational on the International Space Station by mid-2015, without benefit of automated key management, standardized routing, or standardized network management.

We absolutely do want to take on those additional work items at some point, but since there's no serious doubt that they are doable (SNMP-compatible network management is currently being prototyped; there's an RFC for ProPHeT, and contact graph routing has been working well since 2008; JPL has developed a delay-tolerant public key infrastructure that Boeing and NASA are testing now; etc.) I don't think anything is lost by deferring them.  Let's make some progress, and then think about making some more.

Scott

-----Original Message-----
From: dtn [mailto:[email-masked]] On Behalf Of Wesley Eddy
Sent: Tuesday, October 14, 2014 6:17 PM
To: Pete Resnick; Marc Blanchet
Cc: Templin, Fred L; The IESG; [email-masked]; William Ivancic
Subject: Re: [dtn] Pete Resnick's Abstain on charter-ietf-dtn-00-03: (with COMMENT)

On 10/14/2014 3:25 PM, Pete Resnick wrote:
> the WG chooses to address? This is starting to seem like a much 
> broader scope of work than I understood from the BoF or the discussion 
> so far, and seems rather questionable to me. Re-thinking the entire 
> project does not seem like the right approach at this point. If any 
> particular spec needs an applicability statement, that can be put in 
> the intro or an early section, just the way that the LTP documents do. 
> But having a work item for the WG to come up with a new applicability 
> statement for all of the work seems like a really bad idea.

There are a bunch of use cases being mentioned that would seemingly require major work which has not been proposed.  There is no key management document, no default routing mechanism, no default forwarding logic, addressing scheme, configuration means, etc.

IMO, those are the useful pieces that need to be worked, and the naked Bundle Protocol is not actually all that important in comparison, because it's just an envelope and not actually an interoperability spec (since interop requires addressing, etc.).

I had guessed that the point of the problem statement would be to identify these things so that the necessary core could at least be included in standards work.

--
Wes Eddy
MTI Systems

---

From: "Will Ivancic" <[email-masked]>
Date: Wed, 15 Oct 2014 15:04:11 -0400

ISS is a pretty small and simple deployment from what I've seen in my
research efforts.  The literature implies the main use if to automate the
outage recording and standardize on the way payloads handle file/data
transfer.  
http://ipnsig.org/wp-content/uploads/2014/02/ISS-DTN-Presentation-IPNSIG.pdf

Interesting that if this is fully operational by mid-2015, then there
appears to be little concern for a standard prior to full adoption by NASA. 

CCSDS appears to have adopted RFC5050 as is with a bunch of other extras
albeit this has still not made it through the CCSDS standards process.  So,
will the space community move to a new standard or do those extras have to
be incorporated into the IETF standard if one is developed?
 
http://cwe.ccsds.org/sis/docs/SIS-DTN/Draft%20Documents/DTN%20Protocol/Red-3
%20Review/734x2r3_pre-editor.docx

Also, would the DELAY-TOLERANT PAYLOAD CONDITIONING SPECIFICATION be
necessary for the IETF to develop/adopt.  I believe this is used for either
aggregation or to ensure in-order delivery to an application if one were to
break a large data set up into smaller chunks.  I suspect this is necessary
because RFC5050 appears to treat a large data set as a single bundle rather
that treating bundles as delay-tolerant packets.

http://cwe.ccsds.org/sis/docs/SIS-DTN/Draft%20Documents/DTN%20Protocol/CCSDS
%20DTPC.docx

Will

-----Original Message-----
From: dtn [mailto:[email-masked]] On Behalf Of Burleigh, Scott C
(312B)
Sent: Wednesday, October 15, 2014 2:05 PM
To: Wesley Eddy; Pete Resnick; Marc Blanchet
Cc: Templin, Fred L; The IESG; [email-masked]; William Ivancic
Subject: Re: [dtn] Pete Resnick's Abstain on charter-ietf-dtn-00-03: (with
COMMENT)

While the work items you call out are surely needed for broad adoption and
large-scale deployment of DTN, I think we don't have to be quite so
ambitious in the initial work plan for this WG.  There would be benefit to
industry from just standardizing the core bundle protocol and the bundle
security protocol; that's all that is needed for simple, private,
stand-alone DTN-based networks that could address some specific use cases.
For example, DTN will be fully operational on the International Space
Station by mid-2015, without benefit of automated key management,
standardized routing, or standardized network management.

We absolutely do want to take on those additional work items at some point,
but since there's no serious doubt that they are doable (SNMP-compatible
network management is currently being prototyped; there's an RFC for
ProPHeT, and contact graph routing has been working well since 2008; JPL has
developed a delay-tolerant public key infrastructure that Boeing and NASA
are testing now; etc.) I don't think anything is lost by deferring them.
Let's make some progress, and then think about making some more.

Scott

-----Original Message-----
From: dtn [mailto:[email-masked]] On Behalf Of Wesley Eddy
Sent: Tuesday, October 14, 2014 6:17 PM
To: Pete Resnick; Marc Blanchet
Cc: Templin, Fred L; The IESG; [email-masked]; William Ivancic
Subject: Re: [dtn] Pete Resnick's Abstain on charter-ietf-dtn-00-03: (with
COMMENT)

There are a bunch of use cases being mentioned that would seemingly require
major work which has not been proposed.  There is no key management
document, no default routing mechanism, no default forwarding logic,
addressing scheme, configuration means, etc.

IMO, those are the useful pieces that need to be worked, and the naked
Bundle Protocol is not actually all that important in comparison, because
it's just an envelope and not actually an interoperability spec (since
interop requires addressing, etc.).

I had guessed that the point of the problem statement would be to identify
these things so that the necessary core could at least be included in
standards work.

--
Wes Eddy
MTI Systems

---

From: "Burleigh, Scott C (312B)" <[email-masked]>
Date: Wed, 15 Oct 2014 19:44:55 +0000

Will, as you know, ISS is not all of NASA.  Nor is interest in standardizing DTN within IETF limited to NASA, as we've discussed at length.

The CCSDS standardization cycle does take some time, much as the RFC cycle takes some time.  The "extras" in the BP Blue Book for CCSDS, such as DTPC, might be candidates for standardization in IETF, but IETF standardization stands on its own.  Certainly space-specific standards may be adopted by the space flight community without imposing any sort of mandate on the Internet; that has been happening for decades.

I'm having trouble understanding the words "RFC5050 appears to treat a large data set as a single bundle rather that treating bundles as delay-tolerant packets" given the heavy attention paid to bundle fragmentation and reassembly in the BP spec.  (Which is not to say that the BP fragmentation and reassembly procedures are flawless - we do need to clarify some of the interaction with the security protocol.)

Scott

-----Original Message-----
From: Will Ivancic [mailto:[email-masked]] 
Sent: Wednesday, October 15, 2014 12:04 PM
To: Burleigh, Scott C (312B); 'Wesley Eddy'; 'Pete Resnick'; 'Marc Blanchet'
Cc: 'Templin, Fred L'; 'The IESG'; [email-masked]
Subject: RE: [dtn] Pete Resnick's Abstain on charter-ietf-dtn-00-03: (with COMMENT)

ISS is a pretty small and simple deployment from what I've seen in my research efforts.  The literature implies the main use if to automate the outage recording and standardize on the way payloads handle file/data transfer.  
http://ipnsig.org/wp-content/uploads/2014/02/ISS-DTN-Presentation-IPNSIG.pdf

Interesting that if this is fully operational by mid-2015, then there appears to be little concern for a standard prior to full adoption by NASA. 

CCSDS appears to have adopted RFC5050 as is with a bunch of other extras albeit this has still not made it through the CCSDS standards process.  So, will the space community move to a new standard or do those extras have to be incorporated into the IETF standard if one is developed?

Also, would the DELAY-TOLERANT PAYLOAD CONDITIONING SPECIFICATION be necessary for the IETF to develop/adopt.  I believe this is used for either aggregation or to ensure in-order delivery to an application if one were to break a large data set up into smaller chunks.  I suspect this is necessary because RFC5050 appears to treat a large data set as a single bundle rather that treating bundles as delay-tolerant packets.

Will

-----Original Message-----

While the work items you call out are surely needed for broad adoption and large-scale deployment of DTN, I think we don't have to be quite so ambitious in the initial work plan for this WG.  There would be benefit to industry from just standardizing the core bundle protocol and the bundle security protocol; that's all that is needed for simple, private, stand-alone DTN-based networks that could address some specific use cases.
For example, DTN will be fully operational on the International Space Station by mid-2015, without benefit of automated key management, standardized routing, or standardized network management.

We absolutely do want to take on those additional work items at some point, but since there's no serious doubt that they are doable (SNMP-compatible network management is currently being prototyped; there's an RFC for ProPHeT, and contact graph routing has been working well since 2008; JPL has developed a delay-tolerant public key infrastructure that Boeing and NASA are testing now; etc.) I don't think anything is lost by deferring them.
Let's make some progress, and then think about making some more.

Scott

-----Original Message-----
From: dtn [mailto:[email-masked]] On Behalf Of Wesley Eddy
Sent: Tuesday, October 14, 2014 6:17 PM
To: Pete Resnick; Marc Blanchet
Cc: Templin, Fred L; The IESG; [email-masked]; William Ivancic
Subject: Re: [dtn] Pete Resnick's Abstain on charter-ietf-dtn-00-03: (with
COMMENT)

--
Wes Eddy
MTI Systems

---

From: "Templin, Fred L" <[email-masked]>
Date: Wed, 15 Oct 2014 19:51:32 +0000

Hi,

> From: Burleigh, Scott C (312B) [mailto:[email-masked]]
> Sent: Wednesday, October 15, 2014 11:05 AM
> While the work items you call out are surely needed for broad adoption and large-scale deployment of DTN, I think we don't have to
> be quite so ambitious in the initial work plan for this WG.  There would be benefit to industry from just standardizing the core bundle
> protocol and the bundle security protocol; that's all that is needed for simple, private, stand-alone DTN-based networks that could
> address some specific use cases. 

I can confirm that our near- to mid-term (1-5 yr) plans call for core DTN protocols that
are either standardized or on standards track, and in domains other than just space
systems.

> For example, DTN will be fully operational on the International Space Station by mid-2015, without
> benefit of automated key management, standardized routing, or standardized network management.
> 
> We absolutely do want to take on those additional work items at some point, but since there's no serious doubt that they are doable
> (SNMP-compatible network management is currently being prototyped; there's an RFC for ProPHeT, and contact graph routing has
> been working well since 2008; JPL has developed a delay-tolerant public key infrastructure that Boeing and NASA are testing now;
> etc.)

I can confirm that we have successfully tested the JPL key management code
and are using it for our ongoing R&D activities.

> I don't think anything is lost by deferring them.  Let's make some progress, and then think about making some more.

+1

Thanks - Fred

> There are a bunch of use cases being mentioned that would seemingly require major work which has not been proposed.  There is no
> key management document, no default routing mechanism, no default forwarding logic, addressing scheme, configuration means,
> etc.
> 
> IMO, those are the useful pieces that need to be worked, and the naked Bundle Protocol is not actually all that important in
> comparison, because it's just an envelope and not actually an interoperability spec (since interop requires addressing, etc.).
>