Subject: [dtn] Robert Wilton's No Objection on draft-ietf-dtn-bpbis-29: (with COMMENT)

From: Robert Wilton via Datatracker <[email-masked]>
Date: Tue, 01 Dec 2020 08:43:27 -0800

Robert Wilton has entered the following ballot position for
draft-ietf-dtn-bpbis-29: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-dtn-bpbis/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Hi,

Thank you for this document.

Just a few minor observations/comments.  Quite possibly only the last comment
is actionable, and the rest are just observations.

1) Figure 2: Components of a Bundle Node

It would be nice if this diagram is not split across page boundaries, hopefully
the RFC editor can sort this out.

2) 4. Bundle Format

   Each bundle SHALL be a concatenated sequence of at least two blocks,
   represented as a CBOR indefinite-length array

It wasn't immediate obvious why this restriction was here, I presume that this
is to ensure that there is a canonical representation?

4.1.1. CRC Type
I was surprised to see that CRC-16 is also supported.  I presume that reasoning
for this is because blocks could be small, and hence the overhead from always
using CRC32 was regarded as being too much?

4.1.2. CRC
I was also slightly surprised that these are encoded as fixed length byte
strings rather than as unsigned integers.  I presume that this is done to make
them fixed length and also easier to zero out when performing the CRC
calculation?

It looks like RFC 2119 language used to define the bundle format both in
section 4 and 4.2.1.  Possibly it would be better to not use RFC 2119 language
in the intro of section 4, and instead refer to 4.2.1 for the normative
definition?

Regards,
Rob

---

From: "Burleigh, Scott C (US 312B)" <[email-masked]>
Date: Fri, 4 Dec 2020 17:10:42 +0000

Hi, Rob.  Some thoughts on your comments, in-line below.

Scott

-----Original Message-----
From: Robert Wilton via Datatracker <[email-masked]> 
Sent: Tuesday, December 1, 2020 8:43 AM
To: The IESG <[email-masked]>
Cc: [email-masked]; [email-masked]; [email-masked]; Fred Templin <[email-masked]>; [email-masked]
Subject: [EXTERNAL] Robert Wilton's No Objection on draft-ietf-dtn-bpbis-29: (with COMMENT)

Hi,

>	Yes, that's what I'm hoping.

2) 4. Bundle Format

>	Yes, we definitely wanted a canonical representation.

4.1.1. CRC Type

>	That's right.  For some extremely resource-limited platforms, an extra 16 bits in every CRC can make a difference in performance.

4.1.2. CRC

>	Exactly.

>	Since the language in 4.2.1 does not contradict the language in the introductory paragraphs of section 4, I don't see the harm; I think it makes the document a little more readable, providing useful context for the discussion of blocks.  The text at the start of section 4 has to stay where it is, as nothing in the following sections makes any sense without it.  If we were going to make a change, I would frame those introductory section 4 paragraphs as a distinct section and migrate all of 4.2.1 into that new section.  Would that be better?

Regards,
Rob

---

From: "Rob Wilton (rwilton)" <[email-masked]>
Date: Fri, 4 Dec 2020 17:44:28 +0000

Hi Scott,

Please see inline ... 

> From: Burleigh, Scott C (US 312B) <[email-masked]>
> Sent: 04 December 2020 17:11
> To: Rob Wilton (rwilton) <[email-masked]>; The IESG <[email-masked]>
> Cc: [email-masked]; [email-masked]; [email-masked]; Fred
> Templin <[email-masked]>
> Subject: RE: [EXTERNAL] Robert Wilton's No Objection on draft-ietf-dtn-
> bpbis-29: (with COMMENT)
> 
> Cc: [email-masked]; [email-masked]; [email-masked]; Fred
> Templin <[email-masked]>; [email-masked]
> >	That's right.  For some extremely resource-limited platforms, an
> extra 16 bits in every CRC can make a difference in performance.
> 
> 4.1.2. CRC
> >	Since the language in 4.2.1 does not contradict the language in the
> introductory paragraphs of section 4, I don't see the harm; I think it
> makes the document a little more readable, providing useful context for
> the discussion of blocks.  The text at the start of section 4 has to stay
> where it is, as nothing in the following sections makes any sense without
> it.  If we were going to make a change, I would frame those introductory
> section 4 paragraphs as a distinct section and migrate all of 4.2.1 into
> that new section.  Would that be better?
[RW] 

Note, just for clarity.  I'm not objecting to their being some introductory text in section 4 giving an overview of a bundle structure, but more that it uses 2119 language and it looks like some rules are defined in the section 4 intro (e.g., the latter part of the paragraph) and some are defined in section 4.2.1.  So, an alternative solution here would be to ensure that the normative 2119 language is in section 4.2.1, and the intro text is just an introduction -   it can still give a quick overview of the structure but doesn't use 2119 language.

But I would also be okay with the approach that you suggest because it allows it to be only defined once.  However, I would potentially go further.  In a sense, perhaps if you move the whole of "4.2 Bundle Representation" above "4.1 BP Fundamental Data Structures", then the bundle structure is being decomposed as the reader progresses through the chapter.  I.e. the bundle is defined, then the blocks, then the fields within those blocks.

However, this may be a bigger change than you wish to make.  This is a non-blocking comment from an observation as I was reading the document, so I will leave it entirely to your discretion as whether you wish to restructure this.

Regards,
Rob

---

From: "Burleigh, Scott C (US 312B)" <[email-masked]>
Date: Fri, 4 Dec 2020 18:15:57 +0000

Thank you, Rob.  I'll give this some more thought.

Scott

-----Original Message-----
From: Rob Wilton (rwilton) <[email-masked]> 
Sent: Friday, December 4, 2020 9:44 AM
To: Burleigh, Scott C (US 312B) <[email-masked]>; The IESG <[email-masked]>
Cc: [email-masked]; [email-masked]; [email-masked]; Fred Templin <[email-masked]>
Subject: RE: [EXTERNAL] Robert Wilton's No Objection on draft-ietf-dtn-bpbis-29: (with COMMENT)

Hi Scott,

Please see inline ... 

> Cc: [email-masked]; [email-masked]; [email-masked]; 
> Fred Templin <[email-masked]>
> Cc: [email-masked]; [email-masked]; [email-masked]; 
> Fred Templin <[email-masked]>; [email-masked]
> Subject: [EXTERNAL] Robert Wilton's No Objection on 
> draft-ietf-dtn-bpbis-
> 29: (with COMMENT)
> 
> Just a few minor observations/comments.  Quite possibly only the last 
> comment is actionable, and the rest are just observations.
> 
> It would be nice if this diagram is not split across page boundaries, 
> hopefully the RFC editor can sort this out.
> 
> It wasn't immediate obvious why this restriction was here, I presume 
> that this is to ensure that there is a canonical representation?
> 
> I was surprised to see that CRC-16 is also supported.  I presume that 
> reasoning for this is because blocks could be small, and hence the 
> overhead from always using CRC32 was regarded as being too much?
> 
> I was also slightly surprised that these are encoded as fixed length 
> byte strings rather than as unsigned integers.  I presume that this is 
> done to make them fixed length and also easier to zero out when 
> performing the CRC calculation?
> 
> >	Exactly.
> 
> It looks like RFC 2119 language used to define the bundle format both 
> in section 4 and 4.2.1.  Possibly it would be better to not use RFC 
> 2119 language in the intro of section 4, and instead refer to 4.2.1 
> for the normative definition?
> 
> makes the document a little more readable, providing useful context 
> for the discussion of blocks.  The text at the start of section 4 has 
> to stay where it is, as nothing in the following sections makes any 
> sense without it.  If we were going to make a change, I would frame 
> those introductory section 4 paragraphs as a distinct section and 
> migrate all of 4.2.1 into that new section.  Would that be better?
[RW] 

Regards,
Rob