Subject: Re: [dtn-interest] Fwd: Re: LTPCL and ECOS Internet Drafts

From: Stephen Farrell <[email-masked]>
Date: Thu, 25 Oct 2012 14:25:19 +0100

Hi Joerg,

My review of LTPCL, as promised, but late;-)

Basically this is ready, I've some comments below that
can be taken or not.

Incidentally, I've also been doing interop testing
between DTN2/LTPlib and ION, and it basically works fine as
per this draft, which is my main reason for thinking this
is ready.

- 2.2, "ONLY" isn't a 2119 term, better to lowercase that

- 2.2, 2nd bullet, DTN2/LTPlib can support this but I don't
think ION does, if so, do we want to keep the option? I
would prefer to keep it, but worth checking. (I recall
arguing about this with Scott ages ago, but forget the
pros and cons;-)

- 2.2, 4th last para, didn't we setup an IANA registry
for these numbers (can't recall). If so, then a reference
to that from here would be useful.

- 2.3(b) is very hard to read, I think it could be
simplified and I'm not quite sure what its saying,
esp about discarding bytes at the end

- 2.3 overall: I wonder if someone reading this and
wanting to write code would find it good enough or not.
Its hard to say since I don't think that's happened.
Not something that we ought block on, for an experimental
RFC though.

Cheers,
S.

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 25 Oct 2012 14:48:49 +0100

My review of ECOS, I think this one needs fixing then
this is ready.

- 3.2, I think you need to say these rules only apply
to nodes that implement this extension block, as-is it
reads like you want to update 5050 so that all
implementations know about ECOS and I don't think we
want to do that

The rest, you can take or leave:

- section 1, "critical" bullet, I think the example of sending
a bundle with that on every path is ok, but it ought be clearer
that its an example, since whether or not that can happen
depends on how you're routing bundles, e.g. with CGR you
could do that but not (sensibly) with prophet, just adding
an "e.g." somewhere would fix that. In the same para you
also maybe need to make clear that there is in general no
guarantee of the "least possible time" even if that's
the goal.

- section 2, 1st bullet, a fwd reference to IANA
considerations section would be nice here

- section 2, when you say the 0x02 bit, is that the 2nd
MS bit of the 2nd LS bit, it could be read as either.
Maybe best to add a diagram.

- What does ordinal value 255 mean? where's that stated?

- I'm shocked that Scott is wasting an entire byte for
the ordinal number when its not needed and there are
spare flags:-) I don't care really but you could've
saved that byte.

- 3.2 saying you SHOULD delete ECOS blocks if one has
bad syntax seems wrong to me. What if we add a new flag
that re-defines the current ones?

- 3.2 (1), if critical is the same as expidited with
ordinal 254 then why not just use that combination and
don't waste a flag?

- section 5, s/could impact/does impact/

Cheers,
S.

---

From: "Burleigh, Scott C (313B)" <[email-masked]>
Date: Thu, 25 Oct 2012 16:50:32 +0000

Stephen, I think the note you propose for section 3.2 isn't really needed, since the whole specification applies only to nodes that implement this extension block -- nodes that don't are subject only to section 4.6 of RFC 5050.  But I've added a paragraph to that effect anyway.

A couple of other responses are in-line below.

Scott

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Stephen Farrell
Sent: Thursday, October 25, 2012 6:49 AM
To: Joerg Ott
Cc: DTN interest
Subject: Re: [dtn-interest] Fwd: Re: LTPCL and ECOS Internet Drafts

My review of ECOS, I think this one needs fixing then this is ready.

- 3.2, I think you need to say these rules only apply to nodes that implement this extension block, as-is it reads like you want to update 5050 so that all implementations know about ECOS and I don't think we want to do that

- section 1, "critical" bullet, I think the example of sending a bundle with that on every path is ok, but it ought be clearer that its an example, since whether or not that can happen depends on how you're routing bundles, e.g. with CGR you could do that but not (sensibly) with prophet, just adding an "e.g." somewhere would fix that. In the same para you also maybe need to make clear that there is in general no guarantee of the "least possible time" even if that's the goal.

	>>>	This bullet isn't normative, but actually it means what it says.  The interpretation of "critical" here is very specific, as defined in 3.2(1); if the routing system can't do what the flag asks it to do, well, okay, it can't.  If we think there's a need for a more open-ended indication that "this bundle is really important, so do whatever you can to deliver it as soon as possible", great, let's add that somewhere.  But that's not the intent of this flag.  (We could give it a different name if you want.)

- section 2, 1st bullet, a fwd reference to IANA considerations section would be nice here

	>>>	Sure.

- section 2, when you say the 0x02 bit, is that the 2nd MS bit of the 2nd LS bit, it could be read as either.
Maybe best to add a diagram.

	>>>	I don't understand how this is ambiguous.  How can 0x02 mean anything other than the bits 00000010?

	>>>	Section 2 says "Ordinal value 255 is reserved for custody signals".

- I'm shocked that Scott is wasting an entire byte for the ordinal number when its not needed and there are spare flags:-) I don't care really but you could've saved that byte.

	>>>	The ordinal number is the one thing that our users tell us is MOST needed.  The Japanese Space Agency, for example, apparently use several dozens of different levels of priority in mission communications.

- 3.2 saying you SHOULD delete ECOS blocks if one has bad syntax seems wrong to me. What if we add a new flag that re-defines the current ones?

	>>>	Then the syntax has changed and the rule remains in effect.  Does that create a problem?

- 3.2 (1), if critical is the same as expidited with ordinal 254 then why not just use that combination and don't waste a flag?

	>>>	Because "critical" means more than that, as described in 3.2(1).

	>>>	I think it's still more accurate to say "could" than "would" or "will".  If your network happens to be a tree, with no alternative paths, then setting the "critical" flag would never have any effect.

Cheers,
S.
_______________________________________________
dtn-interest mailing list
[email-masked]
https://www.irtf.org/mailman/listinfo/dtn-interest

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 25 Oct 2012 17:54:55 +0100

Hiya,

I'm fine with all that, but do think that a diagram showing that
the bits are the least significant would still help, honest. That
kind of thing does get misinterpreted sometimes.

Thanks,
S

---

From: "Burleigh, Scott C (313B)" <[email-masked]>
Date: Thu, 25 Oct 2012 17:04:36 +0000

Thanks, Stephen.  Responses in-line below.

Scott

-----Original Message-----
From: Stephen Farrell [mailto:[email-masked]] 
Sent: Thursday, October 25, 2012 6:25 AM
To: Joerg Ott
Cc: Burleigh, Scott C (313B); DTN interest
Subject: Re: Fwd: Re: [dtn-interest] LTPCL and ECOS Internet Drafts

Hi Joerg,

Basically this is ready, I've some comments below that can be taken or not.

Incidentally, I've also been doing interop testing between DTN2/LTPlib and ION, and it basically works fine as per this draft, which is my main reason for thinking this is ready.

	>>>	Sure

- 2.2, 2nd bullet, DTN2/LTPlib can support this but I don't think ION does, if so, do we want to keep the option? I would prefer to keep it, but worth checking. (I recall arguing about this with Scott ages ago, but forget the pros and cons;-)

	>>>	I'm fine with keeping the option, so long as it's clearly optional.  The potential DOS attack makes it a non-starter for ION, but I don't think that's a sufficient reason to outlaw it.

- 2.2, 4th last para, didn't we setup an IANA registry for these numbers (can't recall). If so, then a reference to that from here would be useful.

	>>>	I think the registry is being set up in the course of advancing this set of I-Ds.  If somebody can give me the text for an appropriate reference I'll happily add it.

- 2.3(b) is very hard to read, I think it could be simplified and I'm not quite sure what its saying, esp about discarding bytes at the end

	>>>	I can't think of any way to simplify that language without making less precise and explicit.  Do you have some candidate text?

- 2.3 overall: I wonder if someone reading this and wanting to write code would find it good enough or not.
Its hard to say since I don't think that's happened.
Not something that we ought block on, for an experimental RFC though.

Cheers,
S.