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

From: "Burleigh, Scott C (312B)" <[email-masked]>
Date: Wed, 15 Mar 2017 17:00:31 +0000

Hi.  As Rick suggested, I'm posting my thoughts on Stephen's comments to the list in addition to noting them on Ed's spreadsheet - mainly transcribing them but amplifying in a few instances.  In-line below.

Scott

-----Original Message-----
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]>
Subject: Re: [dtn] working group last call on draft-ietf-dtn-bpbis

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

	-	I'm fine with bringing bpsec along at the same time as bp(bis) and tcpcl.

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

	-	I disagree.  In general, I think this language needs to be normative in order to ensure coherent behavior among nodes of the network.

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

	-	I agree with making all status report generation "SHOULD" rather than "MUST".  But if it is possible to generate status reports (and I think it has to be, for network troubleshooting purposes) then it is always possible for a badly engineered implementation to generate them more frequently than might be optimal in a given network.  I'm unclear on how we can legislate against that.  Strong language warning the implementer of the possible dangers would be fine with me; is that enough?  Something like "Implementations MUST limit the generation of status reports so as to prevent excessive network traffic.  Strategies for limiting status report generation are beyond the scope of this specification."

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.

	-	I think having that discussion would be fine.  I don't think that discussion has to happen in this specification, nor that it has to happen before this specification is published.

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

	-	The spec doesn't define "success" at all, and I don't know why it would need to.

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

	-	I think 3.2 is essential to the specification.  I'm fine with moving the 2119 language to another section, if that helps.

(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?

	-	I think that would make the behavior of nodes so indeterminate that it can't be tested.

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

	-	"Singleton" doesn't say how many nodes are in the endpoint.  It says what the maximum number of nodes in the endpoint is.  The source node should know this.

(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;-)

	-	Sure, don't care.

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

	-	I don't think this is really necessary, but I don't mind adding an implementation status section.

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

	-	It was discussed by the WG, and I believe we concluded that sub-second time representation wasn't needed here.

(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?

	-	I agree with Ed on this.  There may be purposes for which a log of bundles may be needed; that's impossible if bundles are not uniquely identified.

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

	-	Sure.

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

	-	There are node IDs in 5050 also, they're just not called by that term.  I think SHALL is correct here.

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

	-	I think this will be a source of headaches eventually, but sure, we can relax this.

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

	-	I don't think there's an issue here, but sure, let's re-read with this in mind.

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

	-	Of course the BPA must determine which node(s) to forward the bundle to.  What else is going to make that determination?  Nothing in the spec says it has to make that determination right now; maybe it sets the bundle aside for a while until a data mule comes along - and then it determines that this data mule is one of the nodes to forward the bundle to.  The text is correct.

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

	-	Okay.

(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?

	-	You are wrong in reading this section as precluding deferred transmission.

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

	-	Sure, let's add a clause saying "this condition is termed 'custody transfer redundancy'".

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

	-	I disagree.

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

	-	I don't think there is a problem.  Custody transfer is undefined if the destination endpoint is not singleton.

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

	-	Custodial retransmission really has nothing to do with routing.

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

	-	Sure, let's review what other registries are needed here.

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

	-	Sure.

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

	-	Worth saying, but not in the Abstract.

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

	-	Sure, whatever.

- 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

	-	I disagree.  Let's turn it into a sentence and keep it.

- 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;-)

	-	Sure.

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

	-	I don't think this is needed.

   [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;-)

	-	No, the spec already says "BP uses underlying "native" transport and/or network protocols".

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

	-	I disagree.  The application agent -- not the application -- is the thing that has an administrative element.  We could say that a given BPA's application agent might lack an administrative element, in which case the node could not take custody of a bundle.  I don't see much advantage in that, but I don't mind saying it.

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

	-	Let's assume that people reading this specification are able to read.

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

	-	Nothing says how long "sustained" is, but okay, we could delete the word.  But I have no idea how to make this sentence any clearer.  There is exactly one possible antecedent for "that node".

- 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;-)

	-	I think those statements are needed and are not obvious.

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

	-	Let's add a general statement, somewhere, to the effect that the bundle protocol agent MAY discard any malformed bundle it receives.

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

	-	The WG discussed this and settled on these options.  See email list traffic starting on 18 January 2016.

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

	-	"Anonymous" doesn't mean you can't figure out who did it.  "Anonymous" means the identity of whoever did it was not attached to it.  The text is correct as written.

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

	-	If the text is correct, let's leave it.  If someone discovers that it is in error for one or more of the reasons proposed, then let's fix it.

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

	-	I disagree.  The section is exactly enough-thought.

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

	-	If the text that it duplicates can be identified then we should remove the duplication.

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

	-	The text says nothing about using any values in any manner, for good or ill.   It only says how many elements are in the array.

- 4.2.2: wrt "anonymous" see earlier comment

	-	Correct as written, as noted above.

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

	-	This section is not duplicative, it is expansive.

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

	-	There are no longer any Bundle Authentication Blocks.  "Bundle Age Block" is a good 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?

	-	I agree, this needs to be clarified.

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

	-	I don't see what harm this does.  For someone who is not steeped in standard IETF process, but wants to read the specification anyway, maybe it would be useful information.

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

	-	All of the retention constraint stuff is explained in detail.  I think it's necessary in order to ensure coherent behavior among the nodes of the network.

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

	-	I don't understand the objection.  "Last possible moment" is very clearly in the scope of the operation of the CLA, which is BP code.  If that happens to be embedded in a NIC, fine, but that's not relevant.

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

	-	Here again I think the normative language is necessary in order to ensure coherent behavior among the nodes of the network.

- 5.6: Again, this is overly prescriptive.

	-	I disagree, again because the normative language is necessary in order to ensure coherent behavior among the nodes of the network.

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

	-	It has been implemented.  The implementation works fine.

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

	-	I am doubtful that this specification should be a compendium of implementation tips.

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

	-	This text does not imply that the receiving node must ignore a custody signal destined for another custodian.  It means exactly what it says, and no more.

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

	-	DTNRG thought these codes would be needed.  Let's get more deployment experience before deciding that they are not.

- section 8: First sentence is bogus.

	-	Not bogus, but not necessary.  Sure, let's delete it.

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

	-	Okay.

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 15 Mar 2017 22:22:46 +0000

Hi Scott,

Thanks for that, likely Friday before I'll get a chance to
respond substantively,

Cheers,
S.

On 15/03/17 17:00, Burleigh, Scott C (312B) wrote:
> _______________________________________________
> dtn mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dtn
>

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 15 Mar 2017 23:47:43 +0100

On 24 Jan 2017, at 04:33, Stephen Farrell <[email-masked]> wrote:
> 
> 
> - 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

Following this WG only with one eye:

Has there been any progress on this issue?

Will the IETF deprecate RFC 3986 and point to the WHATWG web page instead?

Do we know about any specific issues with the use of WHATWG URLs as URIs (except that the web page might change at any time)?

As far as I can see from the CDDL, you have insured yourself against any trouble here by representing the scheme-specific part as a byte string — a text string would be a bit more natural, but then if WHATWG decides their WHATWG URLs are no longer UTF-8 strings that might break.

(While I have your attention, I agree with the previous comment that the CRC should be a byte string, not a uint of possibly variable representation length.)

Grüße, Carsten

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 15 Mar 2017 23:06:06 +0000

> Will the IETF deprecate RFC 3986 and point to the WHATWG web page

I certainly hope not and would argue strongly against any
proposal to do that.

I also don't think it's likely as we generally prefer stable
references and the whatwg thing is not that. While their
approach may be suitable for browsers and how those use URLs,
it'd not work for the many other things that refer to 3986.

But this isn't the right list for that squabble probably:-)

Cheers,
S.

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 20 Mar 2017 22:06:19 +0000

Hi Scott,

Belated responses below. I hope the quoting isn't too messed up to
follow.

As a TL;DR, I'd say we might be best to debate point (B) below, that
the current text is overly prescriptive. I'm entirely happy that the
DoS-vector that would be the current reporting text won't make it to
the RFC, so am ok if we don't spend so much time on that.

For the "too prescriptive" point, I think you and I Scott have had
that debate before, so I'd be most interested in other WG participants
telling me I'm just wrong that all those MUSTs are needed for interop.
(I mean using some of the examples below that refer back to point (B)
and not literally a sentence that means the same as the sentence
before this one:-)

Cheers,
S.

On 15/03/17 17:00, Burleigh, Scott C (312B) wrote:
> Hi.  As Rick suggested, I'm posting my thoughts on Stephen's comments
> to the list in addition to noting them on Ed's spreadsheet - mainly
> transcribing them but amplifying in a few instances.  In-line below.
> 
> Scott
> 
> -----Original Message----- 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]> 
> 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.
> 
> 
> (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.)
> 

Cool. I think that's the right choice.

> 
> (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.
> 
> -	I disagree.  In general, I think this language needs to be
> normative in order to ensure coherent behavior among nodes of the
> network.

Yep, I figured we'd not see eye to eye on the broader conformance
issue, in the same way that we've disagreed about that for about a
decade now:-)

Nonetheless, I will continue to argue the point, and I note that
you didn't respond to the examples in the above. Those are only
examples, but I think some discussion of them may help us to see
that the current text is (or is not) overly prescriptive.

> 
> (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.
> 
> -	I agree with making all status report generation "SHOULD" rather
> than "MUST".  But if it is possible to generate status reports (and I
> think it has to be, for network troubleshooting purposes) then it is
> always possible for a badly engineered implementation to generate
> them more frequently than might be optimal in a given network.  I'm
> unclear on how we can legislate against that.  Strong language
> warning the implementer of the possible dangers would be fine with
> me; is that enough?  Something like "Implementations MUST limit the
> generation of status reports so as to prevent excessive network
> traffic.  Strategies for limiting status report generation are beyond
> the scope of this specification."

I think that a SHOULD for emitting these is just wrong for the
Internet. If 10^8 BPAs were deployed (there are maybe that many
web sites) and each by default will emit these reports then
that'd be just crazy as they could be per-hop and could bounce
around all over the place. At that scale there'd also no doubt be
reports generating reports (due to gatewaying even if that was
disallowed in the BP) and one would get explosions of reports.
I think the only defensible position is for *all* of these to be
specified as "MUST be off by default" to be acceptable for a
proposed standard.

I would be ok if someone wanted to try characterise the kind of
DTN or node(s) in which it'd be ok to have these turned on. That
could of course be done in a separate document later. (Or outside
the IETF if it was e.g. really better a CCSDS thing.)

> (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.
> 
> -	I think having that discussion would be fine.  I don't think that
> discussion has to happen in this specification, nor that it has to
> happen before this specification is published.

Disagree. I think now is exactly the right time to do a privacy
analysis. Later will be too late, if the protocol gets deployed
at scale. Note that I'm not arguing that the result has to be a
BP with fully understood and perfect privacy features.

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

Sure, but I was more asking for clarity - I didn't find it to be
that well explained what kind of effort(s) are expected with
endpoints containing >1 node.

> 
> (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.
> 
> -	I think 3.2 is essential to the specification.  I'm fine with
> moving the 2119 language to another section, if that helps.

Again, I don't think we'll agree here, as with point (B) above:-)

I note that you've not given an argument for including 3.2 though
other than stating that it's essential, and I did ask what'd be
lost if it were deleted so that seems not highly responsive.

> 
> (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?
> 

I don't get that. Given that we're not defining routing here, aren't
we in that position already? We can't for example tell if a node
emitting 10 copies of a bundle at different times, to different next
hops, on different interfaces etc. is good or bad or not.

> 
> (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.
> 
> -	"Singleton" doesn't say how many nodes are in the endpoint.  It
> says what the maximum number of nodes in the endpoint is.  The source
> node should know this.

Huh? How can a source know that in general? I maintain my position:-)

> 
> (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;-)
> 
> -	Sure, don't care.

(I'll skip over stuff where there's little or nothing more to
say, like this one:-)

> 
> (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.
> 
> -	It was discussed by the WG, and I believe we concluded that
> sub-second time representation wasn't needed here.

That makes me a bit sad. If anyone else would like sub-second timing
maybe now'd not be too late if we ask nicely?

> 
> (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?
> 
> -	I agree with Ed on this.  There may be purposes for which a log of
> bundles may be needed; that's impossible if bundles are not uniquely
> identified.

(I'm not sure I saw Ed's argument, I guess it was not on the list,
sorry if I missed it.)

I'd be a bit concerned that the MUST NOT is too hard to nodes without
good clocks and will just be ignored across reboots. If other code
elsewhere (e.g. log analysis) depended on a fiction from here that'd
not be great.

> 
> (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.
> 
> -	Sure.
> 
> (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.
> 
> -	There are node IDs in 5050 also, 

Well, sorta but not really. IIRC implementations and deployments
mostly did include the moral-equivalent but didn't have to.

> they're just not called by that
> term.  I think SHALL is correct here.

But fair enough, if nobody else cared, I'd fold on this one.

> 
> (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.
> 
> -	Of course the BPA must determine which node(s) to forward the
> bundle to.  What else is going to make that determination?  Nothing
> in the spec says it has to make that determination right now; maybe
> it sets the bundle aside for a while until a data mule comes along -
> and then it determines that this data mule is one of the nodes to
> forward the bundle to.  The text is correct.

Disagree. A BPA might decide to send the bundle on an interface
that's broadcast in nature and not care who turns out to be the
next hop that e.g. accepts custody. I think the text reflects a
quite narrow conception of a CLA.

> 
> (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).
> 
> -	Okay.
> 
> (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?
> 

Maybe it needs rewording then. (Happy to look over it with you
later.)

> (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.
> 
> -	I disagree.

See point (B) above I guess:-)

> 
> (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.
> 
> -	I don't think there is a problem.  Custody transfer is undefined if
> the destination endpoint is not singleton.

I wasn't referring to the destination here, C1/C2 are just routers
on paths to that destination. So I do think there's a problem, sorry.

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

I guess we disagree again there. I'd say with almost all routing
schemes (CGR and similar being an exception) figuring out the
best way to handle these timers will be intimately related to
routing. See also point (B) above:-)

> 
> (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] 
> - 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."
> 
> -	Sure, whatever.
> 
> - 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;-)
> 
> -	Sure.
> 
> - 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.
> 
> - 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.
> 
> -	I disagree.  The application agent -- not the application -- is the
> thing that has an administrative element.  We could say that a given
> BPA's application agent might lack an administrative element, in
> which case the node could not take custody of a bundle.  I don't see
> much advantage in that, but I don't mind saying it.
> 
> - 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?
> 
> -	Nothing says how long "sustained" is, but okay, we could delete the
> word.  But I have no idea how to make this sentence any clearer.
> There is exactly one possible antecedent for "that node".
> 
> - 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.
> 
> -	Let's add a general statement, somewhere, to the effect that the
> bundle protocol agent MAY discard any malformed bundle it receives.
> 
> - 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.
> 
> -	"Anonymous" doesn't mean you can't figure out who did it.
> "Anonymous" means the identity of whoever did it was not attached to
> it.  The text is correct as written.

Disagree. The term anonymous has a meaning which is not that.

> 
> - 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.
> 
> -	If the text is correct, let's leave it.  If someone discovers that
> it is in error for one or more of the reasons proposed, then let's
> fix it.
> 
> - 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.
> 

See point (B) above:-) And "exactly"? :-)

> - 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.
> 
> -	The text says nothing about using any values in any manner, for
> good or ill.   It only says how many elements are in the array.
> 
> - 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?
> 
> -	I don't see what harm this does.  For someone who is not steeped in
> standard IETF process, but wants to read the specification anyway,
> maybe it would be useful information.
> 
> - 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.)
> 
> -	All of the retention constraint stuff is explained in detail.  I
> think it's necessary in order to ensure coherent behavior among the
> nodes of the network.

See point (B) above:-)

> 
> - 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.
> 
> -	I don't understand the objection.  "Last possible moment" is very
> clearly in the scope of the operation of the CLA, which is BP code.
> If that happens to be embedded in a NIC, fine, but that's not
> relevant.
> 
> - 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.
> 
> -	Here again I think the normative language is necessary in order to
> ensure coherent behavior among the nodes of the network.

See point (B) above.

> -	I disagree, again because the normative language is necessary in
> order to ensure coherent behavior among the nodes of the network.
> 

See point (B) above.

> -	It has been implemented.  The implementation works fine.

Yeah, but you've been doing this for ages, it's a new implementer
we need to consider, starting from the RFC.

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

s/MAY/SHOULD NOT/ is way more than a tip

> -	This text does not imply that the receiving node must ignore a
> custody signal destined for another custodian.  It means exactly what
> it says, and no more.
> 
> - 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.)
> 
> -	DTNRG thought these codes would be needed.  Let's get more
> deployment experience before deciding that they are not.
>

---

From: "Burleigh, Scott C (312B)" <[email-masked]>
Date: Mon, 27 Mar 2017 20:27:55 +0000

Hi, Stephen.  I won't try to respond to all these points now, but I do want to advance a little bit of an argument on your point (B).

If we look at, say, RFC 5681, I think we see a great deal of firmly prescriptive text that has nothing to do with what bits are transmitted over the wire, and everything to do with how the TCP state machine is supposed to behave.  I think this is true of virtually every MUST in the specification, and I think that in the absence of this prescriptive language it would be impossible to distinguish a correctly functioning router from a broken one -- impossible to test a router for correct operation.

I think the prescriptive language in the BPbis specification is just as necessary, for exactly the same reasons.

I understand that you disagree, but I don't yet understand why.

Scott

-----Original Message-----
From: Stephen Farrell [mailto:[email-masked]] 
Sent: Monday, March 20, 2017 3:06 PM
To: Burleigh, Scott C (312B) <[email-masked]>; Marc Blanchet <[email-masked]>; dtn <[email-masked]>
Subject: Re: [dtn] working group last call on draft-ietf-dtn-bpbis

Hi Scott,

Belated responses below. I hope the quoting isn't too messed up to follow.

As a TL;DR, I'd say we might be best to debate point (B) below, that the current text is overly prescriptive. I'm entirely happy that the DoS-vector that would be the current reporting text won't make it to the RFC, so am ok if we don't spend so much time on that.

For the "too prescriptive" point, I think you and I Scott have had that debate before, so I'd be most interested in other WG participants telling me I'm just wrong that all those MUSTs are needed for interop.
(I mean using some of the examples below that refer back to point (B) and not literally a sentence that means the same as the sentence before this one:-)

Cheers,
S.

On 15/03/17 17:00, Burleigh, Scott C (312B) wrote:
> 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.
> 
> 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.)
> 

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

Yep, I figured we'd not see eye to eye on the broader conformance issue, in the same way that we've disagreed about that for about a decade now:-)

Nonetheless, I will continue to argue the point, and I note that you didn't respond to the examples in the above. Those are only examples, but I think some discussion of them may help us to see that the current text is (or is not) overly prescriptive.

> 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.
> 
> always possible for a badly engineered implementation to generate them 
> more frequently than might be optimal in a given network.  I'm unclear 
> on how we can legislate against that.  Strong language warning the 
> implementer of the possible dangers would be fine with me; is that 
> enough?  Something like "Implementations MUST limit the generation of 
> status reports so as to prevent excessive network traffic.  Strategies 
> for limiting status report generation are beyond the scope of this 
> specification."

I think that a SHOULD for emitting these is just wrong for the Internet. If 10^8 BPAs were deployed (there are maybe that many web sites) and each by default will emit these reports then that'd be just crazy as they could be per-hop and could bounce around all over the place. At that scale there'd also no doubt be reports generating reports (due to gatewaying even if that was disallowed in the BP) and one would get explosions of reports.
I think the only defensible position is for *all* of these to be specified as "MUST be off by default" to be acceptable for a proposed standard.

I would be ok if someone wanted to try characterise the kind of DTN or node(s) in which it'd be ok to have these turned on. That could of course be done in a separate document later. (Or outside the IETF if it was e.g. really better a CCSDS thing.)

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

Disagree. I think now is exactly the right time to do a privacy analysis. Later will be too late, if the protocol gets deployed at scale. Note that I'm not arguing that the result has to be a BP with fully understood and perfect privacy features.

> -	The spec doesn't define "success" at all, and I don't know why it

Sure, but I was more asking for clarity - I didn't find it to be that well explained what kind of effort(s) are expected with endpoints containing >1 node.

I note that you've not given an argument for including 3.2 though other than stating that it's essential, and I did ask what'd be lost if it were deleted so that seems not highly responsive.

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

I don't get that. Given that we're not defining routing here, aren't we in that position already? We can't for example tell if a node emitting 10 copies of a bundle at different times, to different next hops, on different interfaces etc. is good or bad or not.

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

> deleted? (But then I never liked those bits of DTNRG's work

(I'll skip over stuff where there's little or nothing more to say, like this one:-)

> sub-second time representation wasn't needed here.

That makes me a bit sad. If anyone else would like sub-second timing maybe now'd not be too late if we ask nicely?

> bundles may be needed; that's impossible if bundles are not uniquely 

(I'm not sure I saw Ed's argument, I guess it was not on the list, sorry if I missed it.)

I'd be a bit concerned that the MUST NOT is too hard to nodes without good clocks and will just be ignored across reboots. If other code elsewhere (e.g. log analysis) depended on a fiction from here that'd not be great.

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

Well, sorta but not really. IIRC implementations and deployments mostly did include the moral-equivalent but didn't have 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 
> bundle to.  What else is going to make that determination?  Nothing in 
> the spec says it has to make that determination right now; maybe it 
> sets the bundle aside for a while until a data mule comes along - and 
> then it determines that this data mule is one of the nodes to forward 
> the bundle to.  The text is correct.

Disagree. A BPA might decide to send the bundle on an interface that's broadcast in nature and not care who turns out to be the next hop that e.g. accepts custody. I think the text reflects a quite narrow conception of a CLA.

> corner cases exist, or maybe it's easy enough to figure out, not sure.
> 

I wasn't referring to the destination here, C1/C2 are just routers on paths to that destination. So I do think there's a problem, sorry.

> chunks of code that are somewhat more topology/disruption-aware of the 
> situation in the particular DTN.
> 

I guess we disagree again there. I'd say with almost all routing schemes (CGR and similar being an exception) figuring out the best way to handle these timers will be intimately related to routing. See also point (B) above:-)

> be required" at WGLC? Surely the WG should at least have discussed the 
> set of registries needed and the registration rules for those?
> 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.
> 
> 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;-)
> 
> BPA's application agent might lack an administrative element, in which 
> case the node could not take custody of a bundle.  I don't see much 
> advantage in that, but I don't mind saying it.
> 
> - 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 
> though, as the current IESG don't get anal about that, though some ADs 
> in the past have done;-)
> 
> 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.
> 

> 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 
> it'd be good to know if any of those (that are not valid according to 
> it is in error for one or more of the reasons proposed, then let's fix 
> it.
> 

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

See point (B) above:-)

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

See point (B) above.

See point (B) above.

> -	It has been implemented.  The implementation works fine.

Yeah, but you've been doing this for ages, it's a new implementer we need to consider, starting from the RFC.

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

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 27 Mar 2017 21:36:45 +0100

Hi Scott,

On 27/03/17 21:27, Burleigh, Scott C (312B) wrote:
> Hi, Stephen.  I won't try to respond to all these points now, but I
> do want to advance a little bit of an argument on your point (B).
> 
> If we look at, say, RFC 5681, I think we see a great deal of firmly
> prescriptive text that has nothing to do with what bits are
> transmitted over the wire, and everything to do with how the TCP
> state machine is supposed to behave.  

But 5681 is based on some decades of really widespread deployment.
If the BP were in that position I think you'd have a good argument
there, but it isn't.

> I think this is true of
> virtually every MUST in the specification, and I think that in the
> absence of this prescriptive language it would be impossible to
> distinguish a correctly functioning router from a broken one --
> impossible to test a router for correct operation.

I don't believe that an ability to test such correctness from outside
a router is really necessary nor desirable at this point in the
evolution of the BP.

> I think the prescriptive language in the BPbis specification is just
> as necessary, for exactly the same reasons.
> 

I guess I'll point at the examples I offered as to why. I look forward
to seeing your (or others') responses to those examples.

I do hope we agree that egregious/unnecessary MUST statements are a
bad idea though. If so, the question becomes whether or not all these
many MUSTs are needed or not.

Cheers,
S.

> 
> Scott
> 
> -----Original Message----- From: Stephen Farrell
> [mailto:[email-masked]] Sent: Monday, March 20, 2017 3:06
> PM To: Burleigh, Scott C (312B) <[email-masked]>; Marc
> Blanchet <[email-masked]>; dtn <[email-masked]> Subject: Re:
> [dtn] working group last call on draft-ietf-dtn-bpbis
> 
> 
> Hi Scott,
> 
> that debate before, so I'd be most interested in other WG
> participants telling me I'm just wrong that all those MUSTs are
> needed for interop. (I mean using some of the examples below that
> refer back to point (B) and not literally a sentence that means the
> same as the sentence before this one:-)
> 
> Cheers, S.
> 
>> Hi.  As Rick suggested, I'm posting my thoughts on Stephen's
>> comments to the list in addition to noting them on Ed's spreadsheet
>> - mainly transcribing them but amplifying in a few instances.
>> In-line below.
>> 
>> Scott
>> 
>> -----Original Message----- From: dtn [mailto:[email-masked]]
>> On Behalf Of Stephen Farrell Sent: Monday, January 23, 2017 7:33 PM
>> 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.
>> 
>> there (I escape in March) so the fact that I would ballot DISCUSS
>> is not that relevant to what other ADs might do.
>> 
>> 
>> (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.)
>> 
>> 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.
>> 
> Nonetheless, I will continue to argue the point, and I note that you
> didn't respond to the examples in the above. Those are only examples,
> but I think some discussion of them may help us to see that the
> current text is (or is not) overly prescriptive.
> 
>> 
>>  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.
>> 
>> than "MUST".  But if it is possible to generate status reports (and
>> I think it has to be, for network troubleshooting purposes) then it
>> is always possible for a badly engineered implementation to
>> generate them more frequently than might be optimal in a given
>> network.  I'm unclear on how we can legislate against that.  Strong
>> language warning the implementer of the possible dangers would be
>> fine with me; is that enough?  Something like "Implementations MUST
>> limit the generation of status reports so as to prevent excessive
>> network traffic.  Strategies for limiting status report generation
>> are beyond the scope of this specification."
> 
> Internet. If 10^8 BPAs were deployed (there are maybe that many web
> sites) and each by default will emit these reports then that'd be
> just crazy as they could be per-hop and could bounce around all over
> the place. At that scale there'd also no doubt be reports generating
> reports (due to gatewaying even if that was disallowed in the BP) and
> one would get explosions of reports. I think the only defensible
> position is for *all* of these to be specified as "MUST be off by
> default" to be acceptable for a proposed standard.
> 
> I would be ok if someone wanted to try characterise the kind of DTN
> or node(s) in which it'd be ok to have these turned on. That could of
> course be done in a separate document later. (Or outside the IETF if
> it was e.g. really better a CCSDS thing.)
> 
>> 
>>  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.
>> 
>> -	I think having that discussion would be fine.  I don't think
>> that discussion has to happen in this specification, nor that it
>> has to happen before this specification is published.
> 
> analysis. Later will be too late, if the protocol gets deployed at
> scale. Note that I'm not arguing that the result has to be a BP with
> fully understood and perfect privacy features.
> 
>> 
>>  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.
>> 
> Sure, but I was more asking for clarity - I didn't find it to be that
> well explained what kind of effort(s) are expected with endpoints
> containing >1 node.
> 
>> 
>> (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.
>> 
> other than stating that it's essential, and I did ask what'd be lost
> if it were deleted so that seems not highly responsive.
> 
>> 
>> 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.
>> 
>> says what the maximum number of nodes in the endpoint is.  The
>> source node should know this.
> 
>> (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;-)
>> 
>> -	Sure, don't care.
> 
>> 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?
>> 
>> -	I agree with Ed on this.  There may be purposes for which a log
>> of bundles may be needed; that's impossible if bundles are not
>> uniquely identified.
> 
>>  "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
>> 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.
>> 
>> -	Sure.
>> 
>> (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.
>> 
>> they're just not called by that term.  I think SHALL is correct
>> here.
> 
>> (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.
>> 
>>  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.
>> 
>> it sets the bundle aside for a while until a data mule comes along
>> - and then it determines that this data mule is one of the nodes to
> that's broadcast in nature and not care who turns out to be the next
> hop that e.g. accepts custody. I think the text reflects a quite
> narrow conception of a CLA.
> 
>> 
>> (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).
>> 
>> -	Okay.
>> 
>> (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.
>> 
>>  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.
>> 
>> -	I don't think there is a problem.  Custody transfer is undefined
>> if the destination endpoint is not singleton.
> 
> I wasn't referring to the destination here, C1/C2 are just routers on
> paths to that destination. So I do think there's a problem, sorry.
> 
>> 
>> (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.
>> 
> schemes (CGR and similar being an exception) figuring out the best
> way to handle these timers will be intimately related to routing. See
> also point (B) above:-)
> 
>> 
>> (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.)
>> 
>> https://www.iana.org/assignments/uri-schemes/uri-schemes.xhtml#uri-sch
>>
>> 
emes-1
>> - 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."
>> 
>> -	Sure, whatever.
>> 
>>  hard to explain briefly, is really a mechanism and not a
>> capabililty, and maybe not such a highlight, so I'd delete that
>> bullet
>> 
>> 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.
>> 
>> -	I disagree.  The application agent -- not the application -- is
>> the thing that has an administrative element.  We could say that a
>> given BPA's application agent might lack an administrative element,
>> in which case the node could not take custody of a bundle.  I don't
>> see much advantage in that, but I don't mind saying it.
>> 
>> -	Nothing says how long "sustained" is, but okay, we could delete
>> the word.  But I have no idea how to make this sentence any
>> clearer. There is exactly one possible antecedent for "that node".
>> 
>> - 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.
>> 
>> 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.
>> 
>> -	The WG discussed this and settled on these options.  See email
>> list traffic starting on 18 January 2016.
>> 
>> - 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.
>> 
>> "Anonymous" means the identity of whoever did it was not attached
>> to it.  The text is correct as written.
> 
>> - 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.
>> 
>> -	If the text is correct, let's leave it.  If someone discovers
>> that it is in error for one or more of the reasons proposed, then
>> let's fix it.
>> 
>>  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.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.)
>> 
>>  once a hop count EB is added. Also, can any node add one of these,
>> if one was not prevsiously present?
>> 
>> -	I don't see what harm this does.  For someone who is not steeped
>> in standard IETF process, but wants to read the specification
>> anyway, maybe it would be useful information.
>> 
>> - 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.
>> 
>> -	I don't understand the objection.  "Last possible moment" is
>> very clearly in the scope of the operation of the CLA, which is BP
>> code. If that happens to be embedded in a NIC, fine, but that's not
>>  relevant.
>> 
>> - 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.
>> 
>> -	Here again I think the normative language is necessary in order
>> to ensure coherent behavior among the nodes of the network.
> 
> See point (B) above.
> 
>> 
>> - 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?
>> 
>> custody signal destined for another custodian.  It means exactly
>> what it says, and no more.
>> 
> _______________________________________________ dtn mailing list 
> [email-masked] https://www.ietf.org/mailman/listinfo/dtn
>

---

From: "Burleigh, Scott C (312B)" <[email-masked]>
Date: Mon, 27 Mar 2017 21:15:43 +0000

Okay, if you believe that it is unnecessary to be able to test for the correct operation of a BP agent -- that is, an implementation of an Internet standards-track RFC -- then I think we may be at the root of the issue.  Let's continue tomorrow.

Scott

-----Original Message-----
From: Stephen Farrell [mailto:[email-masked]] 
Sent: Monday, March 27, 2017 1:37 PM
To: Burleigh, Scott C (312B) <[email-masked]>; Marc Blanchet <[email-masked]>; dtn <[email-masked]>
Subject: Re: [dtn] working group last call on draft-ietf-dtn-bpbis

Hi Scott,

On 27/03/17 21:27, Burleigh, Scott C (312B) wrote:
> Hi, Stephen.  I won't try to respond to all these points now, but I do 
> want to advance a little bit of an argument on your point (B).
> 
> transmitted over the wire, and everything to do with how the TCP state 
> machine is supposed to behave.

But 5681 is based on some decades of really widespread deployment.
If the BP were in that position I think you'd have a good argument there, but it isn't.

> impossible to test a router for correct operation.

I don't believe that an ability to test such correctness from outside a router is really necessary nor desirable at this point in the evolution of the BP.

> I understand that you disagree, but I don't yet understand why.

I guess I'll point at the examples I offered as to why. I look forward to seeing your (or others') responses to those examples.

I do hope we agree that egregious/unnecessary MUST statements are a bad idea though. If so, the question becomes whether or not all these many MUSTs are needed or not.

Cheers,
S.

>> to the list in addition to noting them on Ed's spreadsheet
>> Behalf Of Stephen Farrell Sent: Monday, January 23, 2017 7:33 PM
>> to not have a normative reference.
>> 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.
>> 
>> what potential countermeasures might apply?
>> 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 
> sites) and each by default will emit these reports then that'd be just 
> crazy as they could be per-hop and could bounce around all over the 
> place. At that scale there'd also no doubt be reports generating 
> I would be ok if someone wanted to try characterise the kind of DTN or 
> node(s) in which it'd be ok to have these turned on. That could of 
>> that discussion has to happen in this specification, nor that it has 
>> to happen before this specification is published.
> 
>> 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 
>> 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.
>> 
>> What'd be bad about losing that concept and letting (the determinants 
>> of) the MRG be unspecified here?
>> 
>> 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.
>> 
>> they're just not called by that term.  I think SHALL is correct here.
> 
> Disagree. A BPA might decide to send the bundle on an interface that's 
> broadcast in nature and not care who turns out to be the next hop that 
> e.g. accepts custody. I think the text reflects a quite narrow 
> conception of a CLA.
> 
>> 
>> Ought it re-transmit or consider that the custody ack for
>> 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.
>> 
> schemes (CGR and similar being an exception) figuring out the best way 
> to handle these timers will be intimately related to routing. See also 
> point (B) above:-)
> 
>> 
emes-1
>> records, if that's what you're implying. (I'm not
>> the word.  But I have no idea how to make this sentence any clearer. 
>> browser-related things in which whatwg have an interest.
>> 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.
>> 
>> 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.
>> 
>> in standard IETF process, but wants to read the specification anyway,

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 27 Mar 2017 22:19:04 +0100

On 27/03/17 22:15, Burleigh, Scott C (312B) wrote:
> Okay, if you believe that it is unnecessary to be able to test for
> the correct operation of a BP agent -- that is, an implementation of
> an Internet standards-track RFC -- then I think we may be at the root
> of the issue.  Let's continue tomorrow.

Sure. To clarify though: I don't believe one needs to be able to
verify a fully correct implementation of the BP purely from outside
the box. Mail MTAs for example don't have that property and I think
email RFCs are fairly good standards.

Cheers,
S.

> [mailto:[email-masked]] Sent: Monday, March 27, 2017 1:37
> But 5681 is based on some decades of really widespread deployment. If
> the BP were in that position I think you'd have a good argument
> there, but it isn't.
> 
>> I think this is true of virtually every MUST in the specification,
>> and I think that in the absence of this prescriptive language it
>> would be impossible to distinguish a correctly functioning router
>> from a broken one -- impossible to test a router for correct
>> operation.
> 
>> I think the prescriptive language in the BPbis specification is
>> just as necessary, for exactly the same reasons.
>> 
> I guess I'll point at the examples I offered as to why. I look
> forward to seeing your (or others') responses to those examples.
> 
>> [mailto:[email-masked]] Sent: Monday, March 20, 2017
>> 3:06 PM To: Burleigh, Scott C (312B)
>> <[email-masked]>; Marc Blanchet
>> <[email-masked]>; dtn <[email-masked]> Subject: Re: [dtn]
>> working group last call on draft-ietf-dtn-bpbis
>> 
>> 
>> Hi Scott,
>> 
>> As a TL;DR, I'd say we might be best to debate point (B) below,
>> that the current text is overly prescriptive. I'm entirely happy
>> that the DoS-vector that would be the current reporting text won't
>> make it to the RFC, so am ok if we don't spend so much time on
>> that.
>> 
>>> comments to the list in addition to noting them on Ed's
>>> spreadsheet - mainly transcribing them but amplifying in a few
>>> instances. In-line below.
>>> 
>>> Scott
>>> 
>>> -----Original Message----- 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]> Subject: Re:
>>> 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.
>>> 
>>>  there (I escape in March) so the fact that I would ballot
>>> DISCUSS is not that relevant to what other ADs might do.
>>> 
>>> 
>>> 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
>>> block types are not appropritate. (But those can likely be
>>> informative refs.)
>>> 
>>> 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.
>>> 
>>> -	I agree with making all status report generation "SHOULD"
>>> rather than "MUST".  But if it is possible to generate status
>>> reports (and I think it has to be, for network troubleshooting
>>> purposes) then it is always possible for a badly engineered
>>> implementation to generate them more frequently than might be
>>> optimal in a given network.  I'm unclear on how we can legislate
>>> against that.  Strong language warning the implementer of the
>>> possible dangers would be fine with me; is that enough?
>>> Something like "Implementations MUST limit the generation of
>>> status reports so as to prevent excessive network traffic.
>>> Strategies for limiting status report generation are beyond the
>>> scope of this specification."
>> 
>> web sites) and each by default will emit these reports then that'd
>> be just crazy as they could be per-hop and could bounce around all
>> over the place. At that scale there'd also no doubt be reports
>> generating reports (due to gatewaying even if that was disallowed
>> in the BP) and one would get explosions of reports. I think the
>> only defensible position is for *all* of these to be specified as
>> "MUST be off by default" to be acceptable for a proposed standard.
>> 
>> or node(s) in which it'd be ok to have these turned on. That could
>> of course be done in a separate document later. (Or outside the
>> IETF if it was e.g. really better a CCSDS thing.)
>> 
>>> 
>>>  better when they include all the meta-data that might be useful.
>>> If considered naively, that conflicts with modern approaches to
>>> 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.
>>> 
>>  scale. Note that I'm not arguing that the result has to be a BP
>> with fully understood and perfect privacy features.
>> 
>>> 
>>> (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.
>>> 
>>> 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?
>>> 
>> I don't get that. Given that we're not defining routing here,
>> aren't we in that position already? We can't for example tell if a
>> node emitting 10 copies of a bundle at different times, to
>> different next hops, on different interfaces etc. is good or bad or
>> not.
>> 
>>> 
>>> (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.
>>> 
>>> interop breaking change in the BP without discussing that topic.
>>> A reason to think about this is that there may be inter-VM (or 
>>> timing as interesting. It'd be a shame to make that impossible
>>> just to make it slightly simpler to represent time.
>>> 
>> That makes me a bit sad. If anyone else would like sub-second
>> timing maybe now'd not be too late if we ask nicely?
>> 
>>> 
>>> 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?
>>> 
>>> -	I agree with Ed on this.  There may be purposes for which a
>>> log of bundles may be needed; that's impossible if bundles are
>>> not uniquely identified.
>> 
>> I'd be a bit concerned that the MUST NOT is too hard to nodes
>> without good clocks and will just be ignored across reboots. If
>> other code elsewhere (e.g. log analysis) depended on a fiction from
>> here that'd not be great.
>> 
>>> 
>>> (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.
>>> 
>>> -	Sure.
>>> 
>>> (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.
>>> 
>>> 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.
>>> 
>>> other opportunistic CLA? Or a sneakernet where nobody knows
>>> who'll be next hop.
>>> 
>>> bundle to.  What else is going to make that determination?
>>> Nothing in the spec says it has to make that determination right
>>> now; maybe it sets the bundle aside for a while until a data mule
>>> comes along - and then it determines that this data mule is one
>>> of the nodes to forward the bundle to.  The text is correct.
>> 
>>> (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.
>>> 
>>> -	I disagree.
>> 
>>> (19) I think some rules related to custody and fragmentation may
>>> be missing. For example, if bundle A is multicast and reaches two
>>> 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
>>> -	I don't think there is a problem.  Custody transfer is
>>> undefined if the destination endpoint is not singleton.
>> 
>>> 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.
>>> 
>> way to handle these timers will be intimately related to routing.
>> See also point (B) above:-)
>> 
>>> 
>>> 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],
>>> https://www.iana.org/assignments/uri-schemes/uri-schemes.xhtml#uri-sc
>>>
>>> 
h
>>> appropriate in the first couple of paras. It should be entirely
>>> ok to say "we've learned stuff and fixed stuff."
>>> 
>>> -	Sure, whatever.
>>> 
>>> - intro: "Custodial forwarding" is too terse at this point but
>>> also hard to explain briefly, is really a mechanism and not a
>>> reference isn't wise (particularly at the moment when we're
>>> seeing SERVFAIL from the relevant NS;-)
>>> 
>>> -	Sure.
>>> 
>>>  useful here, though I've not checked if it touches on enough of
>>> the issues behind the differences between 5050 and this.
>>> 
>>> - 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;-)
>>> 
>>> 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.
>>> 
>>> -	I disagree.  The application agent -- not the application --
>>> is the thing that has an administrative element.  We could say
>>> that a given BPA's application agent might lack an administrative
>>> element, in which case the node could not take custody of a
>>> bundle.  I don't see much advantage in that, but I don't mind
>>> saying it.
>>> 
>>> - 3.1, singleton: not sure if it's clear enough that all
>>> endpoints are sets, so this may puzzle folks. Maybe add e.g.
>>> -	Nothing says how long "sustained" is, but okay, we could
>>> delete the word.  But I have no idea how to make this sentence
>>> any clearer. There is exactly one possible antecedent for "that
>>> node".
>>> 
>>> - 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;-)
>>> 
>>> -	Let's add a general statement, somewhere, to the effect that
>>> the bundle protocol agent MAY discard any malformed bundle it
>>> receives.
>>> 
>>>  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.
>>> 
>>> the whatwg web page that has sometimes claimed to supercede 3986
>>> for the browser-related things in which whatwg have an interest. 
>>> - 4.1.5.2: Danger, metaphysics! "Every node MUST be a member of
>>> at least one singleton endpoint." This entire section is
>>> - 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.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?
>>> 
>>> -	I don't see what harm this does.  For someone who is not
>>> steeped in standard IETF process, but wants to read the
>>> specification anyway, maybe it would be useful information.
>>> 
>>> - 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
>>> -	All of the retention constraint stuff is explained in detail.
>>> I think it's necessary in order to ensure coherent behavior among
>>> the nodes of the network.
>> 
>> See point (B) above:-)
>> 
>>> 
>>> - 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.
>>> 
>>> very clearly in the scope of the operation of the CLA, which is
>>> BP code. If that happens to be embedded in a NIC, fine, but
>>> that's not relevant.
>>> 
>>> 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.
>>> 
>>> -	Here again I think the normative language is necessary in
>>> -	I disagree, again because the normative language is necessary
>>> in order to ensure coherent behavior among the nodes of the
>>> network.
>>> 
>> 
>> See point (B) above.
>> 
>>> non-destination node. It'd be better to warn about that. And
>>> maybe change from MAY for in-path reassembly to SHOULD NOT.
>>>

---

From: "Burleigh, Scott C (312B)" <[email-masked]>
Date: Mon, 27 Mar 2017 21:21:33 +0000

Fair enough.  I am happy to leave this up to the wisdom of the WG.

Scott

-----Original Message-----
From: Stephen Farrell [mailto:[email-masked]] 
Sent: Monday, March 27, 2017 2:19 PM
To: Burleigh, Scott C (312B) <[email-masked]>; Marc Blanchet <[email-masked]>; dtn <[email-masked]>
Subject: Re: [dtn] working group last call on draft-ietf-dtn-bpbis

On 27/03/17 22:15, Burleigh, Scott C (312B) wrote:
> Okay, if you believe that it is unnecessary to be able to test for the 
> correct operation of a BP agent -- that is, an implementation of an 
> Internet standards-track RFC -- then I think we may be at the root of 
> the issue.  Let's continue tomorrow.

Sure. To clarify though: I don't believe one needs to be able to verify a fully correct implementation of the BP purely from outside the box. Mail MTAs for example don't have that property and I think email RFCs are fairly good standards.

Cheers,
S.

> the BP were in that position I think you'd have a good argument there, 
> but it isn't.
> 
>>> On Behalf Of Stephen Farrell Sent:
>>> 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.)
>>> 
>>> MUST in step 4 and all the rest are bogus and a bad plan.
>>> 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 
>>> 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.
>>> 
>>> Something like "Implementations MUST limit the generation of status 
>>> reports so as to prevent excessive network traffic.
>>> 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 
>>> of a person? I don't recall we've ever really discussed such issues.
>>> 
>>> 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 
>>> them all and with custody and less frequent application layer 
>>> breaking change in the BP without discussing that topic.
>>> log of bundles may be needed; that's impossible if bundles are not 
>>> uniquely identified.
>> 
>>> might be to weaken the language here and to see what implementations 
>>> do in the real world.
>>> 
>>> -	Sure.
>>> 
>>> 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.
>>> 
>>> comes along - and then it determines that this data mule is one of 
>>> the nodes to forward the bundle to.  The text is correct.
>> 
>>> I don't think such GOTOs are a good idea really.  I suggest removing 
>>> lots of this and adding in some informative (i.e.
>>> 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.
>>> 
>>> 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.
>>> 
>>> 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.)
>>> 
h
>>> not interoperable with 5050. That's not a bad thing, but worth 
>>> noting here.
>>> 
>>> 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" 
>>> 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.
>>> is the thing that has an administrative element.  We could say that 
>>> a given BPA's application agent might lack an administrative 
>>> element, in which case the node could not take custody of a bundle.  
>>> I don't see much advantage in that, but I don't mind saying it.
>>> 
>>> are sets, so this may puzzle folks. Maybe add e.g.
>>> delete the word.  But I have no idea how to make this sentence any 
>>> applies for all MUSTs stated only in terms of what the encoding must 
>>> match.
>>> 
>>> 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.
>>> 
>>> 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.
>>> 
>>> whatwg web page that has sometimes claimed to supercede 3986 for the 
>>> 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.
>>> 
>>> as it seems to require BP code inside a NIC which is not how this'll 
>>> usually be implemented.
>>> 
>>> 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.
>>> 
>>> in order to ensure coherent behavior among the nodes of the network.
>>> 
>> 
>> See point (B) above.
>>

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 27 Mar 2017 22:23:36 +0100

> Fair enough.  I am happy to leave this up to the wisdom of the WG.

As will I, after we've considered the examples given in the
review (which we have yet to do). I don't think it'd be a
good plan at all for the WG to conclude that all the prescriptive
text is ok without considering at least the issues raised as
examples.

S.