Subject: [dtn] Draft Charter Discussion

From: "Klish, Cypryan" <[email-masked]>
Date: Tue, 17 Jun 2014 21:56:06 +0000

As a long time lurker and foremost an implementer and developer of products suggest a DTN WG charter should address the need to refine and further standardize the fine research done by the DTNRG so that it can be implemented by practitioners/organizations with a reasonable expectation that it will be interoperable, secure, and perform within a range of boundaries and constraints defined in the standards.

What does this entail? Suggest some of the following would be relevant :
*       Generate/refine a reference architecture that is more up to date, comprehensive and complete than RFC4838; a model-based RA would be icing on the cake
*       Better identify known constraints and limitations
*       Better define management aspects (e.g. MIBs or YANG models)
*       Provide multiple security model options  - perhaps like SNMP's USM and VACM
*       Consider layering aspects, particularly layer boundaries, enabling independent/portable use of some features (e.g. bundling as a service?)
*       Consider defining profiles/modes/classes of operation/RA subsets traceable to the use cases

Hope this helps

Kip

Cypryan (Kip) T. Klish II
Senior Scientist
Government Communications Systems
HARRIS
AssuredCommunications*
Post Office Box 37
Melbourne, FL 32902-0037
* 1 321 727 6348
* 1 321 298 0492 (mobile) *Note new mobile number*
* [email-masked]
Confidentiality Notice: This Email and any attachments may contain material that is "HARRIS Proprietary Information," Confidential, Privileged, and/or Attorney Work Product for the Sole Use of the Intended Recipient. Any Review, Reliance, Distribution, Disclosure, or Forwarding Without Expressed Permission is Strictly Prohibited. If you are not the Intended Recipient, Please Contact the Sender and Delete All Copies Without Reading, Printing, or Saving in any Manner. -- Thank You.

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 17 Jun 2014 23:04:42 +0100

Hi Cypryan,

Good stuff. Can you say some more about what you'd be using such
an set of BP specs for?

I think you're the first to suggest re-opening RFC4838 btw. Not sure
I see much benefit in that to be honest. And some risk that the valid
argument that 4838 is a bit too BP specific might win the day and,
from a charter/milestones POV, de-rail the WG.

Ta,
S.

On 17/06/14 22:56, Klish, Cypryan wrote:
> _______________________________________________
> dtn mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dtn
>

---

From: "Klish, Cypryan" <[email-masked]>
Date: Wed, 18 Jun 2014 13:02:36 +0000

Thanks Stephen!

With respect to how the specifications would be used, in general, the organization I work for has capabilities that span most of the use cases that have been discussed.  Mobile tactical edge networks, UAV/airborne sensor networks, space networks, and other mission critical systems that operate over bandwidth-limited and lossy networks are all relevant for us. 

In my case specifically, I'm interested in assured delivery of user data over heterogeneous networks that traverse a variety of physical network types.  I'd like to bound data loss and data delivery delay so that customers can be offered an SLA-like agreement that quantifies these and other aspects of assured delivery.  This, I suggest, would involve not only up front characterization of DTN behaviors but also a robust performance monitoring capability that could be used to validate fulfillment of the SLA-like agreement, hence my suggestion that the charter include definition of management capabilities within the WG's activity scope. 

As a future objective, mapping DTN mechanisms (speaking in broad terms here) directly to Carrier Ethernet over OTN, optical burst switching or optical wavelength switching technologies is also relevant for me.  This gives rise to my interest in layering and making DTN mechanisms portable to different technologies.  The benefit of doing would be freeing up bandwidth that is consumed by protocols at intervening layers - an important consideration in the bandwidth/throughput limited networks I typically work with.

With respect to RFC 4838,I mentioned it only because it is the one existing RFC that attempts to address DTN architecture from a system-wide scope.  I perceive the lack of similar but up to date, current document that is more formal in the sense of being a RA as a critical gap for this effort - accordingly, suggest the need to generate and maintain a DTN RA would be worth of inclusion in the charter.  I agree that re-opening RFC 4838 itself would not be beneficial - a new RA document that cites RFC 4838 as a historical reference might be the better way to go.

Lastly, any charter that doesn't target interoperability as a WG objective would be deficient in my view.

'Hope this helps, welcome everyone's feedback.

Kip (Cypryan) Klish
Sr. Scientist
Harris Corporation, Government Communications Systems

-----Original Message-----
From: Stephen Farrell [mailto:[email-masked]] 
Sent: Tuesday, June 17, 2014 6:05 PM
To: Klish, Cypryan; [email-masked]
Subject: Re: [dtn] Draft Charter Discussion

Hi Cypryan,

Ta,
S.

---

From: <[email-masked]>
Date: Thu, 19 Jun 2014 03:14:20 +0000

Kip

what is "RA"?

thanks
________________________________________
From: dtn <[email-masked]> on behalf of Klish, Cypryan <[email-masked]>
Sent: Wednesday, 18 June 2014 11:02:36 PM
To: [email-masked]
Subject: Re: [dtn] Draft Charter Discussion

Thanks Stephen!

Kip (Cypryan) Klish
Sr. Scientist

-----Original Message-----
From: Stephen Farrell [mailto:[email-masked]]
Sent: Tuesday, June 17, 2014 6:05 PM
To: Klish, Cypryan; [email-masked]
Subject: Re: [dtn] Draft Charter Discussion

Hi Cypryan,

Ta,
S.

---

From: "Klish, Cypryan" <[email-masked]>
Date: Thu, 19 Jun 2014 03:38:05 +0000

RA = Reference Architecture

Sent from my iPhone

> On Jun 18, 2014, at 11:14 PM, "[email-masked]" <[email-masked]> wrote:
> 
> Kip
> 
> what is "RA"?
> 
> thanks

---

From: "Templin, Fred L" <[email-masked]>
Date: Thu, 19 Jun 2014 19:49:17 +0000

Hi Kip,

> From: dtn [mailto:[email-masked]] On Behalf Of Klish, Cypryan
> Sent: Wednesday, June 18, 2014 6:03 AM
> To: [email-masked]
> With respect to how the specifications would be used, in general, the organization I work for has
> capabilities that span most of the use cases that have been discussed.  Mobile tactical edge networks,
> UAV/airborne sensor networks, space networks, and other mission critical systems that operate over
> bandwidth-limited and lossy networks are all relevant for us.

I think it safe to say that my company's business interests also
overlap with some of the use cases that have been discussed in
this thread. 

> In my case specifically, I'm interested in assured delivery of user data over heterogeneous networks
> that traverse a variety of physical network types.  I'd like to bound data loss and data delivery
> delay so that customers can be offered an SLA-like agreement that quantifies these and other aspects
> of assured delivery.  This, I suggest, would involve not only up front characterization of DTN
> behaviors but also a robust performance monitoring capability that could be used to validate
> fulfillment of the SLA-like agreement, hence my suggestion that the charter include definition of
> management capabilities within the WG's activity scope.
> 
> As a future objective, mapping DTN mechanisms (speaking in broad terms here) directly to Carrier
> Ethernet over OTN, optical burst switching or optical wavelength switching technologies is also
> relevant for me.  This gives rise to my interest in layering and making DTN mechanisms portable to
> different technologies.  The benefit of doing would be freeing up bandwidth that is consumed by
> protocols at intervening layers - an important consideration in the bandwidth/throughput limited
> networks I typically work with.
> 
> With respect to RFC 4838,I mentioned it only because it is the one existing RFC that attempts to
> address DTN architecture from a system-wide scope.  I perceive the lack of similar but up to date,
> current document that is more formal in the sense of being a RA as a critical gap for this effort -
> accordingly, suggest the need to generate and maintain a DTN RA would be worth of inclusion in the
> charter.  I agree that re-opening RFC 4838 itself would not be beneficial - a new RA document that
> cites RFC 4838 as a historical reference might be the better way to go.

Architecture documents are not functional specifications; they are
typically targeted for Informational or Experimental category. We
already have RFC4838, and the current work items in the draft charter
are focused on functional specifications. So I am not sure anything
new in this space needs to appear in the draft charter.
 
> Lastly, any charter that doesn't target interoperability as a WG objective would be deficient in my

It is understood by the community that IETF standards-track documents
are produced for the purpose of guiding the development of independent
interoperable implementations. Interoperable implementations are
sometimes made available even before the document is published, but
this is not required.

In the case of the work produced by DTNRG, we already have multiple
interoperable implementation that observe the specifications. Hence,
there is no reason to doubt that interoperable implementations will
naturally track along with the works produced by this prospective
working group.

Thanks - Fred
[email-masked]  
 
> > As a long time lurker and foremost an implementer and developer of products suggest a DTN WG charter
> should address the need to refine and further standardize the fine research done by the DTNRG so that
> it can be implemented by practitioners/organizations with a reasonable expectation that it will be
> interoperable, secure, and perform within a range of boundaries and constraints defined in the
> standards.
> >
> > *       Generate/refine a reference architecture that is more up to date, comprehensive and complete
> than RFC4838; a model-based RA would be icing on the cake
> > *       Consider layering aspects, particularly layer boundaries, enabling independent/portable use
> of some features (e.g. bundling as a service?)
> > Confidentiality Notice: This Email and any attachments may contain material that is "HARRIS
> Proprietary Information," Confidential, Privileged, and/or Attorney Work Product for the Sole Use of
> the Intended Recipient. Any Review, Reliance, Distribution, Disclosure, or Forwarding Without
> Expressed Permission is Strictly Prohibited. If you are not the Intended Recipient, Please Contact the
> Sender and Delete All Copies Without Reading, Printing, or Saving in any Manner. -- Thank You.
> >
> >
> >
> >
> >
> >