Re: [dtn] working group last call on draft-ietf-dtn-bpbis
"Burleigh, Scott C (312B)" <scott.c.burleigh@jpl.nasa.gov> Mon, 27 March 2017 21:15 UTC
Return-Path: <scott.c.burleigh@jpl.nasa.gov>
X-Original-To: dtn@ietfa.amsl.com
Delivered-To: dtn@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F259127076 for <dtn@ietfa.amsl.com>; Mon, 27 Mar 2017 14:15:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level:
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id opyh1MNaNvuZ for <dtn@ietfa.amsl.com>; Mon, 27 Mar 2017 14:15:50 -0700 (PDT)
Received: from mail.jpl.nasa.gov (mailhost.jpl.nasa.gov [128.149.139.105]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1AB00126DEE for <dtn@ietf.org>; Mon, 27 Mar 2017 14:15:50 -0700 (PDT)
Received: from mail.jpl.nasa.gov (ap-ehub-sp01.jpl.nasa.gov [128.149.137.148]) by smtp.jpl.nasa.gov (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id v2RLFh5m016444 (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256 bits) verified NO); Mon, 27 Mar 2017 14:15:44 -0700
Received: from AP-EMBX-SP10.RES.AD.JPL ([169.254.1.166]) by ap-ehub-sp01.RES.AD.JPL ([169.254.3.42]) with mapi id 14.03.0319.002; Mon, 27 Mar 2017 14:15:43 -0700
From: "Burleigh, Scott C (312B)" <scott.c.burleigh@jpl.nasa.gov>
To: Stephen Farrell <stephen.farrell@cs.tcd.ie>, Marc Blanchet <marc.blanchet@viagenie.ca>, dtn <dtn@ietf.org>
Thread-Topic: [dtn] working group last call on draft-ietf-dtn-bpbis
Thread-Index: AQHSaCGmzxdqqnp0pkKUzwuCATCJUKFHmv0AgE3sPKCACapDgIAKaq5ggAB8noD//5S1oA==
Date: Mon, 27 Mar 2017 21:15:43 +0000
Message-ID: <A5BEAD028815CB40A32A5669CF737C3B8A3CAF31@ap-embx-sp10.RES.AD.JPL>
References: <44B4919D-4283-4FDD-91E5-1EE5288D50AC@viagenie.ca> <b573e87b-e62b-56b6-7b89-6bcbde86dd82@cs.tcd.ie> <A5BEAD028815CB40A32A5669CF737C3B8A3B72CB@ap-embx-sp10.RES.AD.JPL> <dcb5c9ad-3ba9-3ecd-668e-6ea28bda8487@cs.tcd.ie> <A5BEAD028815CB40A32A5669CF737C3B8A3C8E47@ap-embx-sp10.RES.AD.JPL> <ac0a9eb6-5aa9-bd7c-e8fa-d79ba39e622b@cs.tcd.ie>
In-Reply-To: <ac0a9eb6-5aa9-bd7c-e8fa-d79ba39e622b@cs.tcd.ie>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [128.149.137.26]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-Source-Sender: scott.c.burleigh@jpl.nasa.gov
X-AUTH: Authorized
Archived-At: <https://mailarchive.ietf.org/arch/msg/dtn/lTyJJduI3Px6fJOsoCHzFW_Pqmo>
Subject: Re: [dtn] working group last call on draft-ietf-dtn-bpbis
X-BeenThere: dtn@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "Delay Tolerant Networking \(DTN\) discussion list at the IETF." <dtn.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dtn>, <mailto:dtn-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dtn/>
List-Post: <mailto:dtn@ietf.org>
List-Help: <mailto:dtn-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dtn>, <mailto:dtn-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 27 Mar 2017 21:15:56 -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:stephen.farrell@cs.tcd.ie] Sent: Monday, March 27, 2017 1:37 PM To: Burleigh, Scott C (312B) <scott.c.burleigh@jpl.nasa.gov>; Marc Blanchet <marc.blanchet@viagenie.ca>; dtn <dtn@ietf.org> 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:stephen.farrell@cs.tcd.ie] Sent: Monday, March 20, 2017 3:06 > PM To: Burleigh, Scott C (312B) <scott.c.burleigh@jpl.nasa.gov>; Marc > Blanchet <marc.blanchet@viagenie.ca>; dtn <dtn@ietf.org> 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:dtn-bounces@ietf.org] On >> Behalf Of Stephen Farrell Sent: Monday, January 23, 2017 7:33 PM >> To: Marc Blanchet <marc.blanchet@viagenie.ca>; dtn <dtn@ietf.org> >> 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 > dtn@ietf.org https://www.ietf.org/mailman/listinfo/dtn >
- [dtn] working group last call on draft-ietf-dtn-b… Marc Blanchet
- Re: [dtn] working group last call on draft-ietf-d… Marc Blanchet
- Re: [dtn] working group last call on draft-ietf-d… Templin, Fred L
- Re: [dtn] working group last call on draft-ietf-d… Burleigh, Scott C (312B)
- Re: [dtn] working group last call on draft-ietf-d… Brian Sipos
- Re: [dtn] working group last call on draft-ietf-d… Stephen Farrell
- Re: [dtn] working group last call on draft-ietf-d… Templin, Fred L
- Re: [dtn] working group last call on draft-ietf-d… Stephen Farrell
- Re: [dtn] working group last call on draft-ietf-d… Spencer Dawkins at IETF
- Re: [dtn] working group last call on draft-ietf-d… I-Viswanathan, Kapaleeswaran
- Re: [dtn] working group last call on draft-ietf-d… Birrane, Edward J.
- Re: [dtn] working group last call on draft-ietf-d… Stephen Farrell
- Re: [dtn] working group last call on draft-ietf-d… Rick Taylor
- Re: [dtn] working group last call on draft-ietf-d… Templin, Fred L
- Re: [dtn] working group last call on draft-ietf-d… Rick Taylor
- Re: [dtn] working group last call on draft-ietf-d… Lucas Kahlert
- Re: [dtn] working group last call on draft-ietf-d… Burleigh, Scott C (312B)
- Re: [dtn] working group last call on draft-ietf-d… Stephen Farrell
- Re: [dtn] working group last call on draft-ietf-d… Carsten Bormann
- Re: [dtn] working group last call on draft-ietf-d… Stephen Farrell
- Re: [dtn] working group last call on draft-ietf-d… Stephen Farrell
- Re: [dtn] working group last call on draft-ietf-d… Burleigh, Scott C (312B)
- Re: [dtn] working group last call on draft-ietf-d… Stephen Farrell
- Re: [dtn] working group last call on draft-ietf-d… Burleigh, Scott C (312B)
- Re: [dtn] working group last call on draft-ietf-d… Stephen Farrell
- Re: [dtn] working group last call on draft-ietf-d… Burleigh, Scott C (312B)
- Re: [dtn] working group last call on draft-ietf-d… Stephen Farrell