Re: [dtn-interest] [IRSG] DTNRG drafts need a few more "ready to publish" mails...

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

Michael, thanks very much for your comments on CBHE.  Some responses in-line below.

Scott

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On Behalf Of Elwyn Davies
Sent: Monday, January 24, 2011 11:37 AM
To: Michael Welzl
Cc: Internet Research Steering Group; DTN interest
Subject: Re: [dtn-interest] [IRSG] DTNRG drafts need a few more "ready to publish" mails...

...

On Mon, 2011-01-17 at 15:39 +1100, Michael Welzl wrote:
> Hi,
> 
> Below are my votes, and my (brief, because this is not my area of  
> expertise) comments on the ones that still needed votes. I'm fine with  
> all of them going forward, so my comments are rather minor, mostly  
> editorial things or nitpicking...

...

> > 3) draft-irtf-dtnrg-chbe
> > ticket: http://trac.tools.ietf.org/group/irtf/trac/ticket/32
> > draft: http://tools.ietf.org/html/draft-irtf-dtnrg-cbhe
> > ready to publish:
> > 	"no objection" Juergen Scheoenwaelder, 2010-03-10
> > 		(note mail subject says "svhe" and not "cbhe" on irsg
> > 		list)
> 
> I vote "no objection" (instead of "ready to publish" due to lack of  
> confidence - I'd really have to be more of an expert on DTN to state  
> if this is really ready for publication or not) provided that you have  
> a good answer to this comment:
> 
> - section 3.1, par 2: the last sentence here, "The manner in which  
> this determination is made is an implementation matter." made me stop  
> and think. Isn't the point of standards to be interoperable? If you  
> don't define how to determine whether CBHE is applied or not, doesn't  
> this make this whole specification a bit pointless? I have a feeling  
> that this is a key element which should be a part of this specification.

I think this goes to a recurring dilemma in configuring DTNs - when to define a discovery mechanism and when to rely on a management procedure.  Discovery protocols reduce network administration workload and ensure interoperability, but they typically rely on fairly prompt round-trip message exchange, which we can't always count on in a DTN; in some cases DTN transmission may even be strictly simplex, making discovery impossible.

That is, in the most general case I believe we have to be able to support CBHE even on nodes that are on "fire and forget" devices that can never tell us how they are configured.  This throws the responsibility for this determination back on the source node, and in the near term I think mandating any particular local node management procedure for this purpose goes beyond the standardization that this specification should be aiming for.

The long-term answer may be different: there is ongoing work on definition of DTN network management protocols, and eventually I think information about the CBHE-readiness of a node could very reasonably be among the items noted in the messages of those protocols.  But DTN network management is a complex problem, and I think it makes more sense to leverage (and conform to) a general solution to that problem when it emerges than to try to invent a separate solution to a small subset of it in the CBHE spec. 
 
> other, minor, non-blocking comments:
> 
> - intro, par 2: you say here that the term SSP is historical - but  
> then, you keep using it throughout the document. This seems a bit  
> strange. Either you should use the new name, or you should rephrase  
> this here (e.g. "also called..." instead of "historically").

Or just remove the word "historically" from intro par.2?  I think that still preserves the sense of the sentence.

> - next par: I think there should be a comma after "eight" in: "...in  
> the dictionary may be less than eight and two or more of the scheme..."

I think that comma is optional in front of a coordinating conjunction, but I agree that it would improve the readability of the sentence.

> - section 2.1, par 1: fix "inSection" => "in Section".

Yes.

> - section 2.2: just a note, this list of constraints is one of the  
> things that made me feel less confident about this document - here, a  
> reviewer must really know the bundle spec very well to judge whether  
> this is ok or not...

Absolutely.  But I think it's unavoidable here.

> - security considerations: note that this appears as a heading within  
> IANA Considerations, and then later again, as a "proper" heading.  
> There is something wrong here, I think the second heading should be  
> removed, and the first one properly formatted.

Right, this looks like an error, but the first "security considerations" paragraph is actually part of the URI registration template I was trying to follow.  I think it's correct, but I will happily revise if someone knows of a more acceptable format.

> - in the bullet list after the first "security considerations" heading  
> (within section 4): "Rare IP address formats: not relevant, ..."   -  
> because this is not relevant, I think it should be removed.

This too was part of the URI registration template I was working from.  Again, I'm happy to remove it if IANA won't complain.

Scott