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

[Elwyn Davies <[e-mail]>]

Hi, Michael.

Thanks very much for your comments.

I was planning a minor update of sdnv and will address your comments
along  with some from Lachlan Andrew.

I am forwarding this to the dtn interest list so that the various
authors can see your comments as well.

Unfortunately that still leaves us needing 'ready to publish' votes for
items 3 (cbhe), 4 (metadata block) and 5 (previous hop block).  Any
other IRSG memebers willing to put their heads above the parapet
*please*?

Regards,
Elwyn

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...
> 
> 
> > 1) draft-irtf-dtnrg-sdnv
> > ticket: http://trac.tools.ietf.org/group/irtf/trac/ticket/30
> > draft: http://tools.ietf.org/html/draft-irtf-dtnrg-sdnv
> > ready to publish:
> > 	Juergen Schoenwaelder, 2010-03-03
> 
> I also vote "ready to publish" here.
> 
> Comments:
> 
> I think this is a very useful document and even enjoyed reading it. A  
> few nits:
> - section 1.1 par 3 line 2: remove "0" before "IP header format"
> - second last line: might have to be "...to have _a_ visible impact  
> on..."   (don't know for sure, I'm not a native speaker)
> - 1.3 bullet list: I suggest to remove the last ("Etc.") bullet, this  
> is just a waste of space because you say "such as" anyway
> - section 4: as I read this, I became more and more curious what  
> SDNV-8 and SDNV-16 really look like. Given that it probably won't be  
> very complicated to explain them, you could make this an easier read  
> with a brief explanation of these formats.
> - paragraph just below table 1: this is a repetition of some earlier  
> text, and as such maybe unnecessary. If you think it adds value to  
> repeat this here, at least refer to the other text ("as initially  
> stated, .." or something like that).
> - Reference ASN1-BER: strange line break here
> 
> 
> > 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.
> 
> 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").
> - 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..."
> - section 2.1, par 1: fix "inSection" => "in Section".
> - 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...
> - 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.
> - 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.
> 
> 
> > 4) draft-irtf-dtnrg-bundle-metadata-block
> > ticket: http://trac.tools.ietf.org/group/irtf/trac/ticket/33
> > draft:  http://tools.ietf.org/html/draft-irtf-dtnrg-metadata-block
> > ready to publish:
> > 	Juergen Schoenwaelder, 2010-11-29
> 
> Again I vote "no objection" just for confidence reasons. The document  
> looks fine to me. The only (non-blocking :-) ) comment I have on this  
> one is that I don't like its last three words (end of security cons.  
> section): "as currently written". I suggest to remove them.
> 
> 
> > 5) draft-irtf-dtnrg-bundle-previous-hop-block
> > ticket: http://trac.tools.ietf.org/group/irtf/trac/ticket/34
> > draft: http://tools.ietf.org/html/draft-irtf-dtnrg-previous-hop-block
> > ready to publish:
> > 	Juergen Schoenwaelder, 2010-11-29
> 
> Again, "no objection", for the same reasons.
> 
> Minor (non-blocking) comments:
> - remove " at the end of the abstract
> - section 3.3: about the statement "If ... the PHIB is not considered  
> to be well-formed." and the text after it: what's the point of  
> including this in the definition? According to the spec, such an ill- 
> formed PHIB MUST NOT be generated, right? In that case, describing how  
> to handle it is a bit like describing the case of when a buggy sender  
> writes "123123" in every field... or whatever... my point is, if we  
> consider buggy hosts, ANYTHING can happen, and incorporating this  
> assumption in the document here just seems like a waste of space to  
> me. But maybe I missed it, and an ill-formed PHIB may be generated  
> somehow in line with this spec.
> - section 4 par 5: same thing here, this looks to me as if you could  
> also add a paragraph saying "Note that a PHIB may also contain the  
> value 123123" no matter where it comes from if hosts are buggy and  
> hence always just stupidly write this number there." or: "Note that a  
> buggy host can write your system password into a packet, and then  
> anybody can see it."  That's taking security concerns too far IMO, and  
> seems like a waste of space (= reader's time!) to me.
> 
> Cheers,
> Michael
>