Subject: [Gen-art] Genart last call review of draft-ietf-dtn-bpbis-17

From: Stewart Bryant via Datatracker <[email-masked]>
Date: Wed, 06 Nov 2019 11:22:34 -0800

Reviewer: Stewart Bryant
Review result: Not Ready

I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair.  Please treat these comments just
like any other last call comments.

For more information, please see the FAQ at

<https://trac.ietf.org/trac/gen/wiki/GenArtfaq>.

Document: draft-ietf-dtn-bpbis-17
Reviewer: Stewart Bryant
Review Date: 2019-11-06
IETF LC End Date: 2019-11-12
IESG Telechat date: Not scheduled for a telechat

Summary:

There are quite a number of issues that need to be attended to in this document.

None of that is fundamental to the protocol itself, but work is needed to make
this ready for publication as a Proposed Standard.

========

Major issues:

It is not clear what the status of this RFC will be relative to RFC5050.
If it modifies the status of RFC5050 it needs to make this clear in the
boilerplate, Abstract and Introduction.

========

     . 0 indicates "no CRC is present."
     . 1 indicates "a standard X-25 CRC-16 is present." [CRC16]
     . 2 indicates "a standard CRC32C (Castagnoli) CRC-32 is present."
        [CRC32C]

SB> I am surprised that in these more modern times something stronger
than a CRC is not used, for example a crypto hash. Particularly given the
harsh environment that this is targeting.

=========
     . The bundle contains a "manifest" extension block.  (Boolean)
SB> Given that manifest is not defined yet this seems out of place in an ST text

======
Relative to the section DTN Time:

   Unix epoch time is the next best option.  Like TAI, Unix epoch time
   is simply a count of seconds elapsed since a standard epoch.  Unlike
   TAI, the current value of Unix epoch time is provided by virtually
   all operating systems on which BP is likely to run.

SB> This section needs to be checked by a time expert.

SB> I think you are saying that you use Unix time, but Unix time
includes leap seconds by double increment, so I don’t think
you are using that because that would give you the measurement
error you are concerned about. I think that what you are using is
a monotonically increasing time based on the Unix epoch. I think
that is what PTP (IEEE1588) is using and PTP might be a better
reference. PTP is likely to become more available in spacecraft
anyway, since it is finding deployment in precision measurement
 applications. Thus I am not sure I understand why UET is more
accessible on spacecraft than TAI. Presumably the spacecraft are using
free-running clocks and so will drift, although I understand that
work is in progress to provide time sync to spacecraft for
navigation purposes.

 The argument in this section seems long and will become dated.
Surely all you need to say is that you need a monotonically
increasing time system such as TAI or UNIX time(), and out of
software convenience you choose the latter. However I don’t
think that is what you are actually doing. What I think you are doing
is using TAI with a free running clock that you accept will drift.

SB> A lot of the text in this section is not really normative and
perhaps belongs in a non-normative appendix.

==========

   The following extension block types are reserved for extension
   blocks for which a need is anticipated but for which no definitions
   yet exist:

     . Block type 13 is reserved for the anticipated Manifest Block.
SB> This should really be handled through an IANA registry. It seems
strange to have text that is semi-definative about anticipated
features in a proposed standard. Same for types 14 and 15.
They should not be in ST text until they are standard.

=========
In the Security Section

   Note that, while the primary block must remain in the clear for
   routing purposes, the Bundle Protocol can be protected against
   traffic analysis to some extent by using bundle-in-bundle
   encapsulation to tunnel bundles to a safe forward distribution
   point: the encapsulated bundle forms the payload of an encapsulating
   bundle, and that payload block may be encrypted by a BCB.

SB> Is there a definition of the bundle in bundle protocol?

SB> The material that follows seems to be defining protocol which
is unusual in a security section. I would be better to define protocol
in the body of the text or simply point to a definition in another document.

=========

10.1. Bundle Block Types
SB> The namespaces do not seem to be identified.

SB> The IANA reference for new allocations ought to be to this RFC

SB> Given that this is a Standards Document I am surprised that
references to RFC5050 are not replaced with references to this RFC.
Does this indicate that RFC5050 is expected to remain a current protocol.
If so we are in the odd position of a ST text relying on definitions in an
Experimental text. This is something that the IESG needs to consider.

=========
   The registration policy is changed to "Expert Review". Given the
   maximum number of bits available, the allocation should only be
   approved with a well-defined specification and proof of real usage.

SB> I am surprised that it (or some part of it) is not changed to one
of the more difficult critera, such as Standards Action. Also I am
surprised that there are no private use or experimental allocations.

=========

11.1. Normative References

   [BPSEC] Birrane, E., "Bundle Security Protocol Specification", Work
   In Progress, October 2015.

SB> I am not sure what this points to but I think it is RFC6257
which is experimental and hence is a downref. This needs the proper ref
and the downref addressing.

   [CRC16] ITU-T Recommendation X.25, p. 9, section 2.2.7.4,
   International Telecommunications Union, October 1996.
SB> This shows up in nits as a downref, but I am sure it is OK,

   [CRC32C] Castagnoli, G., Brauer, S., and M. Herrmann, "Optimization
   of Cyclic Redundancy-Check Codes with 24 and 32 Parity Bits", IEEE
   Transact. on Communications, Vol. 41, No. 6, June 1993.

SB> I am not sure what the policy is WRT having a normative ref to an IEEE
paper. SB> Information on CRC32C is more accessibly found in RFC3385

   [EPOCH] Thompson, K. and D. M. Ritchie, "UNIX Programmer's Manual,
   Fifth Edition", Bell Telephone Laboratories Inc., June 1974.  See
   https://www.tuhs.org/Archive/Distributions/Research/Dennis_v5/v5man.
   pdf.

SB> I am sure this is a fine document but again I am not sure if
you can point to it as normative.

=========

   This work is freely adapted from RFC 5050, which was an effort of
   the Delay Tolerant Networking Research Group.

SB> Is it simply adapted? What is the relative standing of the two?
As far as I can see this Standard relies on definitions provided by that RFC.

=========
Appendix B.                  CDDL expression
SB> What is the licence position for the code that follows?

=========
=========

Minor issues:

10.2. Primary Bundle Protocol Version

   The current Primary Bundle Protocol Version Registry is augmented by
   adding the following value.
SB> This is normally expressed as a request for IANA to take an action on a
namespace.

=======

10.4. Block Processing Control Flags

   The current Block Processing Control Flags Registry is augmented by
   adding a column identifying the version of the Bundle protocol
   (Bundle Protocol Version) that applies to the related BP version.
   The current values in the registry should have the Bundle Protocol
   Version set to the value 6 or "6, 7", as shown below.

SB> Again no namespace specified.

=========

10.6. Bundle Protocol URI scheme types

   The Bundle Protocol has a URI scheme type field - an unsigned
   integer of undefined length - for which IANA is requested to create
   and maintain a new registry named "Bundle Protocol URI Scheme Type
   Registry”.

SB> In which namespace?

SB> I am surprised that in an 8bit field there are not more reserved
values that require more considered  action to release.

========
Appendix A.                 For More Information

   Please refer comments to [email-masked]. DTN Working Group documents
   are located at https://datatracker.ietf.org/wg/dtn/documents.  The
   original Delay Tolerant Networking Research Group (DTNRG) Web site
   is located at https://irtf.org/concluded/dtnrg.

SB> That does not seem right for a PS document.

=======
=======

Nits/editorial comments:

   Note: The choice of Unix epoch time as the scale on which time
   values in DTN are expressed may need some explanation.
SB> The above looks like a spurious editors’ note, instead of the introduction
to the text that follows.

=========

   Step 2: The bundle protocol agent MUST determine whether or not
   forwarding is contraindicated for any of the reasons listed in
   Figure 4. In particular:

SB> contraindicated is a very erudite word, but I wonder how many
of the readers, particularly those who are not native English speakers
will understand it. Perhaps a simpler word might me used. If not then it
ought to be defined in the text.

---

From: "[email-masked]" <[email-masked]>
Date: Thu, 7 Nov 2019 03:06:56 +0000 (UTC)

Hi Stewart,
"not ready' is imo a fair summary.

- How (and whether) to deprecate RFC5050 has received muchdtn list discussion; I believe that boiled down to 'get theIRTF to deprecate RFC5050, since they published and own it'.(implementers in the CCSDS world are keen to make bis as5050-like as possible, and would like bits to be twiddled tomatch where possible. Since RFC5050 was standardised(!) in parallelby CCSDS, deprecating it in favour of bis is rather awkwardfor them.)

- If you're surprised that there's nothing stronger thana CRC here, RFC5050's assumption that bundles always arrivewithout errors in the harsh environment - somehow, neverneeding any high-level checking of payload or sanity-checkingof headers - will AMAZE you. A reliable network and reliabledelivery of bundles is taken for granted.

(I do like MD5 as a hash, which works well for reliability whensecurity properties are not expected of it, and is relativelycollision-free, which is what you want for a checksumof big files. But, even MD5 can be computational overkillfor this, when all that is needed as a minimum is a simpleappropriately-scoped reliability check of headers for onwardforwarding or discards/ requesting resends.)

- leap seconds and getting updates for leap seconds area long term problem. Clocks drift, they fail; assuming thecontinuous presence of a reliable time source at all isa big... leap. A reliable clock and reliable delivery of timeis taken for granted.

The time problem was a problem ten years ago when RFC5050was being debated; little has changed to solve it, andI'd argue that it's a fundamental problem.
But, after ten years and another workgroup, we do now havechecksum support for some reliability checks.
That's progress!

plus ça change, plus c'est la même chose.

Lloyd Wood [email-masked] http://about.me/lloydwood 

    On Thursday, 7 November 2019, 06:22:44 GMT+11, Stewart Bryant via Datatracker <[email-masked]> wrote:  
 
 Reviewer: Stewart Bryant
Review result: Not Ready

Summary:

========

Major issues:

========

=========

======

==========

=========
In the Security Section

=========

10.1. Bundle Block Types

=========

=========

=========

=========

=========
=========

Minor issues:

=======

=========

SB> In which namespace?

========

=======
=======

Nits/editorial comments:

=========

---

From: Stewart Bryant <[email-masked]>
Date: Thu, 7 Nov 2019 13:02:18 +0000

Following offline discussions with an IETF collegue, I would like to add a number of points regarding the timing material in the draft.

1) It would  be better to reference POSIX time (with a reference) than UNIX time.

2) There will be a Y2038 and Y2106 rollover which users need to be aware of and may cause some disruption

3) I can confirm that the time systems chosen will silently double increment when leap seconds are added, which is counter to the behaviour the document seems to be trying to avoid.

Obviously changing to a better reference time such as TAI would solve the problem, but if that is not possible, then the issues should be documented. Whatever the way forward the section on DTN time needs a significant edit.

Best regards.

Stewart

> On 6 Nov 2019, at 19:22, Stewart Bryant via Datatracker <[email-masked]> wrote:
> 
> Reviewer: Stewart Bryant
> Review result: Not Ready
> 
> _______________________________________________
> Gen-art mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/gen-art

---

From: Magnus Westerlund <[email-masked]>
Date: Fri, 8 Nov 2019 10:22:17 +0000

Hi Stewart,

As responsible AD I like to add a bit here. Please see inline. The WG will still
need to discuss how to address these comments. 

Regarding the "pre-allocation" of certain bits and code-points, I would tend to
agree. I think one can put tham as reserved in this specification. And in cases
of where BPv7 and BPv6 (RFC5050) shares registry the actual code-point values
are already registered for those purposes. 

> boilerplate, Abstract and Introduction.

As have been pointed out the WG consensus is to not attempt to obsolete RFC 5050
at this point, rather let IRTF obsolete when they think it is not any more
relevant. This, has also resulted in a discussion between the IESG and the IRTF
chair and IRSG on how do deal with cases where we actually want to obsolete an
IRTF stream document. So that is at least possible if the IRTF agrees to it. 

> harsh environment that this is targeting.

As Lloyd commented this is for basic error checking. There is 
https://datatracker.ietf.org/doc/draft-ietf-dtn-bpsec/ that defines keyed crypto
integrity protection as well as encryption that can be applied to bundles. 

> is using TAI with a free running clock that you accept will drift.

So, when I did the AD review I did raise similar concerns, and the note was
really intended to answer these questions of why the chosen clock rather than
TAI or other clock definitions that would avoid some other issues. I got enough
good answers to progress, but apparently the motivation part isn't clear enough
to make you comfortable over the choices. 

I don't see an issue with removing these forward incomplete references. With the
common type namespaces these code-points are reserved for those particular uses
already. 

> SB> Is there a definition of the bundle in bundle protocol?

Yes, draft-ietf-dtn-bibext. 

> SB> The namespaces do not seem to be identified.

So searching for "Bundle Block Types" on https://www.iana.org/protocols will
find you the registry, so I don't know why you think the namespace isn't
identified. Do you missing the general Bundle Protocol category for the
registry? 

> SB> The IANA reference for new allocations ought to be to this RFC

So the registry is actually defined in RFC 6255. And the decision to allow both
BPv6 and BPv7 so co-exist and co-use the registry results in this situation. But
I think you are correct in that the reference column of the table should contain
both RFC5050 and [RFC-TBA] to make it clear that this is how it is intended to
look. 

> surprised that there are no private use or experimental allocations.

With Expert Review I think the argument can be that one don't need to have
private use or experimental allocations as any such needs can be dealt with
through the expert. From my perspective I think this make sense in this
particular case. There is a limted range and re-use of bits for private and
experimental purpose is not straightforward. Thus, taking each bit's definition
into account if to assign it or not do make sense to me. 

> and the downref addressing.

That should be made clear that this is draft-ietf-dtn-bpsec. 

> https://protect2.fireeye.com/v1/url?k=773aa56c-2beea2c0-773ae5f7-8667c4afe13e-8af513574b1eb372&q=1&e=ed73115d-ee55-44cf-bf78-c189ad611603&u=https%3A%2F%2Fwww.tuhs.org%2FArchive%2FDistributions%2FResearch%2FDennis_v5%2Fv5man
> .
>    pdf.
> 

To my understanding the actual BPv7 protocol definition should be stand-alone,
but sharing some common infrastructure, like IANA registries. Do you have a
particular case where there is a normative dependency to any of the IRTF stream
RFCs, other than the IANA regstries? 

> SB> What is the licence position for the code that follows?

This is not code, it is CDDL so it is format description, comparable to ABNF. 

As it is submitted under BCP 78 and IETF TPL so I don't see any formal issues
with it. 

Cheers

Magnus Westerlund 

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

---

From: Stewart Bryant <[email-masked]>
Date: Fri, 8 Nov 2019 12:35:52 +0000

> to make you comfortable over the choices. 

Hi Magnus

I will address the other points in a later email, but on this I am concerned that WG have a misunderstanding of the timebase they are using. UNIX/POSIX time does have leap seconds it just handles them silently so you will get double increments. However since my follow-up note yesterday, I was wondering how the remote remote system knew to add a leap second in order to keep in track with the local system? Isn’t there a risk that the two systems will drift apart as leap seconds are added locally? Also there is the rollover problem to worry about.

I think the section needs to go to a specialist group for review such as TicToc/NTP to verify that it works exactly as the WG expect.

Best regards

Stewart

---

From: [email-masked]
Date: Fri, 8 Nov 2019 13:03:17 +0000 (UTC)

Yes, there is a risk that systems will drift due to accumulated leap seconds without updates.We worked throuugh the details... http://lloydwood.users.sourceforge.net/Personal/L.Wood/publications/wood-ieee-aerospace-2009-bundle-problems.pdf 
but keeping time accurately and continuously (temperature extremes causing drift, power loss) is likely more of an issue in many use cases.
The background assumption here is the NASA interplanetary internet use case (and first RG before DTNRG), where a spacecraft without a clock is useless, the clock is a critical component and sync'd with updates continuously somehow, all hail the clock.
DTN doesn't scale beyond that to other use cases that well.

Lloyd [email-masked]

On Friday, November 8, 2019, 11:35 pm, Stewart Bryant <[email-masked]> wrote:

Hi Magnus

---

From: Stewart Bryant <[email-masked]>
Date: Fri, 8 Nov 2019 14:33:10 +0000

> On 8 Nov 2019, at 13:03, [email-masked] wrote:
> 
> http://lloydwood.users.sourceforge.net/Personal/L.Wood/publications/wood-ieee-aerospace-2009-bundle-problems.pdf <http://lloydwood.users.sourceforge.net/Personal/L.Wood/publications/wood-ieee-aerospace-2009-bundle-problems.pdf>
The critical text in that paper is:

"The Bundle Protocol uses Coordinated Universal Time (UTC), where leap seconds are added at irregular, unpredictable, intervals to reflect slowing of the Earth’s rotation. For nodes ‘in the field’ for a long time (decades), some way of communicating newly-decided UTC leap seconds will be required to prevent clock drift over long time scales that would eventually lead to bundles expiring before delivery. This is most likely to be a significant issue for real-time traffic with very short bundle lifetimes."
That says that leap-seconds need to be transmitted to the remote site, but the ID does not say anything about that, indeed it silently implies that this is handled.

The draft text says

Like TAI, Unix epoch time
   is simply a count of seconds elapsed since a standard epoch.  Unlike
   TAI, the current value of Unix epoch time is provided by virtually
   all operating systems on which BP is likely to run.

Which is not quite right. The TAI is a continuous count of the number of seconds since the epoch. The UNIX tine is the continuous count + leap seconds since the epoch. Unix knows how many leap seconds have happened by a background process and adds them in, but for that to work it has to have a method of knowing the current leap second state. BTW leap seconds can be removed as well as added.

- Stewart

---

From: "Burleigh, Scott C (US 312B)" <[email-masked]>
Date: Fri, 8 Nov 2019 15:34:00 +0000

I disagree.  From Wikipedia:

Unix time (also known as Epoch time, POSIX time,[1]<https://en.wikipedia.org/wiki/Unix_time#cite_note-1> seconds since the Epoch,[2]<https://en.wikipedia.org/wiki/Unix_time#cite_note-single-unix-spec-4.16-2> or UNIX Epoch time[3]<https://en.wikipedia.org/wiki/Unix_time#cite_note-3>) is a system for describing a point in time<https://en.wikipedia.org/wiki/Timestamp>. It is the number of seconds<https://en.wikipedia.org/wiki/Second> that have elapsed since the Unix epoch, that is the time 00:00:00 UTC<https://en.wikipedia.org/wiki/Coordinated_Universal_Time> on 1 January 1970, minus leap seconds<https://en.wikipedia.org/wiki/Leap_second>. Leap seconds are ignored,[4]<https://en.wikipedia.org/wiki/Unix_time#cite_note-single-unix-spec-rationale-4.16-4> with a leap second having the same Unix time as the second before it, and every day is treated as if it contains exactly 86400 seconds.[2]<https://en.wikipedia.org/wiki/Unix_time#cite_note-single-unix-spec-4.16-2> Due to this treatment Unix time is not a true representation of UTC.

Now, of course, this is Wikipedia, which everyone knows to be useless and unreliable.  But the summary is at least concise and clear, and in this particular case it is supported by several source documents, noted at the bottom of the article.

For example, “The Open Group Base Specifications Issue 7, Rationale: Base Definitions”, section A.4 (General Concepts) says “Coordinated Universal Time (UTC) includes leap seconds. However, in POSIX time (seconds since the Epoch), leap seconds are ignored (not applied) to provide an easy and compatible method of computing time differences.”

Going back a bit, page 166 of https://www.tuhs.org/Archive/Distributions/Research/Dennis_v5/v5man.pdf Dennis and Ritchie (who ought to know) say “Time returns the time since 00:00:00 GMT, Jan. 1, 1970, measured in seconds.”

I am happy to agree that an operating system’s implementation of the time() function may typically obtain accurate UTC time (from GPS or NTP) and subtract the leap seconds out of that value to obtain Epoch time, and in this sense the implementation of the time() function is typically dependent on information about leap seconds.

But that is an implementation expedient, which BP does not care about.  What BP cares about is expressing time as a number of seconds that have elapsed since the Epoch (minus an offset, the number of seconds elapsed from the Epoch to midnight 1 January 2000 UTC).  The manner in which that value is generated doesn’t matter to the protocol.

Scott

From: Stewart Bryant <[email-masked]>
Sent: Friday, November 8, 2019 6:33 AM
To: [email-masked]
Cc: Magnus Westerlund <[email-masked]>; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: [EXTERNAL] Re: [Last-Call] Genart last call review of draft-ietf-dtn-bpbis-17

On 8 Nov 2019, at 13:03, [email-masked]<mailto:[email-masked]> wrote:

http://lloydwood.users.sourceforge.net/Personal/L.Wood/publications/wood-ieee-aerospace-2009-bundle-problems.pdf

- Stewart

---

From: "Salz, Rich" <[email-masked]>
Date: Fri, 8 Nov 2019 15:37:00 +0000

I strongly suggest you talk with NTP WG folks about this.

---

From: Joe Touch <[email-masked]>
Date: Fri, 8 Nov 2019 07:40:41 -0800

Unix time != the Posix time API. One is a time scale; the other is the interface to obtain potentially many different time scales.

I dove into these issues here: draft-touch-time

Joe

> On Nov 8, 2019, at 7:34 AM, Burleigh, Scott C (US 312B) <scott.c.burleigh=[email-masked]> wrote:
> 
> Unix time (also known as Epoch time, POSIX time,[1] <https://en.wikipedia.org/wiki/Unix_time#cite_note-1> seconds since the Epoch,[2] <https://en.wikipedia.org/wiki/Unix_time#cite_note-single-unix-spec-4.16-2> or UNIX Epoch time[3] <https://en.wikipedia.org/wiki/Unix_time#cite_note-3>) is a system for describing a point in time <https://en.wikipedia.org/wiki/Timestamp>. It is the number of seconds <https://en.wikipedia.org/wiki/Second> that have elapsed since the Unix epoch, that is the time 00:00:00 UTC <https://en.wikipedia.org/wiki/Coordinated_Universal_Time> on 1 January 1970, minus leap seconds <https://en.wikipedia.org/wiki/Leap_second>. Leap seconds are ignored,[4] <https://en.wikipedia.org/wiki/Unix_time#cite_note-single-unix-spec-rationale-4.16-4> with a leap second having the same Unix time as the second before it, and every day is treated as if it contains exactly 86400 seconds.[2] <https://en.wikipedia.org/wiki/Unix_time#cite_note-single-unix-spec-4.16-2> Due to this treatment Unix time is not a true representation of UTC.
>  
> For example, “The Open Group Base Specifications Issue 7, Rationale: Base Definitions”, section A.4 (General Concepts) says “Coordinated Universal Time (UTC) includes leap seconds. However, in POSIX time (seconds since the Epoch), leap seconds are ignored(not applied) to provide an easy and compatible method of computing time differences.”
>  
> Going back a bit, page 166 of https://www.tuhs.org/Archive/Distributions/Research/Dennis_v5/v5man.pdf <https://www.tuhs.org/Archive/Distributions/Research/Dennis_v5/v5man.pdf> Dennis and Ritchie (who ought to know) say “Time returns the time since 00:00:00 GMT, Jan. 1, 1970, measured in seconds.”
>  
> From: Stewart Bryant <[email-masked] <mailto:[email-masked]>> 
> To: [email-masked] <mailto:[email-masked]>
> Cc: Magnus Westerlund <[email-masked] <mailto:[email-masked]>>; [email-masked] <mailto:[email-masked]>; [email-masked] <mailto:[email-masked]>; [email-masked] <mailto:[email-masked]>; [email-masked] <mailto:[email-masked]>
> On 8 Nov 2019, at 13:03, [email-masked] <mailto:[email-masked]> wrote:
>  
> -- 
> last-call mailing list
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/last-call <https://www.ietf.org/mailman/listinfo/last-call>

---

From: Stewart Bryant <[email-masked]>
Date: Fri, 8 Nov 2019 16:16:01 +0000

I think you are right, apologies.

However, this subject is such a minefield that the wise thing to do is to have the section reviewed by someone from the NTP/TICTOC WG.

- Stewart

> On 8 Nov 2019, at 15:34, Burleigh, Scott C (US 312B) <[email-masked]> wrote:
>

---

From: Stewart Bryant <[email-masked]>
Date: Fri, 8 Nov 2019 16:24:21 +0000

> On 8 Nov 2019, at 15:40, Joe Touch <[email-masked]> wrote:
> 

Interesting draft, but I am surprised that you do not note PTP/IEEE1588.

Stewart

---

From: "Salz, Rich" <[email-masked]>
Date: Fri, 8 Nov 2019 18:05:29 +0000

*   I dove into these issues here: draft-touch-time

  *   Interesting draft, but I am surprised that you do not note PTP/IEEE1588.

NTP WG works with the PTP folks.

---

From: Laurence Lundblade <[email-masked]>
Date: Fri, 8 Nov 2019 14:04:28 -0800

CBORbis defines an “Epoch-based Date/Time” here <https://tools.ietf.org/html/draft-ietf-cbor-7049bis-09#section-3.4.3> making normative reference to Posix time with a brief discussion of leap seconds, positive and negative values and number of bits.

(I’m not familiar with draft-ietf-dtn-bpbis-xxm, just saw the time discussion and thought it might be of use)

LL

> On Nov 8, 2019, at 7:40 AM, Joe Touch <[email-masked]> wrote:
> 
>> On Nov 8, 2019, at 7:34 AM, Burleigh, Scott C (US 312B) <scott.c.burleigh=[email-masked] <mailto:scott.c.burleigh=[email-masked]>> wrote:
>> 
> [email-masked]
> https://www.ietf.org/mailman/listinfo/last-call

---

From: [email-masked]
Date: Sat, 9 Nov 2019 04:11:17 +0000 (UTC)

One of the more enjoyable aspects of the Bundle Protocol is how you can't reliably correct a misset clock on a bundle node by using the bundle protocol itself - because the bundles containing payloads commanding the time change could well be expired and discarded before being carried out, once their timestamps are compared to the errant clock. It's a rather neat self-denial-of-service - section 5.5, and how do you know the local clock is accurate?
So, an ancillary support apparatus for communications not using the bundle protocol would be needed to update the clock behind the bundle agent's back, and that's likely an IP stack (as it happily is in most bundle implementations, where time comes from NTP. There's not that much bundling standing alone, and TCP is the convergence layer of choice, so there may not be much standalone experience with bundle node clocks).
while there is some text in the draft concerning bundles originating from a node with misset clocks, I can't see much concerning sending -to- a node with a misset clock (yes, it's relative, with just two nodes you never know the right time), what is expected to happen, and how that gets handled. More of a network administration problem...

Lloyd Woodhttp://lloydwood.users.sourceforge.net/Personal/L.Wood/dtn/ 

#yiv8177139594 #yiv8177139594 -- _filtered #yiv8177139594 {font-family:Wingdings;panose-1:5 0 0 0 0 0 0 0 0 0;} _filtered #yiv8177139594 {panose-1:2 4 5 3 5 4 6 3 2 4;} _filtered #yiv8177139594 {font-family:Calibri;panose-1:2 15 5 2 2 2 4 3 2 4;}#yiv8177139594 #yiv8177139594 p.yiv8177139594MsoNormal, #yiv8177139594 li.yiv8177139594MsoNormal, #yiv8177139594 div.yiv8177139594MsoNormal {margin:0in;margin-bottom:.0001pt;font-size:11.0pt;font-family:sans-serif;}#yiv8177139594 a:link, #yiv8177139594 span.yiv8177139594MsoHyperlink {color:blue;text-decoration:underline;}#yiv8177139594 a:visited, #yiv8177139594 span.yiv8177139594MsoHyperlinkFollowed {color:purple;text-decoration:underline;}#yiv8177139594 p.yiv8177139594MsoListParagraph, #yiv8177139594 li.yiv8177139594MsoListParagraph, #yiv8177139594 div.yiv8177139594MsoListParagraph {margin-top:0in;margin-right:0in;margin-bottom:0in;margin-left:.5in;margin-bottom:.0001pt;font-size:11.0pt;font-family:sans-serif;}#yiv8177139594 p.yiv8177139594msonormal0, #yiv8177139594 li.yiv8177139594msonormal0, #yiv8177139594 div.yiv8177139594msonormal0 {margin-right:0in;margin-left:0in;font-size:11.0pt;font-family:sans-serif;}#yiv8177139594 span.yiv8177139594EmailStyle18 {font-family:sans-serif;color:windowtext;}#yiv8177139594 .yiv8177139594MsoChpDefault {font-size:10.0pt;} _filtered #yiv8177139594 {margin:1.0in 1.0in 1.0in 1.0in;}#yiv8177139594 div.yiv8177139594WordSection1 {}#yiv8177139594 _filtered #yiv8177139594 {} _filtered #yiv8177139594 {font-family:Wingdings;} _filtered #yiv8177139594 {} _filtered #yiv8177139594 {font-family:Wingdings;} _filtered #yiv8177139594 {font-family:Symbol;} _filtered #yiv8177139594 {} _filtered #yiv8177139594 {font-family:Wingdings;} _filtered #yiv8177139594 {font-family:Symbol;} _filtered #yiv8177139594 {} _filtered #yiv8177139594 {font-family:Wingdings;}#yiv8177139594 ol {margin-bottom:0in;}#yiv8177139594 ul {margin-bottom:0in;}#yiv8177139594

---

From: Joe Touch <[email-masked]>
Date: Fri, 8 Nov 2019 20:42:52 -0800

The draft is more about time scales than protocols used to sync them. NTP is mentioned largely in its use of UTC. PTP supports a variety of time scales so it doesn’t add much to the discussion.

Joe

> On Nov 8, 2019, at 8:24 AM, Stewart Bryant <[email-masked]> wrote:
> 
> 
> 
>> On 8 Nov 2019, at 15:40, Joe Touch <[email-masked] <mailto:[email-masked]>> wrote:
>>

---

From: Carsten Bormann <[email-masked]>
Date: Sat, 9 Nov 2019 09:30:46 +0100

On Nov 8, 2019, at 16:34, Burleigh, Scott C (US 312B) <scott.c.burleigh=[email-masked]> wrote:
> Unix time (also known as Epoch time, POSIX time,[1] seconds since the Epoch,[2] or UNIX Epoch time[3]) is a system for describing a point in time. It is the number of seconds that have elapsed since the Unix epoch, that is the time 00:00:00 UTC on 1 January 1970, minus leap seconds. Leap seconds are ignored,[4] 

There is a problem with this phrase.
You cannot “ignore” leap seconds if you want Posix time.
To the contrary, you need to subtract every single one of them from the number of seconds you count from the Epoch.

Leap seconds are actively *not counted*, not “ignored”.
Of course, if you think “ignore” means “not count”, you will think the sentence makes sense.
There are time scales that don’t know about leap seconds, such as TAI or GPS (*).
Posix time does know about leap seconds, it needs them to be mostly compatible with civil time (UTC).

(*) The GPS signal indicates the accumulated number of leap seconds since GPS epoch *along with* the monotonic time in GPS time scale (that “ignores” the fact that there are leap seconds).

Sorry for overstressing the semantics here, but from teaching I know that half of the people understand “ignore” as “do not take any notice of”, as TAI does, and only the other half understands that you mean “do not count” as an explicit act of “ignoring”, as in Posix time.

> For example, “The Open Group Base Specifications Issue 7, Rationale: Base Definitions”, section A.4 (General Concepts) says “Coordinated Universal Time (UTC) includes leap seconds. However, in POSI…

“Not applied” has the same problem, maybe slightly less so.

You “apply” leap seconds to Posix time by *not counting* them.

> But that is an implementation expedient, which BP does not care about.  What BP cares about is expressing time as a number of seconds that have elapsed since the Epoch (minus an offset, the number…

That is correct, but it means you can’t have a BP node that doesn’t know about leap seconds (either explicitly or by periodically resetting its clock to the Posix representation of civil time, which in many cases you do anyway because of clock drift).

Grüße, Carsten

---

From: "Burleigh, Scott C (US 312B)" <[email-masked]>
Date: Sat, 9 Nov 2019 21:54:00 +0000

Thank you, Carsten.  Some notes in-line below.

Scott

-----Original Message-----
From: Carsten Bormann <[email-masked]> 
Sent: Saturday, November 9, 2019 12:31 AM
To: Burleigh, Scott C (US 312B) <[email-masked]>
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [dtn] [EXTERNAL] Re: [Last-Call] Genart last call review of draft-ietf-dtn-bpbis-17

	-->  I see your point: Epoch time is simply the number of seconds that have elapsed since the Unix epoch, period.  The "minus" is confusing; "omitting" would have been a little better.

	-->  If you don't have Epoch time, and instead only have UTC, then in order to convert from UTC to the equivalent Epoch time you have to add to your UTC value the applicable number of leap seconds; UTC runs slightly behind Epoch time because it counts more seconds (the leap seconds), which Epoch time does not count.  (At the moment of leap second insertion it takes 2 seconds for UTC to advance from 23:59:59 to 00:00:00 [because the advance from 23:59:59 to 23:59:60 is additionally counted], while over that same 2-second interval the Epoch time will have advanced from 23:59:59 to 00:00:01.)  If you have Epoch time, then in order to convert from Epoch time to the equivalent UTC you have to subtract from your Epoch time value the applicable number of leap seconds, thus retroactively "counting" them.

	-->  Yes.  The sentence could have been written more clearly.

	-->  You're right, an important clarification.

	-->  Not quite true.  You *can* have a BP node that doesn't know about leap seconds, though I admit that this may not be common.  If the only way to implement the function that returns the current DTN time is to consult UTC time and back the leap seconds out then yes, you need to know about leap seconds.  But if the function that returns the current DTN time does so by consulting an accurate local clock that monotonically increases the count of seconds since the Epoch -- which is, for example, what all deep-space spacecraft clocks effectively do -- then no knowledge of leap seconds is needed.

	-->  Spacecraft clocks have been notoriously unstable in the past, but that is changing.  Radiation-hardened on-board electronics are increasingly reliable.  At the outer edge of what we might contemplate in the near term is the deep-space atomic clock, the first instance of which launched in June (https://www.nasa.gov/mission_pages/tdm/clock/index.html).  It may fairly be argued that an atomic clock the size of a toaster oven, massing 16 kg, is far too large and expensive to deploy on a Cubesat.  I think we find, though, that useful devices like these tend to become smaller and less costly as markets for them emerge.

Grüße, Carsten

---

From: "[email-masked]" <[email-masked]>
Date: Mon, 11 Nov 2019 11:05:06 +0000 (UTC)

(That wikipedia page thinks POSIX *is* unix time, and the cited reference
 doesn't seem to support that claim. Anyone want a wikipedia edit war?)

 Scott, when you did the Deep Impact/Epoxi DTN experiments, the
 spacecraft clock was drifting by over a second a day, and clock
 corrections were uploaded before you could do image uploads.
 Yes, notoriously unreliable -- in a harsh environment.

 But this is now going to be addressed with atomic clocks?
 So this is fixing software design problems in hardware?

 I don't have a solution to what I think are difficult problems.
 But I'd rather not see the protocol problems be glossed over.

 Lloyd Wood
 http://lloydwood.users.sourceforge.net/Personal/L.Wood/dtn/

On Sunday, 10 November 2019, 08:54:36 GMT+11, Burleigh, Scott C (US 312B) <scott.c.burleigh=[email-masked]> wrote: 

Scott

-----Original Message-----
From: Carsten Bormann <[email-masked]> 
Sent: Saturday, November 9, 2019 12:31 AM
To: Burleigh, Scott C (US 312B) <[email-masked]>
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [dtn] [EXTERNAL] Re: [Last-Call] Genart last call review of draft-ietf-dtn-bpbis-17

Grüße, Carsten

---

From: "Burleigh, Scott C (US 312B)" <[email-masked]>
Date: Mon, 11 Nov 2019 15:24:49 +0000

Hi, Lloyd.  I don't recall the EPOXI clock drifting that quickly, but certainly it did drift and we did upload clock corrections.  The flow of bundles was not dependent on those corrections; it is not hard to add margin in the time-to-live when bundles are sourced.  But improving the accuracy of the clocks did improve network utilization by enabling the spacecraft to start and stop communication at the beginning and end of each contact rather than a few seconds early or late.

Scott

-----Original Message-----
From: dtn <[email-masked]> On Behalf Of [email-masked]
Sent: Monday, November 11, 2019 3:05 AM
To: Carsten Bormann <[email-masked]>; Burleigh, Scott C (US 312B) <scott.c.burleigh=[email-masked]>
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [dtn] [Last-Call] [EXTERNAL] Re: Genart last call review of draft-ietf-dtn-bpbis-17

 Lloyd Wood

Scott

-----Original Message-----
From: Carsten Bormann <[email-masked]> 
Sent: Saturday, November 9, 2019 12:31 AM
To: Burleigh, Scott C (US 312B) <[email-masked]>
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [dtn] [EXTERNAL] Re: [Last-Call] Genart last call review of draft-ietf-dtn-bpbis-17

Grüße, Carsten

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

---

From: "Burleigh, Scott C (US 312B)" <[email-masked]>
Date: Mon, 11 Nov 2019 21:14:28 +0000

Lloyd, you keep good files!

-----Original Message-----
From: [email-masked] <lloyd.wood=[email-masked]> 
Sent: Monday, November 11, 2019 1:02 PM
To: [email-masked]; Carsten Bormann <[email-masked]>; Burleigh, Scott C (US 312B) <[email-masked]>
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [dtn] [Last-Call] [EXTERNAL] Re: Genart last call review of draft-ietf-dtn-bpbis-17

Scott

a reminder:

Ground System Architectures Workshop, March 2009, where you talked delay at Torrance.

https://csse.usc.edu/GSAW/gsaw2009/s6/burleigh.pdf

second to last slide:

"Spacecraft clock drifted more rapidly than expected – over 1 second per day. Revised clock correction deltas had to be uploaded to ION for each tracking pass."

Leap seconds are noise by comparison... but the bundle protocol's reliance on and expectation of accurate time runs deep.

Lloyd Wood

On Tuesday, 12 November 2019, 02:25:33 GMT+11, Burleigh, Scott C (US 312B) <scott.c.burleigh=[email-masked]> wrote: 

Scott

-----Original Message-----
From: dtn <[email-masked]> On Behalf Of [email-masked]
Sent: Monday, November 11, 2019 3:05 AM
To: Carsten Bormann <[email-masked]>; Burleigh, Scott C (US 312B) <scott.c.burleigh=[email-masked]>
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [dtn] [Last-Call] [EXTERNAL] Re: Genart last call review of draft-ietf-dtn-bpbis-17

 Lloyd Wood

Scott

-----Original Message-----
From: Carsten Bormann <[email-masked]> 
Sent: Saturday, November 9, 2019 12:31 AM
To: Burleigh, Scott C (US 312B) <[email-masked]>
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [dtn] [EXTERNAL] Re: [Last-Call] Genart last call review of draft-ietf-dtn-bpbis-17

Grüße, Carsten

[email-masked]

---

From: "[email-masked]" <[email-masked]>
Date: Mon, 11 Nov 2019 21:01:54 +0000 (UTC)

Scott

a reminder:

second to last slide:

Lloyd Wood

Scott

-----Original Message-----
From: dtn <[email-masked]> On Behalf Of [email-masked]
Sent: Monday, November 11, 2019 3:05 AM
To: Carsten Bormann <[email-masked]>; Burleigh, Scott C (US 312B) <scott.c.burleigh=[email-masked]>
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [dtn] [Last-Call] [EXTERNAL] Re: Genart last call review of draft-ietf-dtn-bpbis-17

 Lloyd Wood

Scott

-----Original Message-----
From: Carsten Bormann <[email-masked]> 
Sent: Saturday, November 9, 2019 12:31 AM
To: Burleigh, Scott C (US 312B) <[email-masked]>
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [dtn] [EXTERNAL] Re: [Last-Call] Genart last call review of draft-ietf-dtn-bpbis-17

Grüße, Carsten

[email-masked]

---

From: "Burleigh, Scott C (US 312B)" <[email-masked]>
Date: Tue, 12 Nov 2019 03:23:17 +0000

I just now realize that what I wrote here may have been confusing: I didn't make it clear that we used BP to upload the clock corrections to EPOXI.  In some contexts that would go without saying, but perhaps not this one.

Specifically, the clock corrections were "utcdelta" commands in "ionrc" files that were encapsulated in bundles; the files were ingested by an on-board instance of the ionadmin utility program.

That is, we uploaded files via BP in order to correct for clock drift, rather than the other way around, and we found it easy to correct a misaligned clock on a bundle node by using the bundle protocol itself.

The mechanism we used for this purpose back in 2008 was relatively clumsy; the new Asynchronous Management protocol will make this process somewhat more graceful.  But the basic principles were demonstrated a long time ago.

Scott

-----Original Message-----
From: Burleigh, Scott C (US 312B) <scott.c.burleigh=[email-masked]> 
Sent: Monday, November 11, 2019 7:25 AM
To: [email-masked]; Carsten Bormann <[email-masked]>; Burleigh, Scott C (US 312B) <[email-masked]>
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: RE: [dtn] [Last-Call] [EXTERNAL] Re: Genart last call review of draft-ietf-dtn-bpbis-17

Scott

-----Original Message-----
From: dtn <[email-masked]> On Behalf Of [email-masked]
Sent: Monday, November 11, 2019 3:05 AM
To: Carsten Bormann <[email-masked]>; Burleigh, Scott C (US 312B) <scott.c.burleigh=[email-masked]>
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [dtn] [Last-Call] [EXTERNAL] Re: Genart last call review of draft-ietf-dtn-bpbis-17

 Lloyd Wood

Scott

-----Original Message-----
From: Carsten Bormann <[email-masked]> 
Sent: Saturday, November 9, 2019 12:31 AM
To: Burleigh, Scott C (US 312B) <[email-masked]>
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [dtn] [EXTERNAL] Re: [Last-Call] Genart last call review of draft-ietf-dtn-bpbis-17

Grüße, Carsten