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

[Stephen Farrell <[e-mail]>]

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

> 
> Scott
> 
> -----Original Message-----
> From: Stephen Farrell [mailto:[e-mail]] 
> Sent: Monday, March 27, 2017 2:19 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
> 
> 
> 
> 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-s
>>>> c
>>>>
>>>>
> 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
>>
>>
> 
> _______________________________________________
> dtn mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dtn
> 
>