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

["Rob Wilton (rwilton)" <[e-mail]>]

Hi Scott,

Please see inline ... 

> -----Original Message-----
> From: Burleigh, Scott C (US 312B) <[e-mail]>
> Sent: 04 December 2020 17:11
> To: Rob Wilton (rwilton) <[e-mail]>; The IESG <[e-mail]>
> Cc: [e-mail]; [e-mail]; [e-mail]; Fred
> Templin <[e-mail]>
> Subject: RE: [EXTERNAL] Robert Wilton's No Objection on draft-ietf-dtn-
> bpbis-29: (with COMMENT)
> 
> Hi, Rob.  Some thoughts on your comments, in-line below.
> 
> Scott
> 
> -----Original Message-----
> From: Robert Wilton via Datatracker <[e-mail]>
> Sent: Tuesday, December 1, 2020 8:43 AM
> To: The IESG <[e-mail]>
> Cc: [e-mail]; [e-mail]; [e-mail]; Fred
> Templin <[e-mail]>; [e-mail]
> Subject: [EXTERNAL] Robert Wilton's No Objection on draft-ietf-dtn-bpbis-
> 29: (with COMMENT)
> 
> Robert Wilton has entered the following ballot position for
> draft-ietf-dtn-bpbis-29: No Objection
> 
> ----------------------------------------------------------------------
> 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.
> 
> >	Yes, that's what I'm hoping.
> 
> 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?
> 
> >	Yes, we definitely wanted 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?
> 
> >	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
> 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?
> 
> >	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


> 
> Regards,
> Rob
> 
>