Re: [dtn] working group last call on draft-ietf-dtn-bpbis
"Templin, Fred L" <Fred.L.Templin@boeing.com> Tue, 24 January 2017 19:02 UTC
Return-Path: <Fred.L.Templin@boeing.com>
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 909731295CE for <dtn@ietfa.amsl.com>; Tue, 24 Jan 2017 11:02:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.221
X-Spam-Level:
X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-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 wiMR3ny8aqap for <dtn@ietfa.amsl.com>; Tue, 24 Jan 2017 11:02:40 -0800 (PST)
Received: from phx-mbsout-01.mbs.boeing.net (phx-mbsout-01.mbs.boeing.net [130.76.184.178]) (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 42D73129557 for <dtn@ietf.org>; Tue, 24 Jan 2017 11:02:39 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by phx-mbsout-01.mbs.boeing.net (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id v0OJ2d1U050664; Tue, 24 Jan 2017 12:02:39 -0700
Received: from XCH15-06-12.nw.nos.boeing.com (xch15-06-12.nw.nos.boeing.com [137.136.239.221]) by phx-mbsout-01.mbs.boeing.net (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id v0OJ2Snp050588 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=OK); Tue, 24 Jan 2017 12:02:29 -0700
Received: from XCH15-06-08.nw.nos.boeing.com (2002:8988:eede::8988:eede) by XCH15-06-12.nw.nos.boeing.com (2002:8988:efdd::8988:efdd) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Tue, 24 Jan 2017 11:02:27 -0800
Received: from XCH15-06-08.nw.nos.boeing.com ([137.136.238.222]) by XCH15-06-08.nw.nos.boeing.com ([137.136.238.222]) with mapi id 15.00.1178.000; Tue, 24 Jan 2017 11:02:27 -0800
From: "Templin, Fred L" <Fred.L.Templin@boeing.com>
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: AQHSdfKpurkHSWBLN0O2diFxKi+UaKFH+7VA
Date: Tue, 24 Jan 2017 19:02:27 +0000
Message-ID: <7a143c37a178456a977662113a4ca13a@XCH15-06-08.nw.nos.boeing.com>
References: <44B4919D-4283-4FDD-91E5-1EE5288D50AC@viagenie.ca> <b573e87b-e62b-56b6-7b89-6bcbde86dd82@cs.tcd.ie>
In-Reply-To: <b573e87b-e62b-56b6-7b89-6bcbde86dd82@cs.tcd.ie>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [137.136.248.6]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-TM-AS-MML: disable
Archived-At: <https://mailarchive.ietf.org/arch/msg/dtn/B7sRt55BGTE0gLMVlqoaEjmlI1U>
Subject: Re: [dtn] working group last call on draft-ietf-dtn-bpbis
X-BeenThere: dtn@ietf.org
X-Mailman-Version: 2.1.17
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: Tue, 24 Jan 2017 19:02:44 -0000
Hi Stephen, I am still going through your comments, but one question that I have on one of your points for now: "4) it's not ok to omit security mechanism definition, (making [BPSEC] normative and waiting on that in the RFC editor queue would fix this, and is IMO needed), Wouldn't that create a circular dependency? If not, what do you see as a way forward that would not entail a prolonged blockage in the RFC editor queue? Thanks - Fred fred.l.templin@boeing.com > -----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.) > > (B) The spec is overly prescriptive in many places and ought be > loosened up wherever possible. All we need is interop and not > the kind of conformance at which this spec seems to aim (but > maybe miss). For exmple the "retention constraint" stuff has > absoluely no reason to be a MUST. As another, I think section > 5.4 only needs a MUST in step 4 and all the rest are bogus and > a bad plan. Also in 3.1, the text here is often far too > prescritpive and I suspect based on only a couple of > implementation strategies. There are many more examples. I > think it'd be a good plan to do an editing pass to get rid of > as many of the extraneous and unnecessary constraints that are > here. Examples feature in other comments, but I've not tried > to be exhaustive in spotting all instances of this. > > (C) Many of the flags relaed to reporting provide ways in which > the BP, if it became widely deployed (even if not planned to be > widely used), could be a significant (D)DoS accelerator. Has > anyone figured out the scale factors involved, (e.g. if N bogus > blocks say report if this can't be processed) whether those > might be significant and if so what potential countermeasures > might apply? Absent such an analysis, or fixing the problem, > I'd argue it'd seem irresponsible to standardise the BP. I'd > say for a PS, the minimum is that BPAs MUST default to not > sending all these new bundles except when specifically > configured to be so verbose. This also affects 5.1 and maybe > elsewhere which says an agent MUST emit admin bundles if asked. > In 5.6, step 2: again the SHOULD needs to be qualified in order > to not have the BP be a fine DoS accelerator (given > non-singletons). Step 3's SHOULD for this is even worse as a > bad actor could include many such blocks. In 5.13 - I think > that is too many custody signals. If one envisages DTNs with > custodians located at links that are particularly subject to > disruption, then those may be few in number and having all > other nodes/routers emit custody signals for each bundle not > taken into custody seems hugely inefficient and unnecessary. > There may be more examples. FWIW, my guess is that if all the > current reporting is kept, then the IESG will require some kind > of applicability statement about the kind of network in which > the BP can safely be deployed. For me, fixing the problem is a > better approach than constraining it via an applicability > statement. > > A bit less major (maybe not DISCUSS-worthy) > ------------------------------------------- > > (1) 3.1's definition of a bundle correctly says that bundles > are better when they include all the meta-data that might be > useful. If considered naively, that conflicts with modern > approaches to privacy where we want to ensure that meta-data is > only seen by those (nodes) that need to see meta-data, as one > form of data minimisation. OTOH, one could argue that such > bundles will ensure that meta-data and payloads enjoy the same > security services, which is a good thing. In any case, I think > it'd be useful to have a discussion about the privacy aspects > of the BP, esp the ways in which those may be different from > other protocols. For example, would we expect report-to URIs to > commonly allow re-identification of a person? I don't recall > we've ever really discussed such issues. > > (2) 3.1, destination: I think this ought be clear that delivery > to some node in the endpoint represents success, i.e. that the > BP does not force successful delivery to all or failure as a > binary choice. > > (3) What bad things would follow if 3.2 was deleted? It may be > that I'm too familiar with DTN (and hence not a good judge if > this section is useful or not) but I didn't find it useful. > Also - is 3.2 normative? If not, I'm even happier to see it go. > If it is, then I gotta wonder if it conflicts with other text > later. And I see there are a few 2119 MUSTs in there so I guess > you do mean it to be normative or did they sneak in in by > accident whilst editing? (As can happen.) If not deleting this > section, I'd argue to find all the bits of text in it that are > needed and move them all elsewhere and then delete the section. > > (4) 3.2: The idea that the EID fully determines the MRG seems > just wrong to me. While that might be a nice theory, I figure > it's way more likely that the routing scheme determines how > many copies of a bundle are rx'd at how many instances of the > destination EID. What'd be bad about losing that concept and > letting (the determinants of) the MRG be unspecified here? > > (5) 3.2, "Custody of a bundle MAY be taken only if the > destination of the bundle is a singleton endpoint." That's > plain wrong. Not all custodians can know about the desitnation > being a singleton or not. And before you say it, I don't > believe in the flag in 4.1.3 that allows an origin to specify > this - I've never seen a real example of when that's useful - > the only nearby case I recall was where the developer (me:-) > knew we wanted distibution to all nodes in a multi-member > endpoint but with best effort in terms of getting to them all > and with custody and less frequent application layer re-tx's to > ensure we got to as many as possible. This also affects 5.2. > > (6) 3.3, I'm not sure this is useful either. What'd break if it > were deleted? (But then I never liked those bits of DTNRG's > work either;-) > > (7) Including some examples and an RFC 7942 implementation > status section would be a good thing, if easily done. That > would help progression and increase confidence in the > correctness of the spec. > > (8) 4.1.6: Was sub-second timing discussed by the WG? I'm not > terribly pushed on that myself, but it'd be a shame to do an > interop breaking change in the BP without discussing that > topic. A reason to think about this is that there may be > inter-VM (or intra-data-centre) reasons to consider the BP with > sub-second timing as interesting. It'd be a shame to make that > impossible just to make it slightly simpler to represent time. > > (9) 4.2.2, creation time rules: I don't see why it'd be a > problem if node-id=X, creation-time=0,counter=0,lifetime=2s is > used in two bundles emitted 3 seconds apart. Why does that > justify a MUST NOT in the spec? > > (10) 4.2.2: The "30 seconds" rule also seems wrong to me, as is > the "MUST NEVER" (not a 2119 term btw) for re-use of the seq > no, which is unrealistic. As an example of that last: what do > you expect to happen with a node that usually knows the wall > clock time, but, at this moment, knows that it does not? E.g. > previous logs have some real dates, but current clock is > 1970-01-01 or whatever. I think this is fixable but the current > language is too prescriptive. Best might be to weaken the > language here and to see what implementations do in the real > world. > > (11) 4.3.1: Is the SHALL here right? I would have thought a > SHOULD is better to allow for legacy interop with 5050 via > gateways, in which case there may be no node ID. That might be > better off handled in some generic fashion though, and not > piecemeal with each mention of node ID. > > (12) 4.3.2: I don't believe it is correct to drop a bundle due > to the lack of a previous node block, which is what sems to be > implied here. Not all routing schemes need this and so it ought > not be a MUST. Maybe a SHOULD is enough, but even if you say > "MUST insert this" then I would like to argue that "receivers > can decide to not care" be stated explicitly e.g. by saying > that bundles MUST NOT be rejected solely due to the lack of > this EB. > > (13) I'm not sure if you have all the right "watch out for the > null EID node ID" text needed. (I didn't go back over > everything, but it'd seem wrong e.g. in an current custodian > AR. > > (14) 5.4: "The bundle protocol agent MUST determine which > node(s) to forward the bundle to." That's ungrammatical and > close to BS - what if I want to multicast or broadcast the > bundle or use some other opportunistic CLA? Or a sneakernet > where nobody knows who'll be next hop. > > (15) 5.4: The text about the flow label should be deleted as it > says nothing. If includng this, then the flow label spec may > need to be a normative ref (arguably). > > (16) 5.4 - I think this is badly misleading. There will be many > cases where a bundle cannot be forwarded now but may be > forwarded later. Am I wrong in reading this section as > precluding that? > > (17) 5.6, step 4 says one MUST handle "custody transfer > redundancy" but that term seems undefined. > > (18) 5.6 (step 5) points back to 5.3 which points to 5.7 or > 5.4. I don't think such GOTOs are a good idea really. I > suggest removing lots of this and adding in some informative > (i.e. non-normative) pseudo code (or real code) as an appendix. > > (19) I think some rules related to custody and fragmentation > may be missing. For example, if bundle A is multicast and > reaches two nodes on different paths who take custody > (custodians C1/C2) and who both fragment but differently (into > F11/F12 and F21/F22 resp) with eventually a custody ack for F21 > reaching C1. Assume F21 is longer than F11, what is C1 to do > with F11 when a custody timer expires? Ought it re-transmit or > consider that the custody ack for F21 matched F11 sufficiently > well? I'm not sure what'd be right here, if such cases can > happen. I'd be fine with the spec admitting that some such > corner cases exist, or maybe it's easy enough to figure out, > not sure. > > (20) 5.10.1, I've always wondered why custody timer expiry is > covered here, and not really considered a part of DTN routing. > It seems to me to make more sense to couple custody timing and > routing. If that resonated with folks, I think the change would > be to make the timer-related text here into an illustrative > example and to say that such things are better considered > together with routing and/or by chunks of code that are > somewhat more topology/disruption-aware of the situation in the > particular DTN. > > (21) section 9 seems woefully incomplete - why is it ok to say > "will be required" at WGLC? Surely the WG should at least have > discussed the set of registries needed and the registration > rules for those? E.g. do we sill want CCSDS to be able to add > entries to some of those registries as we did with 5050? And > has the WG considered how do all the things in this draft > relate to the set of IANA registries related to the BP? [1,2] > (In the case of [3], section 4.1.5.1 really probably does need > to say something.) > > [1] https://www.iana.org/assignments/bundle/bundle.xhtml > [2] > https://www.iana.org/assignments/uri-schemes/uri-schemes.xhtml#uri-schemes-1 > > Seemingly more minor or nitty things > ------------------------------------ > > - abstract: "This Internet Draft" is no longer appropriate > language. > > - abstract: I think this ought capture the fact that this > version is not interoperable with 5050. That's not a bad thing, > but worth noting here. > > - intro: I don't think the "sales" language is needed or > appropriate in the first couple of paras. It should be entirely > ok to say "we've learned stuff and fixed stuff." > > - intro: "Custodial forwarding" is too terse at this point but > also hard to explain briefly, is really a mechanism and not a > capabililty, and maybe not such a highlight, so I'd delete that > bullet > > - intro: "[TUT]" is quite outdated and using dtnrg.org for the > reference isn't wise (particularly at the moment when we're > seeing SERVFAIL from the relevant NS;-) > > - intro: this is a bit self-serving, but maybe a reference to > the architectural retrospective [3] that Kevin and I wrote > might be useful here, though I've not checked if it touches on > enough of the issues behind the differences between 5050 and > this. > > [3] https://ieeexplore.ieee.org/document/4530739 > > - Figure 1: I wonder if it'd be worth pointing out that the BP > does not have to run over a layer 4 that runs over a layer 3 > etc. The figure and this text does give that impression that a > "proper" transport is needed, which isn't the case. > (Tactically, I'm not sure if the text as-is, or something more > correct, would make getting a new RFC easier or harder - I > guess it'll depend on the reader;-) > > - Figure 2: Few if any of the applications I've used with the > BP had an administrative element. That's maybe down to the > experimental nature of the work we've done but I don't think > it's correct to imply that all applications using the BP need > to be able to handle admin records, if that's what you're > implying. (I'm not sure.) I'd say indicating that that's an > optional thing would be right. > > - 3.1, singleton: not sure if it's clear enough that all > endpoints are sets, so this may puzzle folks. Maybe add e.g. > "remember that endpoints are sets," not sure. > > - 3.1, forwarding: the text is odd - "sustained effort" is not > mandatory, and what "that node" is meant here? > > - 4: The first two SHALL statements are odd in that there's no > way in which one could implement this spec and not conform to > those I think. In cases like that it's fine to avoid 2119 > language. Not a big deal though, as the current IESG don't get > anal about that, though some ADs in the past have done;-) > > - 4: last item MUST be break stop code. Is a decoder supposed > to barf a bundle if this is not true? More generally, same > question applies for all MUSTs stated only in terms of what the > encoding must match. > > - 4.1.1: why >1 CRC type? That seems bogus. None or strong > seems better to me. (And I'd go for a crypto hash for strong.) > I assume the WG discussed this and found that there are real > use-cases for each of those specified. While those don't need > to be in the spec, can someone tell me what they are as I'm not > at all sure, e.g. why a 16 bit CRC is useful as an option. > > - 4.1.3: "enables anonymous bundle transmission" - that's > overstated, chances are that something in the CLA will be > identifying, or allow re-identification, so I think what you > want to say is that omitting the source EID helps with, but > does not ensure, nymity. > > - 4.1.5.1: RFC3986 is the correct reference here, so the spec > text is correct as-is. It may however be worth taking a look at > the whatwg web page that has sometimes claimed to supercede > 3986 for the browser-related things in which whatwg have an > interest. That's just in case there're some useful error > handling considerations on the whatwg web page, (on the day you > look at it;-). It's also the case that since BP EIDs are URIs, > it's possible that strings that comply with today's or > yesterday's whatwg web page may end up in the BP, so it'd be > good to know if any of those (that are not valid according to > 3986) might cause a problem with the CBOR encoding. > > - 4.1.5.2: Danger, metaphysics! "Every node MUST be a member of > at least one singleton endpoint." This entire section is > over-thought. I think all you need to say is that nodes the > emit bundles need to have an EID they can use as a source EID > for as long as necessary. > > - 4.2.1: this entire section is duplicative. That's a bad idea. > > - 4.2.2: 2nd para is badly written - that'd encourage coders to > use the values 8,9,10 and 11 in ways that might be unwise. > > - 4.2.2: wrt "anonymous" see earlier comment > > - 4.2.2: description of creation time is duplicative, except > the earlier text didn't cover relative time. > > - 4.3.3: Is "Bundle Age Block" a good name? BAB used to mean > another type of block, so that could confuse maybe. (That said, > I forget how long we're had this name.) > > - 4.3.4: Do you need to say that the hop limit MUST NOT be > changed, once a hop count EB is added. Also, can any node add > one of these, if one was not prevsiously present? > > - 5: It's not necessary to say that new RFCs can supercede > this. That's just standard IEFF process. > > - 5.2: mentions "dispatch pending" as if I should know what > that is - is all the retention constraint stuff sufficiently > explained I wonder? (Personally I don't think you need to > mandate all this stuff and you cannot tell if an implementation > has done it or not so I'd not bother trying to be so > prescriptive.) > > - 5.4: "at the last possible moment... MUST..." that's a bit > silly as it seems to require BP code inside a NIC which is not > how this'll usually be implemented. > > - 5.5: I'm not convinced that the MUSTs here are right for all > DTNs. I reckon that 5.5 could just as well say "MAY delete" and > the BP would be fine. That might also provide some additional > flexibility for some rounting schemes. That said, I won't press > on this - if this doesn't resonate with folks now, and later > turns out to be useful, I don't think we'd have such a hard > time modifying BPAs where needed. > > - 5.6: Again, this is overly prescriptive. > > - 5.6, step 4: I wonder if an implementer will get all this > right. > > - 5.9: Badly implemented, re-assembly can create a memory > consumption DoS vector, perhaps esp. if attempted on a > non-destination node. It'd be better to warn about that. And > maybe change from MAY for in-path reassembly to SHOULD NOT. > > - 5.11: does this mean that a custodian MUST ignore a custody > signal destined for some other custodian? > > - Figure 6: I don't get when reason codes 5 to 8 would really > be used. Are they in fact needed? (They seem a bit > implementation specific to me, but I've not gone looking.) > > - section 8: First sentence is bogus. > > - section 8: [SECO] isn't a good reference. It's outdated and I > doubt will be picked up. > >
- [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