Re: [dtn] [EXTERNAL] Re: AD evaluation of draft-ietf-dtn-bpbis-13

["Burleigh, Scott C (312B)" <[e-mail]>]

Toward reaching that consensus: my own opinion from reading USPTO #7930379 is that Intel seems to have patented TierStore and named it "delay tolerant networking."  I would think that the IEEE Communications article on DTN published in June 2003 is prior art that invalidates the patent, since the patent is dated 30 March 2007, but I am no lawyer.  The earliest published paper I can find on TierStore is dated January 2008, so maybe a patent that limits its claims to what TierStore does can be defended, but the DTN architecture goes far beyond TierStore.

Scott

-----Original Message-----
From: dtn <[e-mail]> On Behalf Of R. Atkinson
Sent: Monday, July 15, 2019 8:11 AM
To: DTN WG <[e-mail]>
Subject: [EXTERNAL] Re: [dtn] AD evaluation of draft-ietf-dtn-bpbis-13

Fred,

Kevin Fall’s note of June 17th means that the WG needs to consider the question of whether it wants to standardize these documents despite the existence of a (possibly related or possibly not related) IPR claim (reportedly USPTO # 7,930,379).

I have not read that USPTO filing.  So I take no position on whether that IPR claim is applicable to DTN or even whether it is a valid claim.

Regardless, from an IETF process perspective, the WG needs to make an explicit decision on whether to proceed with standardization given the existence of USPTO 7,930,379.

I noted this process issue earlier on-list, but I haven’t seen any discussion and I haven’t seen the WG Chairs pose the question.  

Is perhaps the plan to discuss this next week in person and then confirm the in-person consensus (whatever that might be) on the mailing list afterwards ? :-)

Cheers,

Ran

> On Jul 15, 2019, at 08:48, Magnus Westerlund <[e-mail]> wrote:
> 
> On Sat, 2019-07-13 at 00:29 +0000, Templin (US), Fred L wrote:
>> HI Magnus,
>> 
>>> -----Original Message-----
>>> From: dtn [mailto:[e-mail]] On Behalf Of Magnus 
>>> Westerlund
>>> Sent: Monday, July 08, 2019 12:05 AM
>>> To: [e-mail]; [e-mail]
>>> Subject: Re: [dtn] AD evaluation of draft-ietf-dtn-bpbis-13
>>> 
>>> WG,
>>> 
>>> 
>>> To clarify, I will not progress this document until the WG has 
>>> established a consensus on what to do, if any, about the IPR.
>> 
>> Thank you for your review efforts. Regarding IPR, as part of my 
>> document shepherd's writeup I polled the authors and no relevant IPRs 
>> were reported.
>> Can you say more about your concern?
> 
> I was talking about whole set of documents, and at least for the TCP
> CLv4 document there was a potential raised. I want the WG chairs to 
> conlcude if there will be an IPR disclosure and if in that case what 
> the WG action if any will be.
> 
> Regarding the BPbis document, the shepherds write up (
> https://datatracker.ietf.org/doc/draft-ietf-dtn-bpbis/shepherdwriteup/
> ) , question 7 and 8, says N/A on the question about if the authors 
> have confirmed and if there are any IPR disclosures, rather than "It 
> has been confirmed" and "No". If you as shepherd have done the 
> confirmation, can you please have the writeup updated.
> 
> There appear to be more questions that should be updated with actual
> answers: 5, 12, 13, 14, and 15. 
> 
> And yes IESG members do read them, even if this AD apparently missed 
> to read this one properly when doint my AD reveiw.
> 
> Cheers
> 
> Magnus
> 
>> 
>> Regards - Fred
>> 
>>> Cheers
>>> 
>>> Magnus
>>> 
>>> 
>>> 
>>> On Fri, 2019-07-05 at 14:06 +0000, Magnus Westerlund wrote:
>>>> Hi,
>>>> 
>>>> I have now reviewed this document. Consider that there are a number 
>>>> of issues that likely need WG discussion I thought I should send 
>>>> out this, despite that I have not yet reviewed the BPSEC document 
>>>> that appears to be highly relevant and may result in additional 
>>>> changes needed in this document. But BPSEC is next in a my review 
>>>> pile.
>>>> 
>>>> Also as this area is new, I read the architecture a long time ago 
>>>> so don’t hesitate to clarify if it appears that I am missing 
>>>> things.
>>>> 
>>>> 
>>>> 1. Section 4.1.5.1 and 10 :
>>>> 
>>>> As this document uses the "dtn" URI scheme and the "dtn" scheme was 
>>>> only provisional registered by RFC 5050 I think this document 
>>>> should formally register the DTN URI scheme and thus a new 
>>>> subsection in Section 10 is needed.
>>>> 
>>>> Also, maybe similar effort to move "ipn" to permeant is needed?
>>>> 
>>>> 2.       Section 4.1.6:
>>>> 
>>>> I think the format and definition of this field are insufficient.
>>>> It
>>>> is lacking a reference or a normative description of what "Unix 
>>>> Epoch Time" in an unsigned int format actually is. Is the intention 
>>>> here to simply measure the number of seconds since the start of 
>>>> year 2000?
>>>> Which Unix epoch time is not due to leap seconds. And I become 
>>>> uncertain as UTC time scale is something else than Unix Epoch time 
>>>> at least when it comes to leap seconds handling. Due to that Unix 
>>>> Time have discontinuities in the time scale at leap seconds I would 
>>>> recommend strongly against using it. Select UTC or TAI depending on 
>>>> where you want the leap second handling pain to exist.
>>>> 
>>>> Also, you specified only CBOR unsinged integer which is a 
>>>> representation that can use 64-bit and thus not have the issues 
>>>> with 32-bit signed integer seconds epochs that regular unix time 
>>>> has, but that should probably be made explicit that it is expected 
>>>> to handle that. Even if the first wrap of this unsigned 32-bit 
>>>> format will not occur until 2136.
>>>> 
>>>> And please provide necessary normative references, not informative 
>>>> ones.
>>>> 
>>>> 
>>>> 3.       Section 4.2.2:
>>>> 
>>>> The Lifetime field appears problematic if the creating node doesn't 
>>>> have a reliable clock and uses timestamp 0 for all bundles. I think 
>>>> that special case needs to be discussed. Which it is later done, 
>>>> but there is missing reference to that.
>>>> 
>>>> 4.       Section 4.2.2: Report-to EID
>>>> 
>>>> Is this field set by bundle creator and never changed? It is not 
>>>> clear and appear to have implications on how this field should be 
>>>> treated. Primarily considering integrity options over these fields.
>>>> 
>>>> 5.       Section 4.3.3.
>>>> Maximum Hop count upper limit? Can I insert a max UiNT64 here and 
>>>> expect that to be acceptable?
>>>> 
>>>> 6.       Section  5.1:
>>>>   Under some circumstances, the requesting of status reports could
>>>>   result in an unacceptable increase in the bundle traffic in the
>>>>   network. For this reason, the generation of status reports MUST 
>>>> be
>>>>   disabled by default and enabled only when the risk of excessive
>>>>   network traffic is deemed acceptable.
>>>> 
>>>> I find the above paragraph rather unclear. First of all what are 
>>>> the circumstances. Secondly, shouldn't the type of status report 
>>>> requested be discussed. What I can see the different types results 
>>>> in at most 1, N-1 or N times the number of sent bundles with the 
>>>> status report set depending on type, where N is the number of nodes 
>>>> on the path including receiving endpoint.
>>>> 
>>>> So are there any recommendations to when it might be acceptable to 
>>>> request status delivery. To me it appears the trace route like 
>>>> options, like forwarding status report should only be used on a 
>>>> small number of bundles sent for debuging or monitoring purposes.
>>>> 
>>>> Use of the bundle deletion status report appear to have other 
>>>> motivations for its use. I assume that this is fine for cases when 
>>>> it occurs for a small fraction of the bundles for some reasons, but 
>>>> when you have real failures on next hop links it appears that this 
>>>> may cause high volumes of deletion. Thus a rate limitation makes 
>>>> sense. I assume that this is one of the not specified reasons  the 
>>>> below paragraph indicates:
>>>> 
>>>>   When the generation of status reports is enabled, the decision on
>>>>   whether or not to generate a requested status report is left to 
>>>> the
>>>>   discretion of the bundle protocol agent. Mechanisms that could
>>>>   assist in making such decisions, such as pre-placed agreements
>>>>   authorizing the generation of status reports under specified
>>>>   circumstances, are beyond the scope of this specification.
>>>> 
>>>> 7.       Section 5.3:
>>>> 
>>>>   Step 1: If the bundle's destination endpoint is an endpoint of 
>>>> which
>>>>   the node is a member, the bundle delivery procedure defined in
>>>>   Section 5.7 MUST be followed and for the purposes of all 
>>>> subsequent
>>>>   processing of this bundle at this node the node's membership in 
>>>> the
>>>>   bundle's destination endpoint SHALL be disavowed.
>>>> 
>>>> I don't understand why and what implications the disavowing has for 
>>>> a local bundle being dispatched from a member node part of the 
>>>> destination.
>>>> 
>>>> 8.       Section 5.4
>>>> 
>>>>   Step 3: If forwarding of the bundle is determined to be
>>>>   contraindicated for any of the reasons listed in Figure 4, then 
>>>> the
>>>>   Forwarding Contraindicated procedure defined in Section 5.4.1 
>>>> MUST
>>>>   be followed; the remaining steps of Section 5 are skipped at this
>>>>   time.
>>>> 
>>>> Should that last Section 5 be Section 5.4?
>>>> 
>>>> 9.       Section 6.1.1
>>>> What does Destination endpoint ID unintelligible actually mean?
>>>> Same with Block unintelligible.
>>>> 
>>>> Are these the combination for corrupted blocks or EIDs? Are there a 
>>>> point of separating out the case where the CRC indicate a 
>>>> corruption?
>>>> 
>>>> 10.   Section 7.2
>>>> 
>>>> So the service description appears very high level. How is the 
>>>> actual interface working when it comes to dealing with that there 
>>>> is either possibility to send, as well as rate control in the API. 
>>>> When can more data be accepted and when is the convergence layer 
>>>> not ready.
>>>> Also don't the Bundle Agent need a signal when this side thinks it 
>>>> has delivered as a signal of when the forwarding has completed?
>>>> 
>>>> I was expecting this section to actually be explicit about what 
>>>> functionalities the Bundle Agent really need from the convergence 
>>>> layer.
>>>> 
>>>> 11.   Section 9
>>>> 
>>>> I think this section needs to be more explicit about mandating 
>>>> implementation support for BPSEC. The IETF do not publish a 
>>>> protocol today that doesn't have a mandatory to implement security 
>>>> solutions for the protocol's major properties. In this case 
>>>> communication security, i.e. confidentiality, integrity and 
>>>> authentication of the data communicated is very relevant. I have 
>>>> not yet read BPSEC so I may have additional concerns about that 
>>>> issues are not handled in the combined protocol. I hope the BPSEC 
>>>> has some discussion of the privacy properties of the protocol.
>>>> 
>>>> 12.   Section 9:
>>>>   Additionally, convergence-layer protocols that ensure 
>>>> authenticity
>>>>   of communication between adjacent nodes in BP network topology
>>>>   SHOULD be used where available, to minimize the ability of
>>>>   unauthenticated nodes to introduce inauthentic traffic into the
>>>>   network.
>>>> 
>>>> In this context wouldn't it be reasonable to also recommend using 
>>>> encryption on the convergence layer to avoid eavsedropping on the 
>>>> part that is in clear and prevent traffic analysis by third 
>>>> parties?
>>>> 
>>>> 13.   Section 9.
>>>> 
>>>>   Note that the generation of bundle status reports is disabled by
>>>>   default because malicious initiation of bundle status reporting
>>>>   could result in the transmission of extremely large numbers of
>>>>   bundle, effecting a denial of service attack.
>>>> 
>>>> I think there is a clear lack of mitigations proposed for this 
>>>> issue.
>>>> As I mentioned in Issue 6 I think one both needs to consider amount 
>>>> of generated traffic versus utility for the sender. Also I will 
>>>> have to read BPSec to understand what integrity and source 
>>>> authentication there is of the request for status reports. Next is 
>>>> the issue of rate limiting and prioritization of status reports 
>>>> versus other bundles.
>>>> Also due to the multi-hop store and forward nature of this protocol 
>>>> the actual bottle neck may only occur several hops towards the 
>>>> receiver. What can be said about dropping status reports versus 
>>>> other bundles when there is a resource contention, either in 
>>>> storage or in convergence layers capability of forwarding messages 
>>>> within time.
>>>> 
>>>> 14.   Section 6
>>>> I fail to see any discussion of how the sender of a status report 
>>>> should set the lifetime and max hop. Can it actually take that 
>>>> information from the Bundle it is reporting on?
>>>> 
>>>> 15.   Section 10.
>>>> 
>>>> I think this section needs to be clearer. Several improvements that 
>>>> can be made.
>>>> 
>>>> ·         I recommend individual sub-sections per registry
>>>> operation
>>>> ·         Can you be clearer in references to point to specific
>>>> sections of definitions that makes it simpler to find the relevant 
>>>> from the IANA registry?
>>>> 
>>>> More specific parts.
>>>> 
>>>>   This document defines the following additional Bundle Protocol 
>>>> block
>>>>   types, for which values are to be assigned from the Bundle
>>>>   Administrative Record Types namespace [RFC6255]:
>>>> 
>>>> First of all according to the registry, this registry is actually 
>>>> created by RFC 7116.
>>>> 
>>>> This and the observation that the things you attempt to register in 
>>>> this registry you are actual called Bundle Block Types in your 
>>>> document. Thus, I have to ask are you actually addressing the right 
>>>> registry, or is the issue that you actually need per version 
>>>> specific registries for example Bundle Block Types? If it is the 
>>>> later, then lets define new registries. Possibly there should be a 
>>>> new major page for BPv7. Not having read all the old documents, you 
>>>> likely have to consider which registries are version specific and 
>>>> which are not.
>>>> 
>>>> 16. Section 10:
>>>> 
>>>> For the new registry, do you have any requirements for 
>>>> registrations that should be written out. And in addition any 
>>>> criteria you want the expert to consider when approving or 
>>>> rejecting registries? And is this registry version 7 specific or 
>>>> not?
>>>> 
>>>> 17.   Section 4.1.1:
>>>> 
>>>> The CRCs are lacking proper normative references. Needed for both
>>>> 1
>>>> and 2. Note that you have [CRC] that is currently unused.
>>>> 
>>>> 18.   Section 11.2:
>>>> [BPSEC] is a normative reference.
>>>> [RFC6255] is normatively referenced for their registration 
>>>> procedures.
>>>> 
>>>> 19.   Section 13, Section 4.2.2
>>>> 
>>>> This Section 13 item was something I wondered over:
>>>> 
>>>>     . Restructure primary block, making it immutable.  Add optional
>>>>        CRC.
>>>> 
>>>> Did I simply miss where that is said in the context of Section 
>>>> 4.2.2?
>>>> 
>>>> 20.   Optional CRCs
>>>> 
>>>> Why are the primary block CRC optional? I assume the intention with 
>>>> it is to do a verification that the primarily block with the 
>>>> addressing information hasn't become corrupted in the transmission 
>>>> between nodes, similar to the checksums we have in other protocols.
>>>> Under which conditions will not using it be a reasonable idea?
>>>> Are
>>>> you expecting other mechanisms to cover for it, or are you 
>>>> reasoning that having corrupted bundles being delivered to the 
>>>> wrong places is not an issue? As the primarily block is the main 
>>>> addressing part, I would think the considerations that went into 
>>>> discussion of the
>>>> (almost) always usage of the UDP checksum for IPv6 applies here.
>>>> Also
>>>> the implications for corruptions and cost in some DTNs for stray 
>>>> data appears quite high.
>>>> 
>>>> 
>>>> Cheers
>>>> 
>>>> Magnus Westerlund
>>>> 
>>>> _______________________________________________
>>>> dtn mailing list
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/dtn
>>> 
>>> --
>>> Cheers
>>> 
>>> Magnus Westerlund
>>> 
>>> 
>>> -----------------------------------------------------------------
>>> -----
>>> Network Architecture & Protocols, Ericsson Research
>>> -----------------------------------------------------------------
>>> -----
>>> Ericsson AB                 | Phone  [phone]
>>> Torshamnsgatan 23           | Mobile [phone]
>>> SE-164 80 Stockholm, Sweden | mailto: 
>>> [e-mail]
>>> -----------------------------------------------------------------
>>> -----
>>> 
>> 
>> 
> --
> Cheers
> 
> Magnus Westerlund
> 
> 
> ----------------------------------------------------------------------
> Network Architecture & Protocols, Ericsson Research
> ----------------------------------------------------------------------
> Ericsson AB                 | Phone  [phone]
> Torshamnsgatan 23           | Mobile [phone]
> SE-164 80 Stockholm, Sweden | mailto: [e-mail]
> ----------------------------------------------------------------------
> 
> _______________________________________________
> dtn mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dtn

_______________________________________________
dtn mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/dtn