Subject: [dtn] working group last call on draft-ietf-dtn-bpbis

From: "Marc Blanchet" <[email-masked]>
Date: Fri, 06 Jan 2017 08:34:42 -0500

Hello,
  following last IETF meeting in Seoul, this message is a 4 week working 
group last call on draft-ietf-dtn-bpbis, terminating on friday February 
3rd 2017, 23h59 UTC. This wg last call is simultaneous for 2 documents, 
since the intent is to forward them together to the IESG.
  Please send your comments to the mailing list with the subject as this 
message.

Regards, Marc&Rick, dtn wg co-chairs

---

From: "Marc Blanchet" <[email-masked]>
Date: Fri, 06 Jan 2017 13:31:55 -0500

hello again,
  FYI, Fred Tremplin has agreed to be the shepherd for this document.

Regards, Marc.

On 6 Jan 2017, at 8:34, Marc Blanchet wrote:

> Hello,
>  following last IETF meeting in Seoul, this message is a 4 week 
> working group last call on draft-ietf-dtn-bpbis, terminating on friday 
> February 3rd 2017, 23h59 UTC. This wg last call is simultaneous for 2 
> documents, since the intent is to forward them together to the IESG.
>  Please send your comments to the mailing list with the subject as 
> this message.
>
> _______________________________________________
> dtn mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dtn

---

From: "Templin, Fred L" <[email-masked]>
Date: Fri, 20 Jan 2017 22:27:15 +0000

Hi, here are my review comments for draft-ietf-dtn-bpbis:

Fred Templin
[email-masked]

---

1) Abstract, instead of "This Internet Draft", say: "This document" so that the text can carry
     forward into RFC publication.
2) Page 4, figure 1 is split between two pages. Make it fit onto a single page.
3) Page 4, figure 1, "Trans1" and "Trans3" are unexplained. Are they the same as "T1/T3"?
     Why not just call them "T1" and "T3"?
4) Page 6, "Partial payload" is it the case that payload fragmentation is limited to 2-fragment
     fragmentation, or can it be N-fragment? The definition makes it appear that only 2-fragment
    fragmentation is supported.
5) Page 6, figure 2 is split between two pages. Make it fit onto a single page.
6) Section 3.2, page 14, the sentence: "However, in some environments there may be
    segments of the end-to-end path for which no reliable convergence-layer protocol
    is available; in such environments the use of reliable convergence-layer protocols
    wherever possible can reduce the incidence of data loss." - this seems to be saying
    two contradictory things. It basically seems says: "when no reliable convergence-layer
    protocol is available, use a reliable convergence-layer protocol" which is an
    oxymoron - perhaps a misunderstanding?
7) Section 4.1.5.1, page 18, should there be an informative reference for "dtn:" and "ipn:"?
8) Section 4.2.2, page 22, "Total Application Data Unit Length" only appears if the bundle is
    a fragment. But, does it mean that only "two-fragment" fragmented bundles are possible?
9) Section 4.3.4, page 25, why does it need to include both a hop limit and hop count? Isn't
    it sufficient to just have a hop limit that decrements to 0?
10) Section 5.8, page 32, why is only "2-fragment" fragmentation supported? Why not
    "N-fragment"?
11) Section 6.1.2, figure 6, page 42, change: "No known route destination from here."
    to: "No known route to destination from here."

---

From: "Burleigh, Scott C (312B)" <[email-masked]>
Date: Fri, 20 Jan 2017 22:54:02 +0000

Fred, some responses in-line below.

Scott

-----Original Message-----
From: dtn [mailto:[email-masked]] On Behalf Of Templin, Fred L
Sent: Friday, January 20, 2017 2:27 PM
To: dtn <[email-masked]>
Subject: Re: [dtn] working group last call on draft-ietf-dtn-bpbis

Fred Templin

---

Sure.

Sure.

Yep, fine with me.

Bundles can be split up into an unlimited number of fragments, but the way to do that is to split a single bundle into two fragments, each of which is a full-fledged bundle - and since each fragment is a bundle it can then be split into two fragments, each of which is a bundle, and so on.  The rules for dividing one bundle into two fragments can be described exactly, in a fairly concise way.  The rules for dividing a single bundle directly into N bundles would be much more complicated, harder to grasp, and easier to get wrong, and they are really not necessary.  (The development of multicellular organisms is sort of a model here.)  But certainly I can add a sentence somewhere to the effect that fragments are bundles and are therefore amenable to further fragmentation, such that the net result is fragmentation of a single bundle into N fragments, N>= 2.

Sure.

The writing here is bad.  The idea is that even though some segments of the end-to-end path can't be served by reliable CL protocols, you're still better off overall if you use reliable CL protocols on those segments that can be.  I will fiddle with this text to make it clearer.

All we are doing in this section is saying what to do with various string values.  There happen to be some documents that discuss the schemes identified by those strings, and we could insert some informative references to those documents if they would be helpful to the reader.

No, it doesn't mean that (see above).

A fair point, but having both fields actually does provide additional information - if you only decrement hop limit to zero you have no idea what value it started out with, which might be important for some routers.  That said, I'm fine either way.

As discussed above, a bundle can be divided into any number of fragments.

Yes.

---

From: Brian Sipos <[email-masked]>
Date: Mon, 23 Jan 2017 16:11:27 +0000

Scott,

I have no new comments for the BPbis draft, but just want to re-state some earlier discussion:

- On the checksum field position/contents, I believe that we had settled on relocating the checksum to the end of each block and to use a fixed-size byte-string encoding (to avoid ambiguities).

- I had recommended to include some language in the spec about a BP agent accepting alternate, non-canonical encodings (e.g. indefinite-length vs. definite-length arrays) and then possibly canonicalize the bundle. An agent performing canonicalization would have implications for BPSEC down the road, just to keep in mind.

________________________________
From: dtn <[email-masked]> on behalf of Marc Blanchet <[email-masked]>
Sent: Friday, January 6, 2017 8:34:42 AM
To: dtn
Subject: [dtn] working group last call on draft-ietf-dtn-bpbis

Hello,

_______________________________________________
dtn mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dtn
dtn Info Page - Internet Engineering Task Force<https://www.ietf.org/mailman/listinfo/dtn>
www.ietf.org
"This list is for discussions related to the formation of a Delay Tolerant Networking (DTN) working group. The IRTF DTNRG research group has worked on the particular ...

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 24 Jan 2017 03:33:04 +0000

Hiya,

I've done a review of bpbis-06 and have many comments. (Sorry:-)

Overall I don't think this is ready, and some more discussion
of some of the issues is needed. Since I've not followed the
list as closely as I'd have liked I may have missed some such
discussion in which case pointing me at the relevant bit(s) of
the archive would be a fine response.

I've tried to separate stuff into things that'd cause me to
ballot DISCUSS in IESG evaluation (*), things that might not,
and nitty things. I hope that helps, but don't take that
categorisation too seriously:-)

Cheers,
S.

(*) Note that I'll likely not still be on the IESG when this
gets there (I escape in March) so the fact that I would ballot
DISCUSS is not that relevant to what other ADs might do.

Possibly major issues (DISCUSS like)
------------------------------------

(A) intro: The last bullet list of the things that are not
specified here seems problematic for a PS and I think needs
more discussion/work. I'm not sure if it's only the text that
needs work, or if the missing specification is required now.
Taking the bullets one at at time (numbers are in order of
presentation): 1) This isn't clear enough, I'm not sure what's
being omitted, 2) Omitting routing I think is fair, 3) It's
also fair to omot RIB/FIB issues, 4) it's not ok to omit
security mechanism definition, (making [BPSEC] normative and
waiting on that in the RFC editor queue would fix this, and is
IMO needed), 5) I'm not sure what's right here.  I think it'd
be good to have some list discussion about this, as it'll
certainly come up in IETF LC and IESG review and having list
traffic at which to point will help backup whatever conclusions
are reached.  In particular in 4.3, I don't think it's
acceptable for the BIB and BCB to not have a normative
reference. Similarly, the "TBD" for the other extension block
types are not appropritate. (But those can likely be
informative refs.)

(B) The spec is overly prescriptive in many places and ought be
loosened up wherever possible. All we need is interop and not
the kind of conformance at which this spec seems to aim (but
maybe miss). For exmple the "retention constraint" stuff has
absoluely no reason to be a MUST. As another, I think section
5.4 only needs a MUST in step 4 and all the rest are bogus and
a bad plan.  Also in 3.1, the text here is often far too
prescritpive and I suspect based on only a couple of
implementation strategies.  There are many more examples.  I
think it'd be a good plan to do an editing pass to get rid of
as many of the extraneous and unnecessary constraints that are
here.  Examples feature in other comments, but I've not tried
to be exhaustive in spotting all instances of this.

(C) Many of the flags relaed to reporting provide ways in which
the BP, if it became widely deployed (even if not planned to be
widely used), could be a significant (D)DoS accelerator. Has
anyone figured out the scale factors involved, (e.g. if N bogus
blocks say report if this can't be processed) whether those
might be significant and if so what potential countermeasures
might apply? Absent such an analysis, or fixing the problem,
I'd argue it'd seem irresponsible to standardise the BP.  I'd
say for a PS, the minimum is that BPAs MUST default to not
sending all these new bundles except when specifically
configured to be so verbose.  This also affects 5.1 and maybe
elsewhere which says an agent MUST emit admin bundles if asked.
In 5.6, step 2: again the SHOULD needs to be qualified in order
to not have the BP be a fine DoS accelerator (given
non-singletons). Step 3's SHOULD for this is even worse as a
bad actor could include many such blocks.  In 5.13 - I think
that is too many custody signals. If one envisages DTNs with
custodians located at links that are particularly subject to
disruption, then those may be few in number and having all
other nodes/routers emit custody signals for each bundle not
taken into custody seems hugely inefficient and unnecessary.
There may be more examples.  FWIW, my guess is that if all the
current reporting is kept, then the IESG will require some kind
of applicability statement about the kind of network in which
the BP can safely be deployed. For me, fixing the problem is a
better approach than constraining it via an applicability
statement.

A bit less major (maybe not DISCUSS-worthy)
-------------------------------------------

(1) 3.1's definition of a bundle correctly says that bundles
are better when they include all the meta-data that might be
useful. If considered naively, that conflicts with modern
approaches to privacy where we want to ensure that meta-data is
only seen by those (nodes) that need to see meta-data, as one
form of data minimisation. OTOH, one could argue that such
bundles will ensure that meta-data and payloads enjoy the same
security services, which is a good thing. In any case, I think
it'd be useful to have a discussion about the privacy aspects
of the BP, esp the ways in which those may be different from
other protocols. For example, would we expect report-to URIs to
commonly allow re-identification of a person? I don't recall
we've ever really discussed such issues.

(2) 3.1, destination: I think this ought be clear that delivery
to some node in the endpoint represents success, i.e.  that the
BP does not force successful delivery to all or failure as a
binary choice.

(3) What bad things would follow if 3.2 was deleted?  It may be
that I'm too familiar with DTN (and hence not a good judge if
this section is useful or not) but I didn't find it useful.
Also - is 3.2 normative? If not, I'm even happier to see it go.
If it is, then I gotta wonder if it conflicts with other text
later. And I see there are a few 2119 MUSTs in there so I guess
you do mean it to be normative or did they sneak in in by
accident whilst editing? (As can happen.) If not deleting this
section, I'd argue to find all the bits of text in it that are
needed and move them all elsewhere and then delete the section.

(4) 3.2: The idea that the EID fully determines the MRG seems
just wrong to me. While that might be a nice theory, I figure
it's way more likely that the routing scheme determines how
many copies of a bundle are rx'd at how many instances of the
destination EID. What'd be bad about losing that concept and
letting (the determinants of) the MRG be unspecified here?

(5) 3.2, "Custody of a bundle MAY be taken only if the
destination of the bundle is a singleton endpoint." That's
plain wrong. Not all custodians can know about the desitnation
being a singleton or not. And before you say it, I don't
believe in the flag in 4.1.3 that allows an origin to specify
this - I've never seen a real example of when that's useful -
the only nearby case I recall was where the developer (me:-)
knew we wanted distibution to all nodes in a multi-member
endpoint but with best effort in terms of getting to them all
and with custody and less frequent application layer re-tx's to
ensure we got to as many as possible.  This also affects 5.2.

(6) 3.3, I'm not sure this is useful either. What'd break if it
were deleted? (But then I never liked those bits of DTNRG's
work either;-)

(7) Including some examples and an RFC 7942 implementation
status section would be a good thing, if easily done. That
would help progression and increase confidence in the
correctness of the spec.

(8) 4.1.6: Was sub-second timing discussed by the WG?  I'm not
terribly pushed on that myself, but it'd be a shame to do an
interop breaking change in the BP without discussing that
topic. A reason to think about this is that there may be
inter-VM (or intra-data-centre) reasons to consider the BP with
sub-second timing as interesting.  It'd be a shame to make that
impossible just to make it slightly simpler to represent time.

(9) 4.2.2, creation time rules: I don't see why it'd be a
problem if node-id=X, creation-time=0,counter=0,lifetime=2s is
used in two bundles emitted 3 seconds apart. Why does that
justify a MUST NOT in the spec?

(10) 4.2.2: The "30 seconds" rule also seems wrong to me, as is
the "MUST NEVER" (not a 2119 term btw) for re-use of the seq
no, which is unrealistic.  As an example of that last: what do
you expect to happen with a node that usually knows the wall
clock time, but, at this moment, knows that it does not? E.g.
previous logs have some real dates, but current clock is
1970-01-01 or whatever. I think this is fixable but the current
language is too prescriptive. Best might be to weaken the
language here and to see what implementations do in the real
world.

(11) 4.3.1: Is the SHALL here right? I would have thought a
SHOULD is better to allow for legacy interop with 5050 via
gateways, in which case there may be no node ID. That might be
better off handled in some generic fashion though, and not
piecemeal with each mention of node ID.

(12) 4.3.2: I don't believe it is correct to drop a bundle due
to the lack of a previous node block, which is what sems to be
implied here. Not all routing schemes need this and so it ought
not be a MUST. Maybe a SHOULD is enough, but even if you say
"MUST insert this" then I would like to argue that "receivers
can decide to not care" be stated explicitly e.g.  by saying
that bundles MUST NOT be rejected solely due to the lack of
this EB.

(13) I'm not sure if you have all the right "watch out for the
null EID node ID" text needed. (I didn't go back over
everything, but it'd seem wrong e.g. in an current custodian
AR.

(14) 5.4: "The bundle protocol agent MUST determine which
node(s) to forward the bundle to." That's ungrammatical and
close to BS - what if I want to multicast or broadcast the
bundle or use some other opportunistic CLA? Or a sneakernet
where nobody knows who'll be next hop.

(15) 5.4: The text about the flow label should be deleted as it
says nothing. If includng this, then the flow label spec may
need to be a normative ref (arguably).

(16) 5.4 - I think this is badly misleading. There will be many
cases where a bundle cannot be forwarded now but may be
forwarded later. Am I wrong in reading this section as
precluding that?

(17) 5.6, step 4 says one MUST handle "custody transfer
redundancy" but that term seems undefined.

(18) 5.6 (step 5) points back to 5.3 which points to 5.7 or
5.4. I don't think such GOTOs are a good idea really.  I
suggest removing lots of this and adding in some informative
(i.e. non-normative) pseudo code (or real code) as an appendix.

(19) I think some rules related to custody and fragmentation
may be missing. For example, if bundle A is multicast and
reaches two nodes on different paths who take custody
(custodians C1/C2) and who both fragment but differently (into
F11/F12 and F21/F22 resp) with eventually a custody ack for F21
reaching C1.  Assume F21 is longer than F11, what is C1 to do
with F11 when a custody timer expires?  Ought it re-transmit or
consider that the custody ack for F21 matched F11 sufficiently
well?  I'm not sure what'd be right here, if such cases can
happen.  I'd be fine with the spec admitting that some such
corner cases exist, or maybe it's easy enough to figure out,
not sure.

(20) 5.10.1, I've always wondered why custody timer expiry is
covered here, and not really considered a part of DTN routing.
It seems to me to make more sense to couple custody timing and
routing. If that resonated with folks, I think the change would
be to make the timer-related text here into an illustrative
example and to say that such things are better considered
together with routing and/or by chunks of code that are
somewhat more topology/disruption-aware of the situation in the
particular DTN.

(21) section 9 seems woefully incomplete - why is it ok to say
"will be required" at WGLC? Surely the WG should at least have
discussed the set of registries needed and the registration
rules for those? E.g. do we sill want CCSDS to be able to add
entries to some of those registries as we did with 5050?  And
has the WG considered how do all the things in this draft
relate to the set of IANA registries related to the BP? [1,2]
(In the case of [3], section 4.1.5.1 really probably does need
to say something.)

  [1] https://www.iana.org/assignments/bundle/bundle.xhtml
  [2]
https://www.iana.org/assignments/uri-schemes/uri-schemes.xhtml#uri-schemes-1

Seemingly more minor or nitty things
------------------------------------

- abstract: "This Internet Draft" is no longer appropriate
language.

- abstract: I think this ought capture the fact that this
version is not interoperable with 5050. That's not a bad thing,
but worth noting here.

- intro: I don't think the "sales" language is needed or
appropriate in the first couple of paras. It should be entirely
ok to say "we've learned stuff and fixed stuff."

- intro: "Custodial forwarding" is too terse at this point but
also hard to explain briefly, is really a mechanism and not a
capabililty, and maybe not such a highlight, so I'd delete that
bullet

- intro: "[TUT]" is quite outdated and using dtnrg.org for the
reference isn't wise (particularly at the moment when we're
seeing SERVFAIL from the relevant NS;-)

- intro: this is a bit self-serving, but maybe a reference to
the architectural retrospective [3] that Kevin and I wrote
might be useful here, though I've not checked if it touches on
enough of the issues behind the differences between 5050 and
this.

   [3] https://ieeexplore.ieee.org/document/4530739

- Figure 1: I wonder if it'd be worth pointing out that the BP
does not have to run over a layer 4 that runs over a layer 3
etc. The figure and this text does give that impression that a
"proper" transport is needed, which isn't the case.
(Tactically, I'm not sure if the text as-is, or something more
correct, would make getting a new RFC easier or harder - I
guess it'll depend on the reader;-)

- Figure 2: Few if any of the applications I've used with the
BP had an administrative element. That's maybe down to the
experimental nature of the work we've done but I don't think
it's correct to imply that all applications using the BP need
to be able to handle admin records, if that's what you're
implying. (I'm not sure.) I'd say indicating that that's an
optional thing would be right.

- 3.1, singleton: not sure if it's clear enough that all
endpoints are sets, so this may puzzle folks. Maybe add e.g.
"remember that endpoints are sets," not sure.

- 3.1, forwarding: the text is odd - "sustained effort" is not
mandatory, and what "that node" is meant here?

- 4: The first two SHALL statements are odd in that there's no
way in which one could implement this spec and not conform to
those I think. In cases like that it's fine to avoid 2119
language. Not a big deal though, as the current IESG don't get
anal about that, though some ADs in the past have done;-)

- 4: last item MUST be break stop code. Is a decoder supposed
to barf a bundle if this is not true? More generally, same
question applies for all MUSTs stated only in terms of what the
encoding must match.

- 4.1.1: why >1 CRC type? That seems bogus. None or strong
seems better to me. (And I'd go for a crypto hash for strong.)
I assume the WG discussed this and found that there are real
use-cases for each of those specified. While those don't need
to be in the spec, can someone tell me what they are as I'm not
at all sure, e.g. why a 16 bit CRC is useful as an option.

- 4.1.3: "enables anonymous bundle transmission" - that's
overstated, chances are that something in the CLA will be
identifying, or allow re-identification, so I think what you
want to say is that omitting the source EID helps with, but
does not ensure, nymity.

- 4.1.5.1: RFC3986 is the correct reference here, so the spec
text is correct as-is. It may however be worth taking a look at
the whatwg web page that has sometimes claimed to supercede
3986 for the browser-related things in which whatwg have an
interest.  That's just in case there're some useful error
handling considerations on the whatwg web page, (on the day you
look at it;-). It's also the case that since BP EIDs are URIs,
it's possible that strings that comply with today's or
yesterday's whatwg web page may end up in the BP, so it'd be
good to know if any of those (that are not valid according to
3986) might cause a problem with the CBOR encoding.

- 4.1.5.2: Danger, metaphysics! "Every node MUST be a member of
at least one singleton endpoint." This entire section is
over-thought.  I think all you need to say is that nodes the
emit bundles need to have an EID they can use as a source EID
for as long as necessary.

- 4.2.1: this entire section is duplicative. That's a bad idea.

- 4.2.2: 2nd para is badly written - that'd encourage coders to
use the values 8,9,10 and 11 in ways that might be unwise.

- 4.2.2: wrt "anonymous" see earlier comment

- 4.2.2: description of creation time is duplicative, except
the earlier text didn't cover relative time.

- 4.3.3: Is "Bundle Age Block" a good name? BAB used to mean
another type of block, so that could confuse maybe. (That said,
I forget how long we're had this name.)

- 4.3.4: Do you need to say that the hop limit MUST NOT be
changed, once a hop count EB is added. Also, can any node add
one of these, if one was not prevsiously present?

- 5: It's not necessary to say that new RFCs can supercede
this.  That's just standard IEFF process.

- 5.2: mentions "dispatch pending" as if I should know what
that is - is all the retention constraint stuff sufficiently
explained I wonder? (Personally I don't think you need to
mandate all this stuff and you cannot tell if an implementation
has done it or not so I'd not bother trying to be so
prescriptive.)

- 5.4: "at the last possible moment... MUST..." that's a bit
silly as it seems to require BP code inside a NIC which is not
how this'll usually be implemented.

- 5.5: I'm not convinced that the MUSTs here are right for all
DTNs. I reckon that 5.5 could just as well say "MAY delete" and
the BP would be fine. That might also provide some additional
flexibility for some rounting schemes. That said, I won't press
on this - if this doesn't resonate with folks now, and later
turns out to be useful, I don't think we'd have such a hard
time modifying BPAs where needed.

- 5.6: Again, this is overly prescriptive.

- 5.6, step 4: I wonder if an implementer will get all this
right.

- 5.9: Badly implemented, re-assembly can create a memory
consumption DoS vector, perhaps esp. if attempted on a
non-destination node. It'd be better to warn about that. And
maybe change from MAY for in-path reassembly to SHOULD NOT.

- 5.11: does this mean that a custodian MUST ignore a custody
signal destined for some other custodian?

- Figure 6: I don't get when reason codes 5 to 8 would really
be used. Are they in fact needed?  (They seem a bit
implementation specific to me, but I've not gone looking.)

- section 8: First sentence is bogus.

- section 8: [SECO] isn't a good reference. It's outdated and I
doubt will be picked up.

---

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 24 Jan 2017 19:02:27 +0000

Hi Stephen,

I am still going through your comments, but one question that I have
on one of your points for now:

    "4) it's not ok to omit
    IMO needed),

Wouldn't that create a circular dependency? If not, what do you see
as a way forward that would not entail a prolonged blockage in the
RFC editor queue?

Thanks - Fred

> From: dtn [mailto:[email-masked]] On Behalf Of Stephen Farrell
> Sent: Monday, January 23, 2017 7:33 PM
> To: Marc Blanchet <[email-masked]>; dtn <[email-masked]>

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 24 Jan 2017 20:03:45 +0000

Hiya,

On 24/01/17 19:02, Templin, Fred L wrote:
> Wouldn't that create a circular dependency? 

That's not a problem. The RFC editor handles document clusters
like that all the time.

> If not, what do you see

I do think waiting for bpsec to be done is the right thing here.
I've no strong opinion as to whether it's better to have bpbis
wait "in" the WG or the RFC editor queue, though I can see why
folks would prefer the latter which I think is fine. (If some
aspect of bpsec called for some change in bpbis, your AD would
just help you get that done, but I'd say that's low probability.)

We had the equivalent (though imperfect:-) security mechanisms
defined for 5050, not having them while aiming for PS with
5050bis seems to me going backwards.

Not defining security mechanisms that are clearly needed (as
this document itself says) also runs counter to IETF BCPs on
security such as BCP61.

I'll also note that there's a history of efforts that try punt
on security mechanism definition taking longer in the end. (See
the history of the roll WG with RPL for example.)

So, functionally, formally and tactically I'd argue that the thing
to do is to have both RFCs issue at the same time.

Note though that I think it is reasonable to not aim to define
key management mechanisms that meet BCP107 for all possible uses
of the BP, so I also think finishing bpsec should be entirely
doable, e.g. via some kind of applicability statement text about
automated key management in bpsec (though there may be other ways
to handle that too).

Cheers,
S.

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Wed, 25 Jan 2017 13:29:06 +0900

If I might express an opinion here ...

> the history of the roll WG with RPL for example.)

It is certainly the case (in my experience) that there's a history of IESG
Evaluations taking longer/being less enjoyable for all parties when the
protocol specification says "please see this other draft for security" and
the working group says "we owe you one draft on security" ;-)

Do the right thing, of course.

Spencer

---

From: "I-Viswanathan, Kapaleeswaran" <[email-masked]>
Date: Wed, 25 Jan 2017 14:09:06 +0000

Hello:

>>>>>>>>>SNIP(Fred -> Stephen -> Fred -> Stephen -> Spencer)

>That's not a problem. The RFC editor handles document clusters

It is certainly the case (in my experience) that there's a history of IESG Evaluations taking longer/being less enjoyable for all parties when the protocol specification says "please see this other draft for security" and the working group says "we owe you one draft on security" ;-)
<<<<<<<SNIP

I see two ways forward for Bundle Protocol specification.

1.      The IPv4 way: by providing generic data structures for security headers but without providing any detailed specification for these headers.

a.      This approach will be useful to publish the transportation protocol (bundle protocol) specification first and then publish the security protocol (BPSec).

2.      The IPv6 way: by providing clearly specified headers (data structures) for interfacing transportation and security protocols.

a.      This approach will require a complete specification of transportation and security protocols (in different documents) and releasing them at the same time.

I see this as a matter of style, because IPSec has been successfully deployed on IPv4 and IPv6.

But, purely from a documentation perspective, in its current specification style, Bundle Protocol appears to be a similar to IPv6. In the IPv4 document reference model, security specification (IPSec) refers to transportation specification (IPv4) but not the other way around. In the IPv6 document reference model, transportation (IPv6) and security (IPSec) specifications cross-reference each other. The document references in IP and IPSec documents are as follows.

1.      IPSec –refers to--> IPv4, IPv6

2.      IPv6 –refers to--> IPSec

3.      IPv4 –does not refer to--> IPSec

Bundle Protocol specifies security in extension blocks (https://tools.ietf.org/html/draft-ietf-dtn-bpbis-06#section-4.3). IPv6 specifies security in extension headers (https://tools.ietf.org/html/rfc2460#section-4.1). In IPv6, data confidentiality is specified as optional while authentication and data integrity are mandatory. IPv4 specifies security as something that is needed in “some simutations” (https://tools.ietf.org/html/rfc791#section-1.4) and minimizes any heavy-weight attention to the topic.

The following text from IPv6 could be interesting in this regard.

A full implementation of IPv6 includes implementation of the

   following extension headers:

           Hop-by-Hop Options

           Routing (Type 0)

           Fragment

           Destination Options

           Authentication

           Encapsulating Security Payload

   The first four are specified in this document; the last two are

   specified in [RFC-2402<https://tools.ietf.org/html/rfc2402>] and [RFC-2406<https://tools.ietf.org/html/rfc2406>], respectively.

Best regards

Kapali

---

From: "Birrane, Edward J." <[email-masked]>
Date: Sat, 28 Jan 2017 20:27:11 +0000

I spent some time going through Stephen's comments trying to figure out a good way to address them. Rather than making dozens of individual posts on this mailing list, I put together a Google Doc spreadsheet as a way to try and capture thoughts on the items.

The document can be found and edited at:

https://docs.google.com/spreadsheets/d/1NDY3WB6JGoM0I-hNv8F03QxhNzdW8aitOEOcVfoOmUM/edit?usp=sharing

I have 3 sheets (DISCUSS, Minor, Nits) and in each sheet a column where I tried to more concisely distill the comments and then provide my own thoughts.  I would encourage others to make their own columns in the same way. I would also encourage other rows (representing new comments) to be added as we have them.

Not trying to stop or alter discussion on the mailing list itself, but I thought it might be a good idea to also have a place to capture WG member opinions as we go.

Please feel free to use if helpful.

-Ed

---
Edward J. Birrane, III, Ph.D.
Embedded Applications Group Supervisor
Space Exploration Sector
Johns Hopkins Applied Physics Laboratory
(W) 443-778-7423 / (F) 443-228-3839
________________________________
From: dtn <[email-masked]> on behalf of I-Viswanathan, Kapaleeswaran <[email-masked]>
Sent: Wednesday, January 25, 2017 9:09 AM
To: dtn
Subject: Re: [dtn] working group last call on draft-ietf-dtn-bpbis

           Hop-by-Hop Options

           Routing (Type 0)

           Fragment

           Destination Options

           Authentication

   specified in [RFC-2402<https://sslvpn.jhuapl.edu/html/,DanaInfo=tools.ietf.org,SSL+rfc2402>] and [RFC-2406<https://sslvpn.jhuapl.edu/html/,DanaInfo=tools.ietf.org,SSL+rfc2406>], respectively.

Best regards

Kapali

---

From: Stephen Farrell <[email-masked]>
Date: Sat, 28 Jan 2017 21:05:02 +0000

Hi Ed,

I do like the "(dis)agree" column and that there's a nice
scattering of yes/no/maybe values:-)

I'm not sure whether a google doc is a good way to have the
discussion or not though, but it'll be interesting to see.

If the chairs figured it'd help to have a call/interim to
go over all of the wGLC comments including these I'd be
happy to participate

Cheers,
S

On 28/01/17 20:27, Birrane, Edward J. wrote:
> I spent some time going through Stephen's comments trying to figure
> out a good way to address them. Rather than making dozens of
> individual posts on this mailing list, I put together a Google Doc
> spreadsheet as a way to try and capture thoughts on the items.
> 
> 
> I have 3 sheets (DISCUSS, Minor, Nits) and in each sheet a column
> where I tried to more concisely distill the comments and then provide
> my own thoughts.  I would encourage others to make their own columns
> in the same way. I would also encourage other rows (representing new
> comments) to be added as we have them.
> 
> 
> Not trying to stop or alter discussion on the mailing list itself,
> but I thought it might be a good idea to also have a place to capture
> WG member opinions as we go.
> 
> 
> --- Edward J. Birrane, III, Ph.D. Embedded Applications Group
> Supervisor Space Exploration Sector Johns Hopkins Applied Physics
> Laboratory (W) 443-778-7423 / (F) 443-228-3839 
> ________________________________ From: dtn <[email-masked]> on
> behalf of I-Viswanathan, Kapaleeswaran
> <[email-masked]> Sent: Wednesday, January 25,
> 2017 9:09 AM To: dtn Subject: Re: [dtn] working group last call on
> draft-ietf-dtn-bpbis
> 
> Hello:
> 
>> I am still going through your comments, but one question that I
>> have on one of your points for now:
>> 
>> "4) it's not ok to omit security mechanism definition, (making
>> [BPSEC] normative and waiting on that in the RFC editor queue would
>> fix this, and is IMO needed),
>> 
>> That's not a problem. The RFC editor handles document clusters like
>> that all the time.
> 
> It is certainly the case (in my experience) that there's a history of
> IESG Evaluations taking longer/being less enjoyable for all parties
> when the protocol specification says "please see this other draft for
> security" and the working group says "we owe you one draft on
> security" ;-) <<<<<<<SNIP
> 
> 1.      The IPv4 way: by providing generic data structures for
> security headers but without providing any detailed specification for
> these headers.
> 
> a.      This approach will be useful to publish the transportation
> protocol (bundle protocol) specification first and then publish the
> security protocol (BPSec).
> 
> 2.      The IPv6 way: by providing clearly specified headers (data
> structures) for interfacing transportation and security protocols.
> 
> a.      This approach will require a complete specification of
> transportation and security protocols (in different documents) and
> releasing them at the same time.
> 
> But, purely from a documentation perspective, in its current
> specification style, Bundle Protocol appears to be a similar to IPv6.
> In the IPv4 document reference model, security specification (IPSec)
> refers to transportation specification (IPv4) but not the other way
> around. In the IPv6 document reference model, transportation (IPv6)
> and security (IPSec) specifications cross-reference each other. The
> document references in IP and IPSec documents are as follows.
> 
> Bundle Protocol specifies security in extension blocks
> (https://tools.ietf.org/html/draft-ietf-dtn-bpbis-06#section-4.3).
> IPv6 specifies security in extension headers
> (https://tools.ietf.org/html/rfc2460#section-4.1). In IPv6, data
> confidentiality is specified as optional while authentication and
> data integrity are mandatory. IPv4 specifies security as something
> that is needed in “some simutations”
> (https://tools.ietf.org/html/rfc791#section-1.4) and minimizes any
> heavy-weight attention to the topic.
> 
> specified in
> [RFC-2402<https://sslvpn.jhuapl.edu/html/,DanaInfo=tools.ietf.org,SSL+rfc2402>]
> and
> [RFC-2406<https://sslvpn.jhuapl.edu/html/,DanaInfo=tools.ietf.org,SSL+rfc2406>],
> respectively.
> 
> 
> 
> Best regards
> 
> Kapali
> 
> 
> 
> 
> 
> 
> 
> 
> _______________________________________________ dtn mailing list 
> [email-masked] https://www.ietf.org/mailman/listinfo/dtn
>

---

From: Rick Taylor <[email-masked]>
Date: Mon, 30 Jan 2017 10:07:27 +0000

Thank you for this Ed.

I think it is a good repository for opinions on Stephen's comments, and
it would be nice to extend it to include other peoples comments as
well.  But, I don't want to see the mailing list fall silent, and would
ask that people explain their comments on the list, and then update the
relevant row in the spreadsheet.

Can I also request some more comments and feedback on the latest TCPCL
draft as well, please - it too is in Last Call.

Rick

On Sat, 2017-01-28 at 20:27 +0000, Birrane, Edward J. wrote:
> From: dtn <[email-masked]> on behalf of I-Viswanathan,
> Kapaleeswaran <[email-masked]>
> security" ;-)
> Bundle Protocol specifies security in extension blocks (https://tools
> .ietf.org/html/draft-ietf-dtn-bpbis-06#section-4.3). IPv6 specifies
> security in extension headers
>    specified in [RFC-2402] and [RFC-2406], respectively.
>  
> Best regards
> Kapali 
>  
>  
>  
>

---

From: "Templin, Fred L" <[email-masked]>
Date: Mon, 30 Jan 2017 18:57:10 +0000

Hi Rick,

I agree that Ed's repository idea is a good one, and represents an organized
approach at resolving the issues. Conversely, I would be concerned that an
attempt to address all of the issues only through list posts would quickly spiral
out of control given the large and involved set of WGLC comments.

I agree that there should be some form of communication on the list that
tracks with the work that is going on in the spreadsheet, but can we have
some kind of agreement that the spreadsheet will be the place to capture
the proposed resolutions?

Thanks - Fred 

> From: dtn [mailto:[email-masked]] On Behalf Of Rick Taylor
> Sent: Monday, January 30, 2017 2:07 AM
> To: I-Viswanathan, Kapaleeswaran <[email-masked]>; [email-masked]; [email-masked]

---

From: Rick Taylor <[email-masked]>
Date: Tue, 31 Jan 2017 09:53:31 +0000

> the proposed resolutions?

Good point Fred, I was trying to suggest that I would like to see
discussion continue on the list, but with resolution/issue summaries
maintained in the spreadsheet for clarity.  As document shepherd, if
you want to use the spreadsheet as the 'ground-truth' for clarity, I'm
fine with that.

Rick

> > To: I-Viswanathan, Kapaleeswaran <kapaleeswaran.viswanathan@boeing.
> > com>; [email-masked]; [email-masked]
> > > https://docs.google.com/spreadsheets/d/1NDY3WB6JGoM0I-hNv8F03QxhN
> > > zdW8
> > > aitOEOcVfoOmUM/edit?usp=sharing
> > > 
> > > have
> > > I see this as a matter of style, because IPSec has been
> > > successfully
> > > deployed on IPv4 and IPv6.
> > >