[dtn-interest] Re: [IRSG] Looking for reviewers for dtnrg's bundle protocol spec...

[Stephen Farrell <[e-mail]>]

Thanks Sally!

I can answer your "intended status" question: this, as, I
believe, all IRTF protocol specs, is targeted at becoming
an experimental RFC. So, not on the standards-track, but
it is apropriate to use MUST/SHOULD etc.

Cc'ing the dtn-interest list, so DTNRG get to see your good
comments,

Stephen.

Sally Floyd wrote:
> My review for draft-irtf-dtnrg-bundle-spec-08 is below.
> 
> - Sally
> http://www.icir.org/floyd/
> 
> Review of Bundle Protocol Specification,
> draft-irtf-dtnrg-bundle-spec-08.txt.
> 
> I read the Bundle Protocol Specification, and it seems ok to me.
> My feedback below is mostly about presentation.
> 
> IRTF and standards documents:
> It is a little odd to read an IRTF document that is so clearly a
> protocol specification, instead of a description of an architecture
> as in draft-irtf-dtnrg-arch.  (E.g., the document specifies block
> headers, and uses occasional RFC-2119 language (RECOMMENDED,
> OPTIONAL).) I assume the IRTF guidelines are that this is ok?
> Is this intended for Informational, or something else?
> 
> Presentation:
> Compared to draft-irtf-dtnrg-arch, this is not an easy-to-read
> document.  The writing is not the clearest - it strikes me as overly
> formal.  It would be worth considering whether the suggestions in
> RFC 4101 on "Writing Protocol Models" would be useful to make the
> document more readable.  (I understand that draft-irtf-dtnrg-bundle-spec
> builds on the general presentation in draft-irtf-dtnrg-arch, but
> even so, it is possible that more could be done.)  An example of a
> section written in part in response to RFC 4101 is the Overview
> (Section 4) of RFC 4340.
> 
> 
> Example Suggestions about Presentation:
> Some examples about presentation are given below.
> 
> I would have found a paragraph at the end of Section 1 useful
> saying "Section 2 will do this" and "Section 3 will do that".
> I kept waiting for the discussion of the protocol, and it isn't
> really there.
> 
> In Section 2.1, when it says that a bundle consists of two or more
> blocks, it would be good to add a reference to Section 3.
> 
> Section 2.1:
> "utilizes" -> "uses"
> 
> "The application agent in turn has two elements, an
> administrative element and an application-specific element." ->
> "The application agent has an
> administrative element and possibly an application-specific element."
> 
> In the definition of a registration, I would say in the first
> sentence that a registration is either active or passive.
> E.g., "A registration characterizes a node's membership in a
> bundle endpoint, and at any time is either Active or Passive."
> 
> Section 2.1, last sentence:
> You might want to say here that a bundle has at most one custodian.
> 
> Section 3.2, first sentence:
> A pointer to Section 3.6 for the discussion of the primary bundle
> block would be useful.
> 
> Section 3.3:
> "The significance of the values in all currently defined positions of
> this bit string, in order from least-significant position (labeled
> '1') to most-significant (labeled '21'), are described here." ->
> "The Bundle Processing Control Flags field is described here
> (starting with the least-significant bit position, labeled '1') ."
> 
> Even better would be a graphic:
> 
>    0                          1                             2
>    1  2  3  4  5  6  7  8  9  0  1  2  3  4  5  6  7  8  9  0  1
>   +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
>   |  General flags     |  Class of Service  |   Status Report    |
>   |                    |                    |   Request Flags    |
>   +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
> 
> (Or for better formatting:  
> 
> (Though the graphic could look better labeling the
> least significant bit as '0' instead of '1'.)
> 
> Section 3.6:
> Why not say the following:
> "All of fields that are SDNVs are of variable-length.  The field
> sizes shown here for SDNVs are for convenience in representation."
> Instead of having to say it again for every field.
> 
> In some places Bundle Protocol is capitalized, but in other places
> it isn't.  "bundle protocol agent" -> "Bundle Protocol agent" or
> "BP agent"?  (From someone who is used to "TCP agent".)
> 
> In Section 4, 4.6 on "Bundle reception" could come earlier,
> (before "Bungle expiration", for example).
> 
> Section 6:  For the convergence layer, a short example of what
> is done in the convergence layer for TCP would be useful.
> 
> 
> Nits: The references need to be updated (for the ones that are
> internet-drafts).