Subject: [dtn] FW: I-D Action: draft-burleigh-bpv7-00.txt

From: "Templin, Fred L" <[email-masked]>
Date: Fri, 6 Jun 2014 18:38:52 +0000

FYI, see below for a first draft of RFC5050bis (Appendix A has a
summary of differences from RFC5050). Comments to [email-masked].

-----Original Message-----
From: I-D-Announce [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Friday, June 06, 2014 10:38 AM
To: [email-masked]
Subject: I-D Action: draft-burleigh-bpv7-00.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories.

        Title           : Proposed Revised Bundle Protocol
        Author          : Scott Burleigh
	Filename        : draft-burleigh-bpv7-00.txt
	Pages           : 64
	Date            : 2014-06-06

Abstract:
   This Internet Draft presents a proposed modification to the Bundle
   Protocol Specification, including notes on the rationale underlying
   some of the proposed changes.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-burleigh-bpv7/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-burleigh-bpv7-00

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

_______________________________________________
I-D-Announce mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

---

From: "Birrane, Edward J." <[email-masked]>
Date: Tue, 10 Jun 2014 00:13:14 -0400

I've been thinking through the concept of whether security (e.g., security blocks) should be formally defined in BPv7 or whether their definition should be deferred to a separate document.

Having worked through several use cases for both space and terrestrial networking, I think that BPv7 should not mandate a particular security block structure. In most cases, we've been using the design mantra "make the common case fast", which will work for (by definition) a majority of deployments. However, I am sure there are boundary cases and pathological topologies for which a particular closed network or other special deployment would want something different. For those networks, it is far easier to stay compliant with BP and then non-compliant with BSP/SBSP than to require divergence from the core standard. 

Further, my intuition is that the security posture is best captured in a series of (at least) three documents: the initial common-case security blocks (SBSP), a security recipe for common security services (drafting in progress), and configurations/policy best practices. To the extent that a "recipe book" for security would show more than one way to achieve a desired security service, baselining a single methodology in 5050 or BP7 spec would be unduly constraining.

Long story short, I think the path proposed in BPv7 (pointing outside of the document) for security services seems like a sensical thing to be doing.

-Ed
________________________________________
From: dtn [[email-masked]] On Behalf Of Templin, Fred L [[email-masked]]
Sent: Friday, June 06, 2014 2:38 PM
To: [email-masked]
Subject: [dtn] FW: I-D Action: draft-burleigh-bpv7-00.txt

-----Original Message-----
From: I-D-Announce [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Friday, June 06, 2014 10:38 AM
To: [email-masked]
Subject: I-D Action: draft-burleigh-bpv7-00.txt

Abstract:

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

---

From: "Birrane, Edward J." <[email-masked]>
Date: Tue, 10 Jun 2014 00:39:52 -0400

A question about Node identifiers versus endpoint identifiers.... 

I have been reading through BPv7 to see what, if anything, needs to change in the update to DTNMP that I'm currently working on. It seems to me that node identifiers should be the preferred identifier when discussing network management services in a DTN. It seems reasonable that management services operate on singletons and avoid the potential pitfalls of shared or re-assigned EIDs in a network. So, when making an SNMP/DTNMP/other query against a node, going forward, Node IDs are the way to go.

Other than reporting status/performance of EIDs configured at a particular Node ID, are there any use cases where EIDs should be the first-class targets of performance monitoring, configuration, or control? 

This may become a NM scoping issue... if EIDs evolve to be the moral equivalents of service numbers, then extending NM into EIDs would be similar to extending network management services into application management services.

Thoughts?

-Ed

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 10 Jun 2014 07:46:13 +0100

Hi Ed,

Two thoughts on that:

On 10/06/14 05:13, Birrane, Edward J. wrote:
> Long story short, I think the path proposed in BPv7 (pointing outside
> of the document) for security services seems like a sensical thing to
> be doing.

I don't really care how the spec might be broken up into documents
but I do think that doing whatever security work is to be done at
the same time is the right thing - we suffered from that last time
with the BSP.

I think what ought be mandatory to implement etc. is a level of
detail for later, but would like the putative WG to consider
having some security services on by default. But that's also
a discussion probably better had later, if a WG is chartered.

S.