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

Stewart Bryant <stewart.bryant@gmail.com> Thu, 07 November 2019 13:02 UTC

Return-Path: <stewart.bryant@gmail.com>
X-Original-To: dtn@ietfa.amsl.com
Delivered-To: dtn@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BEB0E120815; Thu, 7 Nov 2019 05:02:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OrDnMUYjGfTo; Thu, 7 Nov 2019 05:02:52 -0800 (PST)
Received: from mail-wm1-x336.google.com (mail-wm1-x336.google.com [IPv6:2a00:1450:4864:20::336]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D5DFE12003F; Thu, 7 Nov 2019 05:02:51 -0800 (PST)
Received: by mail-wm1-x336.google.com with SMTP id z19so2327566wmk.3; Thu, 07 Nov 2019 05:02:51 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=Go8KNQsHtBYtIRWsZY1uc4qFV8sffmaixQlPYX3QNUE=; b=W3qThEu3XK2HLLr5V02tbs5m88iLvzk1ko3eP461Ww67t6ZypfXdPEb+yamXVp//e7 fNNjpLvH/jkAkA5uvfkmXlP0UYbKOD0AxsCePwpixb2QOD6MKq4V8Z8DRcmfghQ6VKn8 Drcxs7jZgMTpUdXziNjcjexAboYtceNJqnkNeM0sNNXkAkm24hq+d3s68EX08g6/VFQN 2K814xaiuu5abZ1z6gWBHZh35m3oCCHQDITpnoN12suIhsju7PyLq6oHX+O9uLCa3IV9 j0sG1DJKmd349aSckezERiV2XEDQT2dnWcyOIGZ6dDJVzW7NFTMmYhkCDTTzgJrjFtm7 v0GQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=Go8KNQsHtBYtIRWsZY1uc4qFV8sffmaixQlPYX3QNUE=; b=pbgSgSRzPQc7G63BHGo9Z/acuA5jQJA7gr7lqPjsyViylYQTIZa1qfsA0HHIWWXS3f PiutFVw0xkkksW6FTzBBl+/CsyQtqjk4w0CX0TL/6zDklgQBFcatVQJLg425ekP+lay/ SeLk+fyJcU2z40BkWWLQObP9ramvSaq/jo0Z2fIsVy4QD+hA1TKWdGWpUzv0SIAZ26ZX 34hoJPOf22CtywVAUJRN5PnxS3ipqJRrWBD7S1XvtMwq9tstVHjzWHT/Zz+bsrojLZpB XyeqBiiXHzfFVbzG+Gmecb0g59db9AwDQMai02XP0C1fFvBoGAyP6y3RncpO3dIu7HQo rUag==
X-Gm-Message-State: APjAAAXCi8043PKLvy7hxJFCQf0hHzpkKQZPGsSZdP36br8hA4q9iX3H ehRKRmLUJ3lqXJIfkZe/5Qs=
X-Google-Smtp-Source: APXvYqz9y3qlpnQQqETWVDY1usm9vLc6PSRnAbh818D9wM0qpv+IWUZEmWtjMEbyxMYt3fxHdnp/gQ==
X-Received: by 2002:a1c:28d4:: with SMTP id o203mr2842612wmo.147.1573131769977; Thu, 07 Nov 2019 05:02:49 -0800 (PST)
Received: from [192.168.178.46] ([62.3.64.16]) by smtp.gmail.com with ESMTPSA id a10sm3593358wrg.0.2019.11.07.05.02.48 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 07 Nov 2019 05:02:49 -0800 (PST)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3601.0.10\))
From: Stewart Bryant <stewart.bryant@gmail.com>
In-Reply-To: <157306815414.27362.18239257168598208900@ietfa.amsl.com>
Date: Thu, 7 Nov 2019 13:02:18 +0000
Cc: gen-art@ietf.org, last-call@ietf.org, draft-ietf-dtn-bpbis.all@ietf.org, dtn@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <E3FCFE3F-A50C-4C00-A52B-6B24B75B3F27@gmail.com>
References: <157306815414.27362.18239257168598208900@ietfa.amsl.com>
To: Stewart Bryant <stewart.bryant@gmail.com>
X-Mailer: Apple Mail (2.3601.0.10)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dtn/zAw3cqxSDLizylviN3w0OovksnM>
Subject: Re: [dtn] [Gen-art] Genart last call review of draft-ietf-dtn-bpbis-17
X-BeenThere: dtn@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Delay Tolerant Networking \(DTN\) discussion list at the IETF." <dtn.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dtn>, <mailto:dtn-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dtn/>
List-Post: <mailto:dtn@ietf.org>
List-Help: <mailto:dtn-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dtn>, <mailto:dtn-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 07 Nov 2019 13:02:55 -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 <noreply@ietf.org>; wrote:
> 
> 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 dtn@ietf.org. 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.
> 
> 
> _______________________________________________
> Gen-art mailing list
> Gen-art@ietf.org
> https://www.ietf.org/mailman/listinfo/gen-art