Re: [dtn] I-D Action: draft-ietf-dtn-bpbis-14.txt

["Burleigh, Scott C (US 312B)" <[e-mail]>]

Hi, Magnus.  Responses in-line as well (---->>), with points of agreement 
removed.

Scott

-----Original Message-----
From: Magnus Westerlund <[e-mail]>
Sent: Tuesday, September 17, 2019 4:51 AM
To: Burleigh, Scott C (US 312B) <[e-mail]>
Cc: [e-mail]; [e-mail]
Subject: [EXTERNAL] Re: [dtn] I-D Action: draft-ietf-dtn-bpbis-14.txt

Hi,

Please see inline for comments.


On Fri, 2019-09-13 at 03:14 +0000, Burleigh, Scott C (US 312B) wrote:
> Hi, Magnus.  Responding here (-->) only to the points that still
> remain open:
>
> -----Original Message-----
> From: Magnus Westerlund <[e-mail]>
> Sent: Thursday, September 12, 2019 5:00 AM
> To: [e-mail]; [e-mail]
> Subject: [EXTERNAL] Re: [dtn] I-D Action: draft-ietf-dtn-bpbis-14.txt
>
> Hi,
>
> I have reviewed how this document addresses my AD comments.

...

> > 2.       Section 4.1.6:
> >
> > I think the format and definition of this field are insufficient.
> > It
> > is lacking a reference or a normative description of what "Unix
> > Epoch
> > Time" in an unsigned int format actually is. Is the intention here
> > to
> > simply measure the number of seconds since the start of year 2000?
> > Which Unix epoch time is not due to leap seconds. And I become
> > uncertain as UTC time scale is something else than Unix Epoch time
> > at
> > least when it comes to leap seconds handling. Due to that Unix Time
> > have discontinuities in the time scale at leap seconds I would
> > recommend strongly against using it. Select UTC or TAI depending on
> > where you want the leap second handling pain to exist.
> >
> > Also, you specified only CBOR unsinged integer which is a
> > representation that can use 64-bit and thus not have the issues
> > with
> > 32-bit signed integer seconds epochs that regular unix time has,
> > but
> > that should probably be made explicit that it is expected to handle
> > that. Even if the first wrap of this unsigned 32-bit format will
> > not
> > occur until 2136.
> >
> > And please provide necessary normative references, not informative
> > ones.
>
> The new text I think is good. My only comments are that I the I was
> unable to google for the specific [EPOCH] reference.
>
> 	-->  I googled "Unix programmer's manual 1974" and the top
> entry returned was
> https://protect2.fireeye.com/url?k=c009b4e1-9cddb28c-c009f47a-867011091b6c-4fe5a255ffb263c1&q=1&u=https%3A%2F%2Fwww.tuhs.org%2FArchive%2FDistributions%2FResearch%2FDennis_v5%2Fv5man.pdf
> .

And I tried version and not publication year.

Maybe you should include the URL in the reference.

	---->>	Sure, I'll do that.
 ...

> > 14.   Section 6
> > I fail to see any discussion of how the sender of a status report
> > should set the lifetime and max hop. Can it actually take that
> > information from the Bundle it is reporting on?
>
> If I remember correclty the discussion was that this is
> implementation
> and usage specific and there is lack of experience to provide
> explicit
> recommendations.
>
> 	-->  I think that's right.  Do we need to say something to this
> effect explicitly in the specification, or is this item resolved?
>

I think it is a point to be explicit about this being implementation
and usage specification.

	---->>	Okay, I will add language.

> >    This document defines the following additional Bundle Protocol
> > block
> >    types, for which values are to be assigned from the Bundle
> >    Administrative Record Types namespace [RFC6255]:
> >
> > First of all according to the registry, this registry is actually
> > created by RFC 7116.
> >
> > This and the observation that the things you attempt to register in
> > this registry you are actual called Bundle Block Types in your
> > document. Thus, I have to ask are you actually addressing the right
> > registry, or is the issue that you actually need per version
> > specific
> > registries for example Bundle Block Types? If it is the later, then
> > lets define new registries. Possibly there should be a new major
> > page
> > for BPv7. Not having read all the old documents, you likely have to
> > consider which registries are version specific and which are not.
>
> Apparently needs more discussion. See seperate thread.
>
> 	-->  Right, this is pending resolution on the mailing list.
>
> > 16. Section 10:
> >
> > For the new registry, do you have any requirements for
> > registrations
> > that should be written out. And in addition any criteria you want
> > the
> > expert to consider when approving or rejecting registries? And is
> > this registry version 7 specific or not?
>
> So, I think this question is still relevant for the new registries
> with
> Specification Required policy. It is good to be explicit about what
> information should be provided in a registration. Don't forget for
> example that you maybe should include in the registry who has the
> change control over a registry entry.
>
> 	-->  The requests for new registries in section 10 are modeled
> on the requests in RFC 6255 for the DTN registries that currently
> exist.  Can you point me to an example of a better model that we
> should be following?

One example of this type of registrations are the IANA Considerations
in this document:

https://datatracker.ietf.org/doc/draft-ietf-quic-transport/

	---->>	Great!  I will revise along those lines.

> > 20.   Optional CRCs
> >
> > Why are the primary block CRC optional? I assume the intention with
> > it is to do a verification that the primarily block with the
> > addressing information hasn't become corrupted in the transmission
> > between nodes, similar to the checksums we have in other protocols.
> > Under which conditions will not using it be a reasonable idea? Are
> > you expecting other mechanisms to cover for it, or are you
> > reasoning
> > that having corrupted bundles being delivered to the wrong places
> > is
> > not an issue? As the primarily block is the main addressing part, I
> > would think the considerations that went into discussion of the
> > (almost) always usage of the UDP checksum for IPv6 applies here.
> > Also
> > the implications for corruptions and cost in some DTNs for stray
> > data
> > appears quite high.
> >
>
> Discussion has been raised by not concluded to my understanding.
>
> 	-->  Yes, still pending consensus on the mailing list.
>
-- 
Cheers

Magnus Westerlund


----------------------------------------------------------------------
Network Architecture & Protocols, Ericsson Research
----------------------------------------------------------------------
Ericsson AB                 | Phone  [phone]
Torshamnsgatan 23           | Mobile [phone]
SE-164 80 Stockholm, Sweden | mailto: [e-mail]
----------------------------------------------------------------------