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

[Stephen Farrell <[e-mail]>]

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.

> 
> Scott
> 
> -----Original Message----- From: Stephen Farrell
> [mailto:[e-mail]] Sent: Monday, March 27, 2017 1:37
> PM To: Burleigh, Scott C (312B) <[e-mail]>; Marc
> Blanchet <[e-mail]>; dtn <[e-mail]> 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).
>> 
>> 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 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.
> 
>> 
>> Scott
>> 
>> -----Original Message----- From: Stephen Farrell 
>> [mailto:[e-mail]] Sent: Monday, March 20, 2017
>> 3:06 PM To: Burleigh, Scott C (312B)
>> <[e-mail]>; Marc Blanchet
>> <[e-mail]>; dtn <[e-mail]> 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:
>>> 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:[e-mail]] On Behalf Of Stephen Farrell Sent:
>>> Monday, January 23, 2017 7:33 PM To: Marc Blanchet
>>> <[e-mail]>; dtn <[e-mail]> 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.
>> 
>> 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.)
>> 
>>> 
>>> 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.
>> 
>> 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.
>>> 
>>> -	The spec doesn't define "success" at all, and I don't know why 
>>> it would need to.
>> 
>> 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 think that would make the behavior of nodes so indeterminate 
>>> that it can't be tested.
>> 
>> 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.
>>> 
>>> -	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.
>> 
>> 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.
>>> 
>>> -	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.
>> 
>> 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?
>>> 
>>> -	You are wrong in reading this section as precluding deferred 
>>> transmission.
>> 
>> Maybe it needs rewording then. (Happy to look over it with you 
>> later.)
>> 
>>> 
>>> (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.
>> 
>> 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.
>>> 
>>> -	Custodial retransmission really has nothing to do with
>>> routing.
>> 
>> 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.)
>>> 
>>> -	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-sc
>>>
>>> 
h
>>> 
>>> 
> emes-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.
>> 
>> 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.
>>> 
>>> -	I disagree.  The section is exactly enough-thought.
>> 
>> See point (B) above:-) And "exactly"? :-)
>> 
>>> 
>>> - 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.
>> 
>> 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.
>> 
>>> 
>>> - 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.
>>> 
>> 
>> See point (B) above.
>> 
>>> - 5.6, step 4: I wonder if an implementer will get all this
>>> right.
>>> 
>>> -	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.
>>> 
>>> -	I am doubtful that this specification should be a compendium of
>>>  implementation tips.
>> 
>> s/MAY/SHOULD NOT/ is way more than a tip
>> 
>>> 
>>> - 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.
>>> 
>>> 
>>> 
>> 
>> _______________________________________________ dtn mailing list 
>> [e-mail] https://www.ietf.org/mailman/listinfo/dtn
>> 
> 
> _______________________________________________ dtn mailing list 
> [e-mail] https://www.ietf.org/mailman/listinfo/dtn
> 
>