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

"lloyd.wood@yahoo.co.uk" <lloyd.wood@yahoo.co.uk> Thu, 07 November 2019 03:17 UTC

Return-Path: <lloyd.wood@yahoo.co.uk>
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 E33B21200F3 for <dtn@ietfa.amsl.com>; Wed, 6 Nov 2019 19:17:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.997
X-Spam-Level:
X-Spam-Status: No, score=-1.997 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yahoo.co.uk
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 B2AOAhKCiYx4 for <dtn@ietfa.amsl.com>; Wed, 6 Nov 2019 19:17:03 -0800 (PST)
Received: from sonic309-26.consmr.mail.ir2.yahoo.com (sonic309-26.consmr.mail.ir2.yahoo.com [77.238.179.84]) (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 76FEB120052 for <dtn@ietf.org>; Wed, 6 Nov 2019 19:17:02 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.co.uk; s=s2048; t=1573096619; bh=NVRReXRl13lkJwgS7j1UOvAfhpRiPuO/YSNZfIp0nv4=; h=Date:From:To:Cc:In-Reply-To:References:Subject:From:Subject; b=XE0TSgEH/HV+KV/geIVi9dqf9599cmempu85T3phmwOR9PVdZgd17wyHJYQS2h74wqfTAN2sqFy4SbNoeZNFkp/aUVfAyJ2YnhDQveLAZSu2awjNSv38Y3bXv3su+nUi/wHfjM4i4Va1u9s44NgAcfRTSpcSMsqKurRPHIsFrGQrmOEHnrQTDndhXnhR2YDS25k4Y76qEq08AoSiNka9I2HN5j901AWJwLaFLjdxhzSvv8NG7MGN6HDbbLH6ZcBzMoAIdFvc6+EKI1WbOAouD5g+4qRj5pT4fuiSVQT5KjcSsDLmVYmFo51iI14WZ8fWySgEB7RYQArZXfqRODWUyg==
X-YMail-OSG: Gy8mY28VM1lw_5weh2_oUiF.u5BTVMSAbzOZjfEE_xnKsD6k2XRaBL2_cNpMdCZ TBsVHUA_zFz1VlQCvqZ73cKGhVSCpbiuaO4Tg2D0wu3qU0as78W.MQHZVZpE2ROS7BQ424QG0bYw X9Es_80dA2crHkxVqpJvnr37zbJuKrJmCVR22k3sRqF7Lcx7SFkc1ptiXmPx2PZEy2wssMiQ5Q8r t5dcU8I8jYa2XOAxojFfw686oIG9geuRM.BF5ukf1ven9XSJVmlKm3RZ1MtQ06.nqbLrBtx0AXLa BOhuYm3r.jqWQSNjvfr9SHIt2.ixgqfocSzABdbAS1EJxzc6Zo0tnkxaGcaIBWgSB9zdM.sbqq7F P65rJjuVRRSXSl1OqRtFKOkG3I9C_N6JmQozpawCrSMgCu3cEbgJBJWgQAPlQDKoTPfhSmGfA52l r7dJtLQn5RrT1bSDGrRc.K32FsDYmLJC.ojqT4I44K5PkR3NFAVs2qMlKptY1j0XtLBRTTGKijss qZusgHz.NalFHkuHNbL6xzzEIPoSOIKJ1W1hLsYCuc60yziSGJZ7eFyd9JVAIMAlrwRrELCDa53L IgTDQ_XPA9LwYTQ3ARO9EbFV6fAZbLNW76seBsmvAaQYf.v9mj_eNskrQYPi8nZWhKNeEM8sJR82 qEDywwBUGU.v1HkJoWSQ7KPeaEQ.rMSsdVa.t_Tj9C_t4KqH5XLnEPcGfo8t6d7ADNpDaUUYmo7X ssdtw15IF8CnPHQ1MX6091SnbIuTQdhBUWZXHQCPK3Y3HAjlX67F0sxsJlcaBdZUfkOXfHSb4GOc OuUk3Ae5I8kRDoiAj_9m7ya1AZHYGV72S_9n0R3Krz.R_I41CMyJJ2mqd8tgmcVmfebiCnNy0JdD VpS_nSJdNNwRvSKK7iGbfsTCb3k93PiOE2Mj4bPeCf6.SzIot2MoeL.CcNc8MqzaDdJ7RiNPImoO a4tqbsehiEcaha8ZFNReHfoYQWNpQRLLMQl0T8zQ5xXNt77ZXqSqgdiScjsK2rGBOHhns5xb5BXE zQpcPOOzxr8.G67TwYKbpUh8ZLBl1dVHnDPtMKjyNr8SMbiYAbEPoZ_NGBtyeXtmkeIuN62QL5bc mDgFsNvKl_cxqOYJ_nuPNDoCtNQGoTvnQ7U.Od6ngqR8DJnaqr.xjl0jMSnhMGzjN.J1bmLQ1wpu YF97IO6EJm5XXqUfFgxPuzqz8oO3XpOsXPHChbkXaZlwxTzRa2FYmqqwwwcc3xrIb3rz5EqNRocn p2hP.L43WbCgytRwMEOQhdV9EEgInrW7JdBaE6Ik8wh47qN_MztZp7QH3eyPqg4OSPdoJy.jcYBP 23wqZi81Ox5gQId03gvk8UiklV2DlBAKl25A-
Received: from sonic.gate.mail.ne1.yahoo.com by sonic309.consmr.mail.ir2.yahoo.com with HTTP; Thu, 7 Nov 2019 03:16:59 +0000
Date: Thu, 7 Nov 2019 03:06:56 +0000 (UTC)
From: "lloyd.wood@yahoo.co.uk" <lloyd.wood@yahoo.co.uk>
To: gen-art@ietf.org, Stewart Bryant <stewart.bryant@gmail.com>
Cc: last-call@ietf.org, draft-ietf-dtn-bpbis.all@ietf.org, dtn@ietf.org
Message-ID: <1160884509.13681.1573096016520@mail.yahoo.com>
In-Reply-To: <157306815414.27362.18239257168598208900@ietfa.amsl.com>
References: <157306815414.27362.18239257168598208900@ietfa.amsl.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_Part_13680_182777200.1573096016515"
X-Mailer: WebService/1.1.14680 YMailNorrin Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:70.0) Gecko/20100101 Firefox/70.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/dtn/n3jAbwb2dkORYmhfi72rDEhCyao>
Subject: Re: [dtn] 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 03:17:05 -0000

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 lloyd.wood@yahoo.co.uk http://about.me/lloydwood 

    On Thursday, 7 November 2019, 06:22:44 GMT+11, 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.