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

["R. Atkinson" <[e-mail]>]

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