Subject: [dtn] I-D Action: draft-ietf-dtn-bpbis-15.txt

From: [email-masked]
Date: Fri, 18 Oct 2019 14:02:50 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Delay/Disruption Tolerant Networking WG of the IETF.

        Title           : Bundle Protocol Version 7
        Authors         : Scott Burleigh
                          Kevin Fall
                          Edward J. Birrane
	Filename        : draft-ietf-dtn-bpbis-15.txt
	Pages           : 61
	Date            : 2019-10-18

Abstract:
   This Internet Draft presents a specification for Bundle Protocol,
   adapted from the experimental Bundle Protocol specification
   developed by the Delay-Tolerant Networking Research group of the
   Internet Research Task Force and documented in RFC 5050.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-dtn-bpbis/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-dtn-bpbis-15
https://datatracker.ietf.org/doc/html/draft-ietf-dtn-bpbis-15

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-dtn-bpbis-15

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Brian Sipos <[email-masked]>
Date: Mon, 21 Oct 2019 21:42:13 +0000

Scott,
The new text leaves me confused about the correct encoding and interpretation of the CRC values themselves. The earlier text said that the values are a "sequence of bytes" representing an integer. The new -15 text says that the values are CBOR integer type but still talks about sequences of bytes.

For some background on my desire for specific requirements here: there are many COTS CBOR encoders today (mostly for higher-level languages, e.g. Python and ECMAScript) which do not allow a fine-grained level of control about how numbers are CBOR-encoded. These COTS encoders don't have an API to tell the encoder to make a non-shortest-length output; so it's not possible to implement the BPv7-CRC-required behavior of:

   ...including the CRC field itself, which for this purpose SHALL be
   temporarily populated with the value zero.

When these encoders see a native integer/number value of zero the output is always the encoded bytestring 0x00. My opinion is that unnecessarily limits environments which BPv7 can be used in (at least when CRC handling is intended). I understand that these may not be expected use environments for BP, so take all of this with a grain of salt.
Thanks,
Brian S.

________________________________
From: dtn <[email-masked]> on behalf of [email-masked] <[email-masked]>
Sent: Friday, October 18, 2019 17:02
To: [email-masked] <[email-masked]>
Cc: [email-masked] <[email-masked]>
Subject: [dtn] I-D Action: draft-ietf-dtn-bpbis-15.txt

Abstract:

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

---

From: "Burleigh, Scott C (US 312B)" <[email-masked]>
Date: Mon, 21 Oct 2019 22:03:40 +0000

Thanks, Brian.  How about byte strings?  Could we say that the CRC SHALL be represented as a CBOR byte string of length either 2 or 4, and that the content of each such byte string is to be processed as an integer in network byte order?

Scott

From: Brian Sipos <[email-masked]>
Sent: Monday, October 21, 2019 2:42 PM
To: [email-masked]; Burleigh, Scott C (US 312B) <[email-masked]>
Subject: [EXTERNAL] Re: [dtn] I-D Action: draft-ietf-dtn-bpbis-15.txt

Scott,

________________________________
From: dtn <[email-masked]<mailto:[email-masked]>> on behalf of [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>
Sent: Friday, October 18, 2019 17:02
To: [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>
Subject: [dtn] I-D Action: draft-ietf-dtn-bpbis-15.txt

Abstract:

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

---

From: Felix Walter <[email-masked]>
Date: Tue, 22 Oct 2019 08:41:31 +0200

Dear Scott,

I agree with your proposed update to the text. This reflects how we
understood it previously and have implemented it in uPCN. Works quite
well for us.

Felix

On 22.10.19 00:03, Burleigh, Scott C (US 312B) wrote:
>
> Thanks, Brian.  How about byte strings?  Could we say that the CRC
> SHALL be represented as a CBOR byte string of length either 2 or 4,
> and that the content of each such byte string is to be processed as an
> integer in network byte order?
>
>  
>
> Scott
>
>  
>
> *From:* Brian Sipos <[email-masked]>
> *Sent:* Monday, October 21, 2019 2:42 PM
> *To:* [email-masked]; Burleigh, Scott C (US 312B)
> <[email-masked]>
> *Subject:* [EXTERNAL] Re: [dtn] I-D Action: draft-ietf-dtn-bpbis-15.txt
>
>  
>
> Scott,
>
> The new text leaves me confused about the correct encoding and
> interpretation of the CRC values themselves. The earlier text said
> that the values are a "sequence of bytes" representing an integer. The
> new -15 text says that the values are CBOR integer type but still
> talks about sequences of bytes.
>
>  
>
> For some background on my desire for specific requirements here: there
> are many COTS CBOR encoders today (mostly for higher-level languages,
> e.g. Python and ECMAScript) which do not allow a fine-grained level of
> control about how numbers are CBOR-encoded. These COTS encoders don't
> have an API to tell the encoder to make a non-shortest-length output;
> so it's not possible to implement the BPv7-CRC-required behavior of:
>
> When these encoders see a native integer/number value of zero the
> output is always the encoded bytestring 0x00. My opinion is that
> unnecessarily limits environments which BPv7 can be used in (at least
> when CRC handling is intended). I understand that these may not be
> expected use environments for BP, so take all of this with a grain of
> salt.
>
> Thanks,
>
> Brian S..
>
>  
>
> ------------------------------------------------------------------------
>
> *From:*dtn <[email-masked] <mailto:[email-masked]>> on
> behalf of [email-masked] <mailto:[email-masked]>
> <[email-masked] <mailto:[email-masked]>>
> *Sent:* Friday, October 18, 2019 17:02
> *To:* [email-masked] <mailto:[email-masked]>
> <[email-masked] <mailto:[email-masked]>>
> *Cc:* [email-masked] <mailto:[email-masked]> <[email-masked]
> <mailto:[email-masked]>>
> *Subject:* [dtn] I-D Action: draft-ietf-dtn-bpbis-15.txt
>
>  
>
>
> [email-masked] <mailto:[email-masked]>

---

From: Brian Sipos <[email-masked]>
Date: Tue, 22 Oct 2019 14:00:16 +0000

Scott,
Yes that makes sense. If you want to be explicit with code points, as your last edit does, they will always be major type 2 and additional information 2 or 4 (no indefinite-lengths allowed).
________________________________
From: Burleigh, Scott C (US 312B) <[email-masked]>
Sent: Monday, October 21, 2019 18:03
To: Brian Sipos <[email-masked]>; [email-masked] <[email-masked]>
Subject: RE: [dtn] I-D Action: draft-ietf-dtn-bpbis-15.txt

Scott

Scott,

Thanks,

Brian S.

Abstract: