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

From: Magnus Westerlund <[email-masked]>
Date: Fri, 5 Jul 2019 14:06:07 +0000

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

---

From: "R. Atkinson" <[email-masked]>
Date: Sun, 7 Jul 2019 15:27:14 -0400

> On Jul 5, 2019, at 10:06, Magnus Westerlund <[email-masked]> wrote:
>  
> 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. 
>  

Nota Bene:  I understand that DTN is not mandating the use of any particular time synchronisation protocol by a particular DTN implementation.  I agree that such is a system time implementation decision is outside the DTN protocol scope.

That said, in the context of widely deployed IETF standards for time synchronisation, I wonder whether the right answer really might be to specify that this DTN protocol field contains “Time as defined by the IETF Network Time Protocol (NTP)”.  NTP is derived from UTC, but its epoch is not “seconds since start of year 2000”.  Note also that NTP ought not crash in 2036 (which is a common misconception).  Further, while Unix systems often use NTP, NTP time is not necessarily precisely the same as "Unix time".

Quoting from Dave Mills (who invented NTP):

"However, the NTP protocol will synchronise correctly, regardless of era, as long as the system clock is set initially within 68 years of the correct time.”

URL for above quote:  "https://www.eecis.udel.edu/~mills/ntp/html/warp.html"

For more about NTP time eras, please see the article by Dave Mills which is online here:
      "https://www.eecis.udel.edu/~mills/y2k.html”.

The main alternative standards-based  implementation/deployment alternative to NTP might be to use time as defined by Precision Time Protocol (PTP), which is derived from TAI.  

A 3rd possibility is to pick something consistent with CCSDS’ Proximity-1 protocol.  Mills discusses Proximity-1 here:
"https://www.eecis.udel.edu/~mills/proximity.html"

In the context of Delay-Tolerant Networking, the clock precision of PTP likely is significant overkill, while the lower precision of NTP might be more reasonable.  Further, in the context of Delay-Tolerant Networking, consistent definition of time matters but the presence of leap seconds does not create issues (after all, DTN is supposed to be delay-tolerant).

Maybe just go with NTP time and normatively reference the NTP RFC, possibly also with informational references to some of Dave Mills documents ?

What do others think ?

Yours,

Ran

---

From: Magnus Westerlund <[email-masked]>
Date: Mon, 8 Jul 2019 07:05:26 +0000

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. 

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.
>  
>  
> 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.
>  
> 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.
>  
> 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.
>  
> 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:
> 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:
>  
> 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
>  
> 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
>  
> 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?
>  
> 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:
> 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.
>  
> 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.
>  
> 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:
> 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dtn
-- 
Cheers

Magnus Westerlund 

----------------------------------------------------------------------
Network Architecture & Protocols, Ericsson Research
----------------------------------------------------------------------
Ericsson AB                 | Phone  +46 10 7148287
Torshamnsgatan 23           | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden | mailto: [email-masked]
----------------------------------------------------------------------

---

From: Magnus Westerlund <[email-masked]>
Date: Mon, 8 Jul 2019 07:29:56 +0000

Hi,

I also had some private discussion with Scott Burleigh on this matter
of the clock. What we concluded is that the current clock using Unix
Epoch time adjusted to start 2000 appears fine for the current usages
in DTN. The only implication is that during a positive (added) leap
second, both the leap second and the second before will have the same
seconds since value. Nothing BP can't handle. And during negative leap
seconds the clock will simply skip over that last second of that day.
Neither appear to have any real impact on the protocol. 

However, how leap seconds are handled need to be documented and a
normative reference to the clock needs to be provided. 

Regarding Ran's comments below and my comment regarding 64-bit unsigned
integers. You simply need to document what is expected to happen here.
If you continue to use the seconds since year 2000 started then I
really think you should allow 64-bit precision. The reason is that any
system using this system still will have to know the NTP era, i.e. how
many wraps the NTP 32-bits seconds have done to correctly populate BPs
time field. Note that BP time has one wrap around day for a 32-bit
counter, NTP has another and Unix Epoch time a third. Thus tracking the
wraps becomes necessary, or at least knowing that one have a clock
system that will know the year correctly to derive the era. 

So my comment here was really one part failure to understand your
requirements and one part this is insufficiently specified. 
I now have a better understanding of your considerations, so fixing the
insufficiently specified is likely all that is needed. 

Cheers

Magnus Westerlund

On Sun, 2019-07-07 at 15:27 -0400, R. Atkinson wrote:
> > 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. 
> >  
> > 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. 
> >  
> Nota Bene:  I understand that DTN is not mandating the use of any
> particular time synchronisation protocol by a particular DTN
> implementation.  I agree that such is a system time implementation
> decision is outside the DTN protocol scope.
> 
> That said, in the context of widely deployed IETF standards for time
> synchronisation, I wonder whether the right answer really might be to
> specify that this DTN protocol field contains “Time as defined by the
> IETF Network Time Protocol (NTP)”.  NTP is derived from UTC, but its
> epoch is not “seconds since start of year 2000”.  Note also that NTP
> ought not crash in 2036 (which is a common misconception).  Further,
> while Unix systems often use NTP, NTP time is not necessarily
> precisely the same as "Unix time".
> 
> "However, the NTP protocol will synchronise correctly, regardless of
> era, as long as the system clock is set initially within 68 years of
> the correct time.”
> 
> URL for above quote:  "
> https://www.eecis.udel.edu/~mills/ntp/html/warp.html"
> 
> The main alternative standards-based  implementation/deployment
> alternative to NTP might be to use time as defined by Precision Time
> Protocol (PTP), which is derived from TAI.  
> 
> A 3rd possibility is to pick something consistent with CCSDS’
> Proximity-1 protocol.  Mills discusses Proximity-1 here:
> In the context of Delay-Tolerant Networking, the clock precision of
> PTP likely is significant overkill, while the lower precision of NTP
> might be more reasonable.  Further, in the context of Delay-Tolerant
> Networking, consistent definition of time matters but the presence of
> leap seconds does not create issues (after all, DTN is supposed to be
> delay-tolerant).
> 
> Maybe just go with NTP time and normatively reference the NTP RFC,
> possibly also with informational references to some of Dave Mills
> documents ?
> 
> What do others think ?
> 
> Yours,
> 
> Ran
> 
> 
> 
> 
> 
-- 
Cheers

Magnus Westerlund

---

From: "Templin (US), Fred L" <[email-masked]>
Date: Sat, 13 Jul 2019 00:29:20 +0000

HI Magnus,

> -----Original Message-----
> From: dtn [mailto:[email-masked]] On Behalf Of Magnus Westerlund
> Sent: Monday, July 08, 2019 12:05 AM
> To: [email-masked]; [email-masked]
> Subject: Re: [dtn] AD evaluation of draft-ietf-dtn-bpbis-13
> 
> WG,
> 
> 

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?

Regards - Fred

---

From: Magnus Westerlund <[email-masked]>
Date: Mon, 15 Jul 2019 12:48:39 +0000

> 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

> > > It
> > > with
> > > And please provide necessary normative references, not
> > > informative
> > > ones.
> > > 
> > > 
> > > 3.       Section 4.2.2:
> > > 
> > >    whether or not to generate a requested status report is left
> > > to
> > > the
> > >    processing of this bundle at this node the node's membership
> > > in
> > > the
> > >    contraindicated for any of the reasons listed in Figure 4,
> > > then
> > > the
-- 
Cheers

Magnus Westerlund

---

From: "R. Atkinson" <[email-masked]>
Date: Mon, 15 Jul 2019 11:11:18 -0400

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 <[email-masked]> wrote:
>

---

From: "Burleigh, Scott C (312B)" <[email-masked]>
Date: Mon, 15 Jul 2019 23:01:54 +0000

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 <[email-masked]> On Behalf Of R. Atkinson
Sent: Monday, July 15, 2019 8:11 AM
To: DTN WG <[email-masked]>
Subject: [EXTERNAL] Re: [dtn] AD evaluation of draft-ietf-dtn-bpbis-13

Fred,

Cheers,

Ran

>> 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.
> 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 
> 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
>>> 
>>> 
>>> 
>>>> 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.
>>>> 
>>>> 
>>>> 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.
>>>> 
>>>> is lacking a reference or a normative description of what "Unix 
>>>> year 2000?
>>>> 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 
>>>> that special case needs to be discussed. Which it is later done, 
>>>> but there is missing reference to that.
>>>> 
>>>> 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.
>>>> 
>>>> options, like forwarding status report should only be used on a 
>>>> small number of bundles sent for debuging or monitoring purposes.
>>>> 
>>>> 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:
>>>> 
>>>> 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
>>>> 
>>>> 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.
>>>> 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 
>>>> 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.
>>>> 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
>>>> 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:
>>>> 
>>>> 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
>>>> the implications for corruptions and cost in some DTNs for stray 
>>>> data appears quite high.
>>>> 
>>>> 
>>>> Cheers
>>>> 
>>>> Magnus Westerlund
>>>>

---

From: "Burleigh, Scott C (US 312B)" <[email-masked]>
Date: Wed, 17 Jul 2019 15:22:57 +0000

Hi, all.  Attached is a revised bpbis Internet-Draft, modified in response
to Magnus's evaluation of draft 13.  (The window for posting I-Ds is
currently closed, so unfortunately the document has to be emailed.)  Answers
to the questions in the evaluation are proposed in-line within the
evaluation, below.

In addition to the modifications in response to the evaluation, this draft
also responds to Brian's comments from May 16 and reflects some additional
discussion among the authors.  Also, it has been called to my attention that
the thing I have been calling a flow label is not one; in the new draft, the
term "data label" is adopted instead.

Scott

From: Magnus Westerlund <[email-masked]> 
Sent: Friday, July 5, 2019 7:06 AM
To: [email-masked]; [email-masked]
Subject: [EXTERNAL] AD evaluation of draft-ietf-dtn-bpbis-13

Hi,

Yes. Section 10.3 has been added for this purpose.

By all means.  But I think the first step is to get the "dtn" scheme
provisionally registered. 

2.       Section 4.1.6:

As we've discussed, some explanatory text is needed; it has been inserted
into section 4.1.6. 

Noted in 4.1.6.

Some guidance needed here: which normative references are required? 

3.       Section 4.2.2:

Forward reference to 4.3.2 has been added in 4.2.2. 

Text has been added in 4.2.2 to clarify that the primary block is immutable.

5.       Section 4.3.3.

We left this question as explicitly "beyond the scope", but we can assert a
number.  What should the maximum hop limit be? 

6.       Section  5.1:

Text acknowledging this has been added to 5.1.

That's the intent.  A clarifying phrase has been added in 5.1.

That's right.  We believe that policy mechanisms to accomplish this are
going to be needed, but we don't know what form they will take.  Again,
beyond the scope.

7.       Section 5.3:

Some clarifying text has been added to 5.3.

8.       Section 5.4

Yes!  Good catch - now fixed.

9.       Section 6.1.1

It means that the receiving bundle protocol agent cannot process the block
for some reason: either the block is malformed or it is corrupted (CRC
doesn't match) or it is simply a type of extension block that the
implementation does not recognize.

Yes.  Added a new Step 3 in 5.6.

10.   Section 7.2

We specifically don't want to constrain implementations of BP and
convergence-layer adapters any more than necessary, as this has no impact on
protocol interoperability.  But yes, a "forwarding completed" signal is
needed; inserted second bullet in list in 7.2.  

We really want to avoid over-constraining here.  Implementation experience
has shown that more extensive guidance is not needed. 

11.   Section 9

Section 9 now states that inclusion of the Bundle Security Protocol in any
Bundle Protocol implementation is REQUIRED.

12.   Section 9:

   network.

Yes; added in 4th paragraph of section 9. 

13.   Section 9. 

Yes.  To address this, an additional reason code "Traffic pared" has been
added to Figure 4.  This authorizes the bundle protocol agent to drop status
reports at its own discretion as described in Step 2 of 5.4.

14.   Section 6

There may be better ways to select values for these parameters, but none are
known yet.  The correct procedure may be wildly different in different kinds
of delay-tolerant networks.  We want to avoid over-constraining
applications. 

15.   Section 10.

.         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? 

Yes, done.

More specific parts.

RFC 7116 defines the Licklider Transmission Protocol.  This sounds like an
error in the registry. 

"Bundle Block Types" is correct.  The block types defined for BPv7 are a
superset of the block type types defined for RFC 5050. 

16. Section 10: 

No known requirements or considerations aside from the obvious ones (e.g., a
reference document is required).  RFC 5050 has no notion of URI scheme type
numbers, so while the new registry is specific to version 7 it doesn't
supersede any other registry.

17.   Section 4.1.1:

Right, added.  (Brian Sipos commented on this as well.) 

18.   Section 11.2:

Changed [BPSEC] to normative.  Changed [RFC6255] to normative also, but
since this is an informative RFC I worry that the nits filter won't like it.

        CRC.

Added text about primary block immutability in 4.2.2.

20.   Optional CRCs

The thinking has been that you should virtually always have a bpsec BIB
attached to the primary block, which not only authenticates the block but
also protects the integrity of the block.  In that scenario, a CRC on the
primary block would not add much value.

BIBs can also be attached to other blocks, but in some cases a BIB might be
overkill and a CRC is all that's needed.  So the CRCs are always an option. 

Cheers

Magnus Westerlund

---

From: Magnus Westerlund <[email-masked]>
Date: Fri, 26 Jul 2019 14:36:08 +0000

Hi,

Regarding reference in section 4.1.6: What I expect in the text is a
normative reference for the definition of the Unix Epoch Time in the first
sentence of this section. 

Cheers

Magnus

---

From: Magnus Westerlund <[email-masked]>
Date: Tue, 30 Jul 2019 09:56:57 +0000

Hi,

I looked at the attached changes and here are some comments. Note, I
found some additional editorial issues that should be addressed. 

1. Section 2: Instead of using the home made boiler plate I would
suggest that you use RFC 8174 and its proposed boiler plate.

2. Section 4.1.3: Bit 8. The Manifest block extension. I forsee that
people will have issues with the lack of normative reference. So either
normatively reference the manifest specification, alternatively mark it
reserved, and a informative note that it is inteded for this manifest
block. Then have the manifest block assign itself this bit when
actually published?

3. Section 4.3: 

This section has additional normative reference requirements. As
currently formulated it most definitely makes teh Manifest block a
normative reference. But also the other extension blocks needs
references. If that can be informative references or needs to be
normative ones depends on and needs a detailed look on each. 

So BIB and BCB is simple to normatively reference and synchronization
of their publication is not an issue. 

Manifest I lack the view of in what status it is in. However, there are
no active WG draft on it? 

What are the status of the Data Label Block? 

I would think that making an informative reference and simply note that
they are reserved and future assignment needs to have matching purposes
with BPv6 as the name space is shared is way forward. 

4. Section 10. As discussed at meeting, there is a benefit in having
this docuemnt take over the registries that RFC 6255 defines to gather
the rules in one place and ensure that they are aligned. 

The rest of the changes appears fine to me. 

Cheers

Magnus Westerlund

---

From: "Burleigh, Scott C (US 312B)" <[email-masked]>
Date: Tue, 30 Jul 2019 13:19:17 +0000

Perfect.  I will make update the draft accordingly and aim to get it posted by sometime Thursday.  Thanks, Magnus.

Scott

-----Original Message-----
From: Magnus Westerlund <[email-masked]> 
Sent: Tuesday, July 30, 2019 2:57 AM
To: [email-masked]; [email-masked]; Burleigh, Scott C (US 312B) <[email-masked]>
Subject: [EXTERNAL] Re: [dtn] AD evaluation of draft-ietf-dtn-bpbis-13

Hi,

3. Section 4.3: 

Cheers

Magnus Westerlund