Subject: Re: [dtn-interest] Comments on SHOULD
From: "Adrian J. Hooke" <[email-masked]>
To: [email-masked]
Date: Mon, 28 Apr 2003 08:28:28 -0700
List-Id: Delay Tolerant Networking Interest List <dtn-interest.mailman.dtnrg.org>

At 03:48 PM 4/26/2003, Petre Dini wrote:
>E-mail-wise, the only different venue for continuing the discussion I saw, 
>was to change the subject in "Comments on "SHOULD" to let people desiring 
>to discuss to continue to comment on a precise topic.

I wonder if Joe Touch, having recently established two useful discussion 
lists ["[email-masked]" and "[email-masked]"], 
could (should?) now bring the world "[email-masked]" so that 
the DTN list can (shall?) revert to technical discussions about delay 
tolerant networking?

///adrian hooke

Date: Sun, 27 Apr 2003 19:07:35 -0400
From: "vinton g. cerf" <[email-masked]>
Subject: Re: types of contact (was: Re: [dtn-interest] Comments on draft-irtf-dtnrg-arch-00.txt)
To: Scott Burleigh <[email-masked]>, [email-masked]
Sender: [email-masked]

why does this sound like some kind of psychological classification
like mutant anachronistic and computational schizoid...

:-)

At 11:32 AM 4/25/2003 -0700, Scott Burleigh wrote:
>At 08:03 PM 4/22/2003 +0100, Stephen Farrell wrote:
>
>
>It's intermittent opportunistic

Date: Sun, 27 Apr 2003 09:44:06 -0400
From: "vinton g. cerf" <[email-masked]>
To: [email-masked], Ebba Thora Hvannberg <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: [dtn-interest] Re: Keynote speakers  to be announced / NORDUnet 2003
Sender: [email-masked]

At 11:23 PM 4/4/2003 +0100, Ebba Þóra Hvannberg wrote:

>Dear distinguished keynote speaker,
>
>We are very pleased and honoured that you have accepted to be a keynote
>speaker.
>
>The preliminary programme of the NORDUnet 2003 conference will be published
>on the web next week.
>
>In order to prepare the announcement, I would like to ask you to send us the
>following by replying to this e-mail:
>
>1. Your name, title and association
>2. Short CV (ca. 50-100 words). Can include a web-site.
>
>I will be greatful if you can send the above two items to me as soon as
>possible, or before April 11th.
>
>Can you also provide me with the following two items before May 15th:
>
>3. Title of talk

Delay Tolerant Networking

>4. Abstract

In the environment of deep space communication, there are significant impairments to communication including extreme and varying round-trip time delays owing to speed of light propagation, asymmetry in connectivity and data rates, varying error rates, power consumption limitations, disconnections resulting from celestial or surface motions, among many other effects. While the standard TCP/IP protocol works well in low-delay environments, and can be used onboard spacecraft and on the surface of planets, as it is on Earth, it appears to be worth seriously considering alternatives that take into account the potential impairments noted above.

TCP/IP does not operate in a vacuum (pun intended!) and many of the protocols layered above it rely on the Domain Name System to decouple destinations from their immediate IP addresses. Running the DNS in the impaired environment described above also has its challenges. At the Jet Propulsion Laboratory, a team of protocol designers and architects have developed an alternative to TCP/IP for deep space transport. Essentially it runs atop TCP/IP or OTHER transport systems, delays the binding of symbolic names until reaching the destination planet (space craft, etc.), and copes with the many other limitations already mentioned. This talk will outline the challenges and responses that lead to the design of an interplanetary network - effectively a network of Internets. 

>Best regards
>
>Ebba Thora Hvannberg
>Program Chair of Nordunet 2003 (www.nordunet2003.is)
>
>Ebba Thora Hvannberg
>associate professor        t: 354 525 4702
>Computer Science           m: 354 897 9196
>University of Iceland      f: 354 525 4937
>Hjardarhaga 2-6            e-mail:[email-masked]
>IS-107 Reykjavik

Vint Cerf
SVP Architecture & Technology
MCI
22001 Loudoun County Parkway, F2-4115
Ashburn, VA 20147
703 886 1690 (v806 1690)
703 886 0047 fax
[email-masked]
www.mci.com/cerfsup 

To: Petre Dini <[email-masked]>
cc: [email-masked]
Subject: Re: [dtn-interest] Comments on draft-irtf-dtnrg-arch-00.txt [SHOULD] 
Date: Sat, 26 Apr 2003 19:56:10 -0400
From: Craig Partridge <[email-masked]>
Sender: [email-masked]

In message <[email-masked]>, Petre Din
i writes:

>>So why not simply accept they exist?
>
>Implementation-wise, valid reasons are different owners and they tend to 
>conflict too frequently, as interpretation may vary.
>Accepting them is one thing, recognizing and differentiating them is 
>something else. Only differentiating them leads to avoid inconsistency, I 
>think.

I think this is too narrow a view (and after this I'll stop).  

I believe there are clearly standards where inconsistency leads to
less good performance, but does not cause interoperability to cease to
exist.

Craig

Date: Sat, 26 Apr 2003 16:23:45 -0700
To: Warthman Associates <[email-masked]>
From: Petre Dini <[email-masked]>
Subject: Re: [dtn-interest] Comments on SHOULD
Cc: Scott  Bradner <[email-masked]>, [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Sender: [email-masked]

--=====================_16799135==_.ALT
Content-Type: text/plain; charset="us-ascii"; format=flowed

Forrest,
Great!
Let us keep in touch. I suggest we will exchange off-list till we have a 
crispier document.
I'll let you know soon my draft version, as I have a lot of examples of 
inconsistencies.
Regards,
Petre

  At 04:06 PM 4/26/2003 -0700, Warthman Associates wrote:
>Petre,
>
>Yes, I'd be most happy to help with your document.
>
>Forrest
>
>At 03:48 PM 4/26/2003, Petre Dini wrote:
>>Forrest,
>>
>>It was my point also in my preceding e-mail; your e-mail fits on mine 
>>almost perfectly.
>>
>>E-mail-wise, the only different venue for continuing the discussion I 
>>saw, was to change the subject in "Comments on "SHOULD" to let people 
>>desiring to discuss to continue to comment on a precise topic. So, only 
>>those interested to contribute will continue the discussion, which is fair!
>>
>>
>>IETF-wise, as I said, I'm writing this document, and now, as Scott 
>>suggested in his e-mail the path
>>
>> >> the way to get things done in the IETF is to write an Internet Draft
>> >> and submit it - once it is published send a note to the IETF list
>> >> to see if you can get a discussion going
>>
>>I really intend to follow this path.
>>
>>I will draft a more organized strawman and exchange with those interested 
>>then go on the IETF.
>>
>>Who want then to continue the discussion and contribute to the Internet 
>>Draft?
>>Are you Forest willing to contribute/cooperate on a document on this topic?
>>Who else?
>>
>>Thanks,
>>Petre
>>
>>
>>
>>
>>At 03:21 PM 4/26/2003 -0700, Warthman Associates wrote:
>>>Scott,
>>>
>>>I think the IETF needs to reconsider this issue. Here's an even shorter 
>>>summary of my argument:
>>>
>>>The logical equivalent of "should" in RFC 2119 is:
>>>
>>>if <valid_reason> then need_not_implement else must_implement
>>>
>>>However, an external testing agent (such as code executing on, or data 
>>>flowing through, an implementation of the architecture) is unable to 
>>>judge the validity or even the existence of the reason, which is the 
>>>condition of the if-then-else branch, so from the agent's viewpoint the 
>>>architecture seems to treat the implementation of the function as a may.
>>>
>>>It would be useful, of course, for an architecture to specify that a 
>>>state-flag be set according to whether the function in question has or 
>>>has not been implemented. This helps external agents, but it does not 
>>>fix the problem of incompatible implementations of the architecture: 
>>>some will implement the function, others won't. So, we're stuck with a 
>>>mixed batch of implementations -- not a great situation in a world of 
>>>growing software-interoperability problems.
>>>
>>>If you'd like to suggest a different venue in which to carry on this 
>>>discussion, please do so.
>>>
>>>Forrest
>>>
>>>-----------------------------------------------------------------
>>>Forrest Warthman       Warthman Associates      Technical Writers
>>>2417 Embarcadero Way   Palo Alto, CA 94303   [email-masked]
>>>(650)494-8555          (650)857-1815 fax         www.warthman.com
>>>
>>>
>>>
>>>At 01:22 PM 4/26/2003, Scott  Bradner wrote:
>>>> > Any input and/or position is appreciated,
>>>>
>>>>I think there is dead horse beating going on here - as Bob
>>>>pointed out, this terminology has been in use in the IETF for quite a long
>>>>time and I've never heard of anyone getting confused (well, I do recall one
>>>>case where someone wanted to be confused because he did not want the
>>>>requirement to be that strong) - in addition RFC 2119 went through IETF
>>>>last call in which it got quite a bit of review as far as I can recall
>>>>SHOULD was never brought up as an issue.
>>>>
>>>>That said, anyone can write an Internet Draft and suggest to the IESG that
>>>>it be considered for publication as a BCP or to the RFC Ed that it be
>>>>considered for publication as an Informational RFC.
>>>>
>>>>but I would think that there are rather many higher priority issues to
>>>>be looked at than trying to aditionally clarify some text that most
>>>>people have felt was quite clear since long before 2119 was published.
>>>>
>>>>Scott

--=====================_16799135==_.ALT
Content-Type: text/html; charset="us-ascii"

<html>
Forrest,<br>
Great!<br>
Let us keep in touch. I suggest we will exchange off-list till we have a
crispier document.<br>
I'll let you know soon my draft version, as I have a lot of examples of
inconsistencies. <br>
Regards,<br>
Petre<br>
<br>
<br>
<br>
&nbsp;At 04:06 PM 4/26/2003 -0700, Warthman Associates wrote:<br>
<blockquote type=cite cite>Petre,<br>
<br>
Yes, I'd be most happy to help with your document.<br>
<br>
Forrest<br>
<br>
At 03:48 PM 4/26/2003, Petre Dini wrote:<br>
<blockquote type=cite cite>Forrest,<br>
<br>
It was my point also in my preceding e-mail; your e-mail fits on mine
almost perfectly.<br>
<br>
E-mail-wise, the only different venue for continuing the discussion I
saw, was to change the subject in &quot;Comments on &quot;SHOULD&quot; to
let people desiring to discuss to continue to comment on a precise topic.
So, only those interested to contribute will continue the discussion,
which is fair!<br>
<br>
<br>
IETF-wise, as I said, I'm writing this document, and now, as Scott
suggested in his e-mail the path<br>
<br>
<font color="#0000FF">&gt;&gt; the way to get things done in the IETF is
to write an Internet Draft<br>
&gt;&gt; and submit it - once it is published send a note to the IETF
list <br>
&gt;&gt; to see if you can get a discussion going<br>
<br>
</font>I really intend to follow this path. <br>
<br>
I will draft a more organized strawman and exchange with those interested
then go on the IETF.<br>
<br>
Who want then to continue the discussion and contribute to the Internet
Draft?<br>
Are you Forest willing to contribute/cooperate on a document on this
topic?<br>
Who else?<br>
<br>
Thanks,<br>
Petre<br>
&nbsp;<br>
<br>
<br>
<br>
At 03:21 PM 4/26/2003 -0700, Warthman Associates wrote:<br>
<blockquote type=cite cite>Scott,<br>
<br>
I think the IETF needs to reconsider this issue. Here's an even shorter
summary of my argument:<br>
<br>
The logical equivalent of &quot;should&quot; in RFC 2119 is:<br>
<br>
<b>if </b><i>&lt;valid_reason&gt;</i> <b>then </b>need_not_implement<b>
else </b>must_implement<br>
<br>
However, an external testing agent (such as code executing on, or data flowing through, an implementation of the architecture) is unable to judge the validity or even the existence of the reason, which is the condition of the if-then-else branch, so from the agent's viewpoint the architecture seems to treat the implementation of the function as a <b>may</b>. <br>
<br>
It would be useful, of course, for an architecture to specify that a state-flag be set according to whether the function in question has or has not been implemented. This helps external agents, but it does not fix the problem of incompatible implementations of the architecture: some will implement the function, others won't. So, we're stuck with a mixed batch of implementations -- not a great situation in a world of growing software-interoperability problems. <br>
<br>
If you'd like to suggest a different venue in which to carry on this discussion, please do so. <br>
<br>
Forrest<br>
<br>
-----------------------------------------------------------------<br>
Forrest Warthman&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Warthman Associates&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Technical Writers<br>
2417 Embarcadero Way&nbsp;&nbsp; Palo Alto, CA 94303&nbsp;&nbsp; [email-masked]<br>
(650)494-8555&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; (650)857-1815 fax&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <a href="http://www.warthman.com/" eudora="autourl">www.warthman.com</a><br>
<br>
<br>
<br>
At 01:22 PM 4/26/2003, Scott&nbsp; Bradner wrote:<br>
<blockquote type=cite cite>&gt; Any input and/or position is appreciated,<br>
<br>
I think there is dead horse beating going on here - as Bob<br>
pointed out, this terminology has been in use in the IETF for quite a long <br>
time and I've never heard of anyone getting confused (well, I do recall one<br>
case where someone wanted to be confused because he did not want the <br>
requirement to be that strong) - in addition RFC 2119 went through IETF <br>
last call in which it got quite a bit of review as far as I can recall <br>
SHOULD was never brought up as an issue.<br>
<br>
That said, anyone can write an Internet Draft and suggest to the IESG that<br>
it be considered for publication as a BCP or to the RFC Ed that it be <br>
considered for publication as an Informational RFC.<br>
<br>
but I would think that there are rather many higher priority issues to<br>
be looked at than trying to aditionally clarify some text that most<br>
people have felt was quite clear since long before 2119 was published.<br>
<br>
Scott</blockquote></blockquote></blockquote></blockquote></html>

--=====================_16799135==_.ALT--

Date: Sat, 26 Apr 2003 16:08:43 -0700
To: Craig Partridge <[email-masked]>
From: Petre Dini <[email-masked]>
Subject: Re: [dtn-interest] Comments on draft-irtf-dtnrg-arch-00.txt [SHOULD] 
Cc: Warthman Associates <[email-masked]>, [email-masked], Petre Dini <[email-masked]>
Sender: [email-masked]

At 06:50 PM 4/26/2003 -0400, Craig Partridge wrote:

>In message <[email-masked]>, Warthman 
>Associat
>
> >The logical equivalent of "should" in RFC 2119 is:
> >
> >if <valid_reason> then need_not_implement else must_implement
>
>I think this makes sense.  Only the most arrogant think that they can
>completely define/determine the future.

I think that the point was to learn from the past experiences instead of 
completely defining the future.
This is not question of arrogance, but pragmatism, my guess!

>So ennumerating valid reasons is a hopeless task.

Idea was on past-based use cases, experience, etc. Kind of guidelines; see 
my proposed strawman.

>So why not simply accept they exist?

Implementation-wise, valid reasons are different owners and they tend to 
conflict too frequently, as interpretation may vary.
Accepting them is one thing, recognizing and differentiating them is 
something else. Only differentiating them leads to avoid inconsistency, I 
think.

>Craig
>_______________________________________________

-- Petre

Date: Sat, 26 Apr 2003 16:06:33 -0700
To: Petre Dini <[email-masked]>, Scott  Bradner <[email-masked]>, [email-masked], Petre Dini <[email-masked]>
From: Warthman Associates <[email-masked]>
Subject: Re: [dtn-interest] Comments on SHOULD
Cc: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Sender: [email-masked]

--=====================_163153742==.ALT
Content-Type: text/plain; charset="us-ascii"; format=flowed

Petre,

Yes, I'd be most happy to help with your document.

Forrest

At 03:48 PM 4/26/2003, Petre Dini wrote:
>Forrest,
>
>It was my point also in my preceding e-mail; your e-mail fits on mine 
>almost perfectly.
>
>E-mail-wise, the only different venue for continuing the discussion I saw, 
>was to change the subject in "Comments on "SHOULD" to let people desiring 
>to discuss to continue to comment on a precise topic. So, only those 
>interested to contribute will continue the discussion, which is fair!
>
>
>IETF-wise, as I said, I'm writing this document, and now, as Scott 
>suggested in his e-mail the path
>
> >> the way to get things done in the IETF is to write an Internet Draft
> >> and submit it - once it is published send a note to the IETF list
> >> to see if you can get a discussion going
>
>I really intend to follow this path.
>
>I will draft a more organized strawman and exchange with those interested 
>then go on the IETF.
>
>Who want then to continue the discussion and contribute to the Internet Draft?
>Are you Forest willing to contribute/cooperate on a document on this topic?
>Who else?
>
>Thanks,
>Petre
>
>
>
>
>At 03:21 PM 4/26/2003 -0700, Warthman Associates wrote:
>>Scott,
>>
>>I think the IETF needs to reconsider this issue. Here's an even shorter 
>>summary of my argument:
>>
>>The logical equivalent of "should" in RFC 2119 is:
>>
>>if <valid_reason> then need_not_implement else must_implement
>>
>>However, an external testing agent (such as code executing on, or data 
>>flowing through, an implementation of the architecture) is unable to 
>>judge the validity or even the existence of the reason, which is the 
>>condition of the if-then-else branch, so from the agent's viewpoint the 
>>architecture seems to treat the implementation of the function as a may.
>>
>>It would be useful, of course, for an architecture to specify that a 
>>state-flag be set according to whether the function in question has or 
>>has not been implemented. This helps external agents, but it does not fix 
>>the problem of incompatible implementations of the architecture: some 
>>will implement the function, others won't. So, we're stuck with a mixed 
>>batch of implementations -- not a great situation in a world of growing 
>>software-interoperability problems.
>>
>>If you'd like to suggest a different venue in which to carry on this 
>>discussion, please do so.
>>
>>Forrest
>>
>>-----------------------------------------------------------------
>>Forrest Warthman       Warthman Associates      Technical Writers
>>2417 Embarcadero Way   Palo Alto, CA 94303   [email-masked]
>>(650)494-8555          (650)857-1815 fax         www.warthman.com
>>
>>
>>
>>At 01:22 PM 4/26/2003, Scott  Bradner wrote:
>>> > Any input and/or position is appreciated,
>>>
>>>I think there is dead horse beating going on here - as Bob
>>>pointed out, this terminology has been in use in the IETF for quite a long
>>>time and I've never heard of anyone getting confused (well, I do recall one
>>>case where someone wanted to be confused because he did not want the
>>>requirement to be that strong) - in addition RFC 2119 went through IETF
>>>last call in which it got quite a bit of review as far as I can recall
>>>SHOULD was never brought up as an issue.
>>>
>>>That said, anyone can write an Internet Draft and suggest to the IESG that
>>>it be considered for publication as a BCP or to the RFC Ed that it be
>>>considered for publication as an Informational RFC.
>>>
>>>but I would think that there are rather many higher priority issues to
>>>be looked at than trying to aditionally clarify some text that most
>>>people have felt was quite clear since long before 2119 was published.
>>>
>>>Scott

--=====================_163153742==.ALT
Content-Type: text/html; charset="us-ascii"

<html>
<body>
Petre,<br><br>
Yes, I'd be most happy to help with your document.<br><br>
Forrest<br><br>
At 03:48 PM 4/26/2003, Petre Dini wrote:<br>
<blockquote type=cite class=cite cite>Forrest,<br><br>
It was my point also in my preceding e-mail; your e-mail fits on mine
almost perfectly.<br><br>
E-mail-wise, the only different venue for continuing the discussion I
saw, was to change the subject in &quot;Comments on &quot;SHOULD&quot; to
let people desiring to discuss to continue to comment on a precise topic.
So, only those interested to contribute will continue the discussion,
which is fair!<br><br>
<br>
IETF-wise, as I said, I'm writing this document, and now, as Scott
suggested in his e-mail the path<br><br>
<font color="#0000FF">&gt;&gt; the way to get things done in the IETF is
to write an Internet Draft<br>
&gt;&gt; and submit it - once it is published send a note to the IETF
list <br>
&gt;&gt; to see if you can get a discussion going<br><br>
</font>I really intend to follow this path. <br><br>
I will draft a more organized strawman and exchange with those interested
then go on the IETF.<br><br>
Who want then to continue the discussion and contribute to the Internet
Draft?<br>
Are you Forest willing to contribute/cooperate on a document on this
topic?<br>
Who else?<br><br>
Thanks,<br>
Petre<br>
&nbsp;<br><br>
<br><br>
At 03:21 PM 4/26/2003 -0700, Warthman Associates wrote:<br>
<blockquote type=cite class=cite cite>Scott,<br><br>
I think the IETF needs to reconsider this issue. Here's an even shorter
summary of my argument:<br><br>
The logical equivalent of &quot;should&quot; in RFC 2119 is:<br><br>
<b>if </b><i>&lt;valid_reason&gt;</i> <b>then </b>need_not_implement<b>
else </b>must_implement<br><br>
However, an external testing agent (such as code executing on, or data flowing through, an implementation of the architecture) is unable to judge the validity or even the existence of the reason, which is the condition of the if-then-else branch, so from the agent's viewpoint the architecture seems to treat the implementation of the function as a <b>may</b>. <br><br>
It would be useful, of course, for an architecture to specify that a state-flag be set according to whether the function in question has or has not been implemented. This helps external agents, but it does not fix the problem of incompatible implementations of the architecture: some will implement the function, others won't. So, we're stuck with a mixed batch of implementations -- not a great situation in a world of growing software-interoperability problems. <br><br>
If you'd like to suggest a different venue in which to carry on this discussion, please do so. <br><br>
Forrest<br><br>
-----------------------------------------------------------------<br>
Forrest Warthman&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Warthman Associates&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Technical Writers<br>
2417 Embarcadero Way&nbsp;&nbsp; Palo Alto, CA 94303&nbsp;&nbsp; [email-masked]<br>
(650)494-8555&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; (650)857-1815 fax&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <a href="http://www.warthman.com/" eudora="autourl">www.warthman.com</a><br><br>
<br><br>
At 01:22 PM 4/26/2003, Scott&nbsp; Bradner wrote:<br>
<blockquote type=cite class=cite cite>&gt; Any input and/or position is appreciated,<br><br>
I think there is dead horse beating going on here - as Bob<br>
pointed out, this terminology has been in use in the IETF for quite a long <br>
time and I've never heard of anyone getting confused (well, I do recall one<br>
case where someone wanted to be confused because he did not want the <br>
requirement to be that strong) - in addition RFC 2119 went through IETF <br>
last call in which it got quite a bit of review as far as I can recall <br>
SHOULD was never brought up as an issue.<br><br>
That said, anyone can write an Internet Draft and suggest to the IESG that<br>
it be considered for publication as a BCP or to the RFC Ed that it be <br>
considered for publication as an Informational RFC.<br><br>
but I would think that there are rather many higher priority issues to<br>
be looked at than trying to aditionally clarify some text that most<br>
people have felt was quite clear since long before 2119 was published.<br><br>
Scott</blockquote></blockquote></blockquote></body>
</html>

--=====================_163153742==.ALT--

To: Warthman Associates <[email-masked]>
cc: [email-masked]
Subject: Re: [dtn-interest] Comments on draft-irtf-dtnrg-arch-00.txt 
Date: Sat, 26 Apr 2003 18:50:17 -0400
From: Craig Partridge <[email-masked]>
Sender: [email-masked]

In message <[email-masked]>, Warthman Associat

>The logical equivalent of "should" in RFC 2119 is:
>
>if <valid_reason> then need_not_implement else must_implement

I think this makes sense.  Only the most arrogant think that they can
completely define/determine the future.  So ennumerating valid reasons
is a hopeless task.  So why not simply accept they exist?

Craig

Date: Sat, 26 Apr 2003 15:48:25 -0700
To: Warthman Associates <[email-masked]>, Scott  Bradner <[email-masked]>, [email-masked], Petre Dini <[email-masked]>
From: Petre Dini <[email-masked]>
Subject: Re: [dtn-interest] Comments on SHOULD
Cc: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Sender: [email-masked]

--=====================_14679498==_.ALT
Content-Type: text/plain; charset="us-ascii"; format=flowed

Forrest,

It was my point also in my preceding e-mail; your e-mail fits on mine 
almost perfectly.

E-mail-wise, the only different venue for continuing the discussion I saw, 
was to change the subject in "Comments on "SHOULD" to let people desiring 
to discuss to continue to comment on a precise topic. So, only those 
interested to contribute will continue the discussion, which is fair!

IETF-wise, as I said, I'm writing this document, and now, as Scott 
suggested in his e-mail the path

 >> the way to get things done in the IETF is to write an Internet Draft
 >> and submit it - once it is published send a note to the IETF list
 >> to see if you can get a discussion going

I really intend to follow this path.

I will draft a more organized strawman and exchange with those interested 
then go on the IETF.

Who want then to continue the discussion and contribute to the Internet Draft?
Are you Forest willing to contribute/cooperate on a document on this topic?
Who else?

Thanks,
Petre

At 03:21 PM 4/26/2003 -0700, Warthman Associates wrote:
>Scott,
>
>I think the IETF needs to reconsider this issue. Here's an even shorter 
>summary of my argument:
>
>The logical equivalent of "should" in RFC 2119 is:
>
>if <valid_reason> then need_not_implement else must_implement
>
>However, an external testing agent (such as code executing on, or data 
>flowing through, an implementation of the architecture) is unable to judge 
>the validity or even the existence of the reason, which is the condition 
>of the if-then-else branch, so from the agent's viewpoint the architecture 
>seems to treat the implementation of the function as a may.
>
>It would be useful, of course, for an architecture to specify that a 
>state-flag be set according to whether the function in question has or has 
>not been implemented. This helps external agents, but it does not fix the 
>problem of incompatible implementations of the architecture: some will 
>implement the function, others won't. So, we're stuck with a mixed batch 
>of implementations -- not a great situation in a world of growing 
>software-interoperability problems.
>
>If you'd like to suggest a different venue in which to carry on this 
>discussion, please do so.
>
>Forrest
>
>-----------------------------------------------------------------
>Forrest Warthman       Warthman Associates      Technical Writers
>2417 Embarcadero Way   Palo Alto, CA 94303   [email-masked]
>(650)494-8555          (650)857-1815 fax         www.warthman.com
>
>
>
>At 01:22 PM 4/26/2003, Scott  Bradner wrote:
>> > Any input and/or position is appreciated,
>>
>>I think there is dead horse beating going on here - as Bob
>>pointed out, this terminology has been in use in the IETF for quite a long
>>time and I've never heard of anyone getting confused (well, I do recall one
>>case where someone wanted to be confused because he did not want the
>>requirement to be that strong) - in addition RFC 2119 went through IETF
>>last call in which it got quite a bit of review as far as I can recall
>>SHOULD was never brought up as an issue.
>>
>>That said, anyone can write an Internet Draft and suggest to the IESG that
>>it be considered for publication as a BCP or to the RFC Ed that it be
>>considered for publication as an Informational RFC.
>>
>>but I would think that there are rather many higher priority issues to
>>be looked at than trying to aditionally clarify some text that most
>>people have felt was quite clear since long before 2119 was published.
>>
>>Scott

--=====================_14679498==_.ALT
Content-Type: text/html; charset="us-ascii"

<html>
Forrest,<br>
<br>
It was my point also in my preceding e-mail; your e-mail fits on mine
almost perfectly.<br>
<br>
E-mail-wise, the only different venue for continuing the discussion I
saw, was to change the subject in &quot;Comments on &quot;SHOULD&quot; to
let people desiring to discuss to continue to comment on a precise topic.
So, only those interested to contribute will continue the discussion,
which is fair!<br>
<br>
<br>
IETF-wise, as I said, I'm writing this document, and now, as Scott
suggested in his e-mail the path<br>
<br>
<font color="#0000FF">&gt;&gt; the way to get things done in the IETF is
to write an Internet Draft<br>
&gt;&gt; and submit it - once it is published send a note to the IETF
list <br>
&gt;&gt; to see if you can get a discussion going<br>
<br>
</font>I really intend to follow this path.  <br>
<br>
I will draft a more organized strawman and exchange with those interested
then go on the IETF.<br>
<br>
Who want then to continue the discussion and contribute to the Internet
Draft?<br>
Are you Forest willing to contribute/cooperate on a document on this
topic?<br>
Who else?<br>
<br>
Thanks,<br>
Petre<br>
&nbsp;<br>
<br>
<br>
<br>
At 03:21 PM 4/26/2003 -0700, Warthman Associates wrote:<br>
<blockquote type=cite cite>Scott,<br>
<br>
I think the IETF needs to reconsider this issue. Here's an even shorter
summary of my argument:<br>
<br>
The logical equivalent of &quot;should&quot; in RFC 2119 is:<br>
<br>
<b>if </b><i>&lt;valid_reason&gt;</i> <b>then </b>need_not_implement<b>
else </b>must_implement<br>
<br>
However, an external testing agent (such as code executing on, or data flowing through, an implementation of the architecture) is unable to judge the validity or even the existence of the reason, which is the condition of the if-then-else branch, so from the agent's viewpoint the architecture seems to treat the implementation of the function as a <b>may</b>. <br>
<br>
It would be useful, of course, for an architecture to specify that a state-flag be set according to whether the function in question has or has not been implemented. This helps external agents, but it does not fix the problem of incompatible implementations of the architecture: some will implement the function, others won't. So, we're stuck with a mixed batch of implementations -- not a great situation in a world of growing software-interoperability problems. <br>
<br>
If you'd like to suggest a different venue in which to carry on this discussion, please do so. <br>
<br>
Forrest<br>
<br>
-----------------------------------------------------------------<br>
Forrest Warthman&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Warthman Associates&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Technical Writers<br>
2417 Embarcadero Way&nbsp;&nbsp; Palo Alto, CA 94303&nbsp;&nbsp; [email-masked]<br>
(650)494-8555&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; (650)857-1815 fax&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <a href="http://www.warthman.com/" eudora="autourl">www.warthman.com</a><br>
<br>
<br>
<br>
At 01:22 PM 4/26/2003, Scott&nbsp; Bradner wrote:<br>
<blockquote type=cite cite>&gt; Any input and/or position is appreciated,<br>
<br>
I think there is dead horse beating going on here - as Bob<br>
pointed out, this terminology has been in use in the IETF for quite a long <br>
time and I've never heard of anyone getting confused (well, I do recall one<br>
case where someone wanted to be confused because he did not want the <br>
requirement to be that strong) - in addition RFC 2119 went through IETF <br>
last call in which it got quite a bit of review as far as I can recall <br>
SHOULD was never brought up as an issue.<br>
<br>
That said, anyone can write an Internet Draft and suggest to the IESG that<br>
it be considered for publication as a BCP or to the RFC Ed that it be <br>
considered for publication as an Informational RFC.<br>
<br>
but I would think that there are rather many higher priority issues to<br>
be looked at than trying to aditionally clarify some text that most<br>
people have felt was quite clear since long before 2119 was published.<br>
<br>
Scott</blockquote></blockquote></html>

--=====================_14679498==_.ALT--

Date: Sat, 26 Apr 2003 18:25:54 -0400 (EDT)
From: Scott  Bradner <[email-masked]>
To: [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: [dtn-interest] Comments on draft-irtf-dtnrg-arch-00.txt
Cc: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Sender: [email-masked]

> If you'd like to suggest a different venue in which to carry on this 
> discussion, please do so.

the way to get things done in the IETF is to write an Internet Draft
and submit it - once it is published send a note to the IETF list 
to see if you can get a discussion going

Scott

Date: Sat, 26 Apr 2003 15:21:09 -0700
To: Scott  Bradner <[email-masked]>, [email-masked], [email-masked]
From: Warthman Associates <[email-masked]>
Subject: Re: [dtn-interest] Comments on draft-irtf-dtnrg-arch-00.txt
Cc: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Sender: [email-masked]

--=====================_160380835==.ALT
Content-Type: text/plain; charset="us-ascii"; format=flowed

Scott,

I think the IETF needs to reconsider this issue. Here's an even shorter 
summary of my argument:

The logical equivalent of "should" in RFC 2119 is:

if <valid_reason> then need_not_implement else must_implement

However, an external testing agent (such as code executing on, or data 
flowing through, an implementation of the architecture) is unable to judge 
the validity or even the existence of the reason, which is the condition of 
the if-then-else branch, so from the agent's viewpoint the architecture 
seems to treat the implementation of the function as a may.

It would be useful, of course, for an architecture to specify that a 
state-flag be set according to whether the function in question has or has 
not been implemented. This helps external agents, but it does not fix the 
problem of incompatible implementations of the architecture: some will 
implement the function, others won't. So, we're stuck with a mixed batch of 
implementations -- not a great situation in a world of growing 
software-interoperability problems.

If you'd like to suggest a different venue in which to carry on this 
discussion, please do so.

Forrest

-----------------------------------------------------------------
Forrest Warthman       Warthman Associates      Technical Writers
2417 Embarcadero Way   Palo Alto, CA 94303   [email-masked]
(650)494-8555          (650)857-1815 fax         www.warthman.com

At 01:22 PM 4/26/2003, Scott  Bradner wrote:
> > Any input and/or position is appreciated,
>
>I think there is dead horse beating going on here - as Bob
>pointed out, this terminology has been in use in the IETF for quite a long
>time and I've never heard of anyone getting confused (well, I do recall one
>case where someone wanted to be confused because he did not want the
>requirement to be that strong) - in addition RFC 2119 went through IETF
>last call in which it got quite a bit of review as far as I can recall
>SHOULD was never brought up as an issue.
>
>That said, anyone can write an Internet Draft and suggest to the IESG that
>it be considered for publication as a BCP or to the RFC Ed that it be
>considered for publication as an Informational RFC.
>
>but I would think that there are rather many higher priority issues to
>be looked at than trying to aditionally clarify some text that most
>people have felt was quite clear since long before 2119 was published.
>
>Scott

--=====================_160380835==.ALT
Content-Type: text/html; charset="us-ascii"

<html>
<body>
Scott,<br><br>
I think the IETF needs to reconsider this issue. Here's an even shorter
summary of my argument:<br><br>
The logical equivalent of &quot;should&quot; in RFC 2119 is:<br><br>
<b>if </b><i>&lt;valid_reason&gt;</i> <b>then </b>need_not_implement<b>
else </b>must_implement<br><br>
However, an external testing agent (such as code executing on, or data flowing through, an implementation of the architecture) is unable to judge the validity or even the existence of the reason, which is the condition of the if-then-else branch, so from the agent's viewpoint the architecture seems to treat the implementation of the function as a <b>may</b>. <br><br>
It would be useful, of course, for an architecture to specify that a state-flag be set according to whether the function in question has or has not been implemented. This helps external agents, but it does not fix the problem of incompatible implementations of the architecture: some will implement the function, others won't. So, we're stuck with a mixed batch of implementations -- not a great situation in a world of growing software-interoperability problems. <br><br>
If you'd like to suggest a different venue in which to carry on this discussion, please do so. <br><br>
Forrest<br><br>
-----------------------------------------------------------------<br>
Forrest Warthman&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Warthman Associates&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Technical Writers<br>
2417 Embarcadero Way&nbsp;&nbsp; Palo Alto, CA 94303&nbsp;&nbsp; [email-masked]<br>
(650)494-8555&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; (650)857-1815 fax&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <a href="http://www.warthman.com/" eudora="autourl">www.warthman.com<br><br>
<br><br>
</a>At 01:22 PM 4/26/2003, Scott&nbsp; Bradner wrote:<br>
<blockquote type=cite class=cite cite>&gt; Any input and/or position is appreciated,<br><br>
I think there is dead horse beating going on here - as Bob<br>
pointed out, this terminology has been in use in the IETF for quite a long <br>
time and I've never heard of anyone getting confused (well, I do recall one<br>
case where someone wanted to be confused because he did not want the <br>
requirement to be that strong) - in addition RFC 2119 went through IETF <br>
last call in which it got quite a bit of review as far as I can recall <br>
SHOULD was never brought up as an issue.<br><br>
That said, anyone can write an Internet Draft and suggest to the IESG that<br>
it be considered for publication as a BCP or to the RFC Ed that it be <br>
considered for publication as an Informational RFC.<br><br>
but I would think that there are rather many higher priority issues to<br>
be looked at than trying to aditionally clarify some text that most<br>
people have felt was quite clear since long before 2119 was published.<br><br>
Scott</blockquote></body>
</html>

--=====================_160380835==.ALT--

Date: Sat, 26 Apr 2003 14:52:10 -0700
To: Scott  Bradner <[email-masked]>
From: Petre Dini <[email-masked]>
Subject: Re: [dtn-interest] Comments on SHOULD
Cc: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], Petre Dini <[email-masked]>
Sender: [email-masked]

--=====================_11304284==_.ALT
Content-Type: text/plain; charset="us-ascii"; format=flowed

At 04:22 PM 4/26/2003 -0400, Scott  Bradner wrote:
> > Any input and/or position is appreciated,
>
>I think there is dead horse beating going on here - as Bob
>pointed out, this terminology has been in use in the IETF for quite a long
>time and I've never heard of anyone getting confused (well, I do recall one
>case where someone wanted to be confused because he did not want the
>requirement to be that strong) - in addition RFC 2119 went through IETF
>last call in which it got quite a bit of review as far as I can recall
>SHOULD was never brought up as an issue.

Your message is clear; I have no interest to duplicate any clear existing 
document.
The text is not confuse, no one said this; the choice it offers may lead to 
inconsistent decisions.
There is no magic in fixing this; I thought that learning from experience 
and guiding those implementing following the rules will be useful.

And I understood that you are not a partisan of such a need [:-) the simple 
fact that Vint and other still debate on this may shadow your position (see 
below).]

>That said, anyone can write an Internet Draft and suggest to the IESG that
>it be considered for publication as a BCP or to the RFC Ed that it be
>considered for publication as an Informational RFC.

Agree! It was not the intend. I'm working in industry now, less time for 
this, clearly!

>but I would think that there are rather many higher priority issues to
>be looked at than trying to aditionally clarify some text

I agree on this too; the point was not to clarify the text at all (see 
below), but helping on its implementation, as its interpretation may vary 
from a reason to another. When you have to simultaneously manage systems 
that implement partial subsets of a set of features, in different ways, it 
becomes a problem.

>that most
>people have felt was quite clear since long before 2119 was published.

As I already said, it was not question of clarifying the text;
It was question of HOW the cleared text MUST be considered, as we are all 
human beings, when applying it.
While there is not ambiguity in interpreting the text (we all agree on 
this), there is a lot of potential inconsistences in implementing its sayings.

:-(( Actually, I even question the fuzziness of some text chunks, only from 
the implementation and  validation perspective.
[I hope I am clear, I do not question the text per see, I simply say that 
the reader implementing it has the freedom to do it wrongly; and my 
experience is that people understanding vary.]

For example, you written:
SHOULD
This word, or the adjective "RECOMMENDED", mean that there may exist valid 
reasons in particular circumstances to ignore a particular item, but the 
full implications must be understood and carefully weighed before choosing 
a different course.

I bet that anyone has different "interested or biased, aka intentional or 
unintentional" interpretations of the following expressions: "valid 
reasons", "particular circumstances", "full implications" "carefully 
weighted". Even we semantically understand what they may mean, we end up 
with OUR valid reasons for particular implementations, in particular 
circumstances, pretending that WE carefully understood the full implications.

My position is very practical: the standards are there to easy 
interoperability, to offer a common basis, and so on. While it is almost 
impossible to capture ALL the exceptions from a rule, the need to guideline 
what a valid reason may be, what a particular circumstance may be, and 
eventually create a context-based taxonomy may help automation.

Therefore I jumped into the discussion simply to taste if you know eloquent 
cases where the implementation of the SHOULD led to inconsistencies, 
practically leading to unmanageable systems, or, contrarily, you have 
particularly successful cases.

Scott, if you have not, it is OK. Other may have.
Thanks for your input.

>Scott

I don't want to make your bandwidth busy with my e-mails.
I simply say that, when implementing, documenting SHOULD (and even MAY: for 
MAY at least we know that it will not be there) is not as simple as 
defining what they mean. And it is my feeling that some guidelines may 
help. I'm writing the document for my Cisco fellows anyway.

Wish you the best,
Petre

--=====================_11304284==_.ALT
Content-Type: text/html; charset="us-ascii"

<html>
At 04:22 PM 4/26/2003 -0400, Scott&nbsp; Bradner wrote:<br>
<blockquote type=cite cite>&gt; Any input and/or position is
appreciated,<br>
<br>
I think there is dead horse beating going on here - as Bob<br>
pointed out, this terminology has been in use in the IETF for quite a
long <br>
time and I've never heard of anyone getting confused (well, I do recall
one<br>
case where someone wanted to be confused because he did not want the
<br>
requirement to be that strong) - in addition RFC 2119 went through IETF
<br>
last call in which it got quite a bit of review as far as I can recall
<br>
SHOULD was never brought up as an issue.</blockquote><br>
Your message is clear; I have no interest to duplicate any clear existing
document.<br>
The text is not confuse, no one said this;  the choice it offers may lead
to inconsistent decisions.<br>
There is no magic in fixing this; I thought that learning from experience
and guiding those implementing following the rules will be useful.  
<br>
<br>
And I understood that you are not a partisan of such a need [:-) the
simple fact that Vint and other still debate on this may shadow your
position (see below).]<br>
<br>
<br>
<blockquote type=cite cite>That said, anyone can write an Internet Draft
and suggest to the IESG that<br>
it be considered for publication as a BCP or to the RFC Ed that it be
<br>
considered for publication as an Informational RFC.</blockquote><br>
Agree! It was not the intend. I'm working in industry now, less time for
this, clearly!<br>
<br>
<br>
<blockquote type=cite cite>but I would think that there are rather many
higher priority issues to<br>
be looked at than trying to aditionally clarify some text
</blockquote><br>
I agree on this too; the point was not to clarify the text at all (see
below), but helping on its implementation, as its interpretation may vary
from a reason to another. When you have to simultaneously manage systems
that implement partial subsets of a set of features, in different ways,
it becomes a problem. <br>
<br>
<blockquote type=cite cite>that most<br>
people have felt was quite clear since long before 2119 was
published.</blockquote><br>
As I already said, it was not question of clarifying the text; <br>
It was question of HOW the cleared text MUST be considered, as we are all
human beings, when applying it. <br>
While there is not ambiguity in interpreting the text (we all agree on
this), there is a lot of potential inconsistences in implementing its
sayings. <br>
<br>
:-(( Actually, I even question the fuzziness of some text chunks, only
from the implementation and&nbsp; validation perspective. <br>
[I hope I am clear, I do not question the text per see, I simply say that
the reader implementing it has the freedom to do it wrongly; and my
experience is that people understanding vary.]<br>
<br>
For example, you written:<br>
<font color="#0000FF">SHOULD&nbsp;&nbsp; <br>
This word, or the adjective &quot;RECOMMENDED&quot;, mean that there may
exist valid reasons in particular circumstances to ignore a particular
item, but the full implications must be understood and carefully weighed
before choosing a different course. <br>
<br>
</font>I bet that anyone has different &quot;interested or biased, aka
intentional or unintentional&quot; interpretations of the following
expressions: &quot;valid reasons&quot;, &quot;particular
circumstances&quot;, &quot;full implications&quot; &quot;carefully
weighted&quot;. Even we semantically understand what they may mean, we
end up with OUR valid reasons for particular implementations, in
particular circumstances, pretending that WE carefully understood the
full implications. <br>
<br>
My position is very practical: the standards are there to easy
interoperability, to offer a common basis, and so on. While it is almost
impossible to capture ALL the exceptions from a rule, the need to
guideline what a valid reason may be, what a particular circumstance may
be, and eventually create a context-based taxonomy may help
automation.<br>
<br>
Therefore I jumped into the discussion simply to taste if you know
eloquent cases where the implementation of the SHOULD led to
inconsistencies, practically leading to unmanageable systems, or,
contrarily, you have particularly successful cases. <br>
<br>
Scott, if you have not, it is OK. Other may have. <br>
Thanks for your input.<br>
<br>
<br>
<blockquote type=cite cite>Scott </blockquote><br>
I don't want to make your bandwidth busy with my e-mails. <br>
I simply say that, when implementing, documenting SHOULD (and even MAY:
for MAY at least we know that it will not be there) is not as simple as
defining what they mean. And it is my feeling that some guidelines may
help. I'm writing the document for my Cisco fellows anyway. <br>
<br>
Wish you the best,<br>
Petre<br>
<br>
<br>
</html>

--=====================_11304284==_.ALT--

Date: Sat, 26 Apr 2003 16:22:59 -0400 (EDT)
From: Scott  Bradner <[email-masked]>
To: [email-masked], [email-masked]
Subject: Re: [dtn-interest] Comments on draft-irtf-dtnrg-arch-00.txt
Cc: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Sender: [email-masked]

> Any input and/or position is appreciated,

I think there is dead horse beating going on here - as Bob
pointed out, this terminology has been in use in the IETF for quite a long 
time and I've never heard of anyone getting confused (well, I do recall one
case where someone wanted to be confused because he did not want the 
requirement to be that strong) - in addition RFC 2119 went through IETF 
last call in which it got quite a bit of review as far as I can recall 
SHOULD was never brought up as an issue.

That said, anyone can write an Internet Draft and suggest to the IESG that
it be considered for publication as a BCP or to the RFC Ed that it be 
considered for publication as an Informational RFC.

but I would think that there are rather many higher priority issues to
be looked at than trying to aditionally clarify some text that most
people have felt was quite clear since long before 2119 was published.

Scott

Date: Sat, 26 Apr 2003 13:14:11 -0700
To: "vinton g. cerf" <[email-masked]>
From: Petre Dini <[email-masked]>
Subject: Re: [dtn-interest] Comments on draft-irtf-dtnrg-arch-00.txt
Cc: Warthman Associates <[email-masked]>, Craig Partridge <[email-masked]>, Kevin Fall <[email-masked]>, [email-masked], "Adrian J. Hooke" <[email-masked]>, "J. Leigh Torgerson" <[email-masked]>, Scott Bradner <[email-masked]>, Scott Burleigh <[email-masked]>, Petre Dini <[email-masked]>
Sender: [email-masked]

--=====================_5425611==_.ALT
Content-Type: text/plain; charset="us-ascii"; format=flowed

At 06:31 AM 4/23/2003 -0400, vinton g. cerf wrote:
>"May omit" suggests that the item is not particularly important
>"should include" suggests it is important and should [that word!!] be 
>omitted ONLY if there is a good reason.

The problem is that a good reason for me may be a unreasonable one for you; 
therefore, I would suggest that every time 'should' is used, a general 
waiving condition, or, at least, a context-related condition be used as an 
example to clarify why a certain requirement is 'must', and other is just 
'should'. In practice, most of implementers understand 'should' as an 
optional label for a requirement, which is totally wrong. This leads to 
inconsistent implementations of apparently well understood and agreed upon 
requirements. A lot of examples exist.

>there IS a nuance there that should [that word again!] not be overlooked.

I'm thinking on a draft document for personal and internal purposes on 
exemplifying different kinds of exceptions and clarifying what kind of 
waiving is suitable and what kind is not.

If someone considers that such a document could be useful and on a general 
interest, please advise and contribute with your experience on concrete 
examples of 'like-this' and 'not-like-this'.

The structure of the strawnam document on " Use Cases Guidelines for SHOULD 
requirements in Internet Standard Documents" might be as following and is 
intended as Internet Best Current Practices for the Internet Community:

1. Short recall on MUST, SHOULD, and MAY and dialects [RFC 2119 and other ]
2. Guidelines for SHOULD Waiving Cases
2.1 Technology implementation reasons
2.2 Critical mass reasons
2.3 Cost reasons
2.4 Complexity Implementation reasons
2.5 Dependencies on other standard reasons
2.6 Functional dependency reasons
2.7 Market segment reasons
2.x Others .....
3. Notorius SHOULD-related cases
3.1 Good implementation decisions
3.2 Clearly bad implementation decisions
4. Conclusion

Any input and/or position is appreciated,

-- Petre

>:-)
>
>vint
>
>At 10:33 AM 4/22/2003 -0700, Warthman Associates wrote:
> >I've copied Scott Bradner at Harvard on this discussion, because he is 
> the author of RFC 2119. Scott, I welcome your comments.
> >
> >And, after I have another coffee and read the OED dictionary again, I'll 
> get together -- perhaps in Cleveland -- with Adrian, Leigh, and other 
> alleged truth-tellers to start working on DTNRG Resolution 1441.
> >
> >Forrest
>
>Vint Cerf
>SVP Architecture & Technology
>MCI
>22001 Loudoun County Parkway, F2-4115
>Ashburn, VA 20147
>703 886 1690 (v806 1690)
>703 886 0047 fax
>[email-masked]
>www.mci.com/cerfsup

______________________________________________
Petre Dini, Ph.D., Eng.
Senior Technical Leader, Cisco Systems, San Jose, USA
Adj. Professor, Concordia University, Montreal, Canada

Phone: +1408 8534050, Mob: +1408 8936407
Fax: +1 408 5276351, e-mail: [email-masked]
______________________________________________
Cisco Systems, 725 Alder Drive, Bldg 20/2
Milpitas, CA 95035, USA
______________________________________________

--=====================_5425611==_.ALT
Content-Type: text/html; charset="us-ascii"

<html>
At 06:31 AM 4/23/2003 -0400, vinton g. cerf wrote:<br>
<blockquote type=cite cite>&quot;May omit&quot; suggests that the item is
not particularly important<br>
&quot;should include&quot; suggests it is important and should [that
word!!] be omitted ONLY if there is a good reason.</blockquote><br>
The problem is that a <u>good reason</u> for me may be a
<u>unreasonable</u> one for you; therefore, I would suggest that every
time 'should' is used, a general waiving condition, or, at least, a
context-related condition be used as an example to clarify why a certain
requirement is 'must', and other is just 'should'. In practice, most of
implementers understand 'should' as an optional label for a requirement,
which is totally wrong. This leads to inconsistent implementations of
apparently well understood and agreed upon requirements.  A lot of
examples exist.<br>
<br>
<br>
<blockquote type=cite cite>there IS a nuance there that should [that word
again!] not be overlooked.</blockquote><br>
I'm thinking on a draft document for personal and internal purposes on
exemplifying different kinds of exceptions and clarifying what kind of
waiving is suitable and what kind is not. <br>
<br>
If someone considers that such a document could be useful and on a
general interest, please advise and contribute with your experience on
concrete examples of 'like-this' and 'not-like-this'. <br>
<br>
The structure of the strawnam document on &quot; Use Cases Guidelines for
SHOULD requirements in Internet Standard Documents&quot; might be as
following and is intended as Internet Best Current Practices for the
Internet Community:<br>
<br>
1. Short recall on MUST, SHOULD, and MAY and dialects [RFC 2119 and other
]<br>
2. Guidelines for SHOULD Waiving Cases<br>
2.1 Technology implementation reasons<br>
2.2 Critical mass reasons<br>
2.3 Cost reasons<br>
2.4 Complexity Implementation reasons<br>
2.5 Dependencies on other standard reasons<br>
2.6 Functional dependency reasons<br>
2.7 Market segment reasons<br>
2.x Others .....<br>
3. Notorius SHOULD-related cases<br>
3.1 Good implementation decisions<br>
3.2 Clearly bad implementation decisions<br>
4. Conclusion<br>
<br>
Any input and/or position is appreciated,<br>
<br>
-- Petre<br>
<br>
<br>
<blockquote type=cite cite>:-)<br>
<br>
vint<br>
<br>
At 10:33 AM 4/22/2003 -0700, Warthman Associates wrote:<br>
&gt;I've copied Scott Bradner at Harvard on this discussion, because he
is the author of RFC 2119. Scott, I welcome your comments.<br>
&gt;<br>
&gt;And, after I have another coffee and read the OED dictionary again,
I'll get together -- perhaps in Cleveland -- with Adrian, Leigh, and
other alleged truth-tellers to start working on DTNRG Resolution
1441.<br>
&gt;<br>
&gt;Forrest<br>
<br>
Vint Cerf<br>
SVP Architecture &amp; Technology<br>
MCI<br>
22001 Loudoun County Parkway, F2-4115<br>
Ashburn, VA 20147<br>
703 886 1690 (v806 1690)<br>
703 886 0047 fax<br>
[email-masked]<br>
<a href="http://www.mci.com/cerfsup" eudora="autourl">www.mci.com/cerfsup</a>
</blockquote><br>
<font size=1>______________________________________________<br>
Petre Dini, Ph.D., Eng.<br>
Senior Technical Leader, Cisco Systems, San Jose, USA<br>
Adj. Professor, Concordia University, Montreal, Canada<br>
<br>
Phone: +1408 8534050, Mob: +1408 8936407<br>
Fax: +1 408 5276351, e-mail: [email-masked]&nbsp;&nbsp; <br>
______________________________________________<br>
Cisco Systems, 725 Alder Drive, Bldg 20/2<br>
Milpitas, CA 95035, USA<br>
______________________________________________<br>
<br>
<br>
</font></html>

--=====================_5425611==_.ALT--

Date: Fri, 25 Apr 2003 11:32:56 -0700
To: [email-masked]
From: Scott Burleigh <[email-masked]>
Subject: Re: types of contact (was: Re: [dtn-interest] Comments on draft-irtf-dtnrg-arch-00.txt)
Sender: [email-masked]

At 08:03 PM 4/22/2003 +0100, Stephen Farrell wrote:

>Scott,
>
>As I said, I really like the idea of trying to classify
>the types of contact that exist and we might even have
>the right classification in front of us already, but I'm
>not yet sure of that.
>
>Perhaps we need to make a list of the different contact
>scenarios we envisage and then show how each falls under
>one of the classes and also that the classes are handled
>differently by bundle routing software. Sounds like a lot
>of work though (you guys almost certainly did some of
>that already), but maybe something to chat about in LA.
>
>Let me give an example of where I'm not sure whether the
>current classes are right.
>
>Assume that lots of sensor nodes can be edge routers and
>that bundles are (somehow) flooded out to all edge routers
>to await a contact with the outside world. Once bundles are
>picked up (taken into custody by the peer router), the custody
>ACKs need to be flooded back to release storage at the sensor
>network's edge routers.
>
>An edge router in that case might be aware that contacts will
>occur between 9am and 10am (when the person carrying the peer
>router goes by) but with a quite low probability (say just 1%
>for a given sensor node/edge router) that a contact will occur
>on any given day. I think (but am not sure really) that the
>number of nodes involved, the success probability and the
>duration and frequency of the time windows involved may be
>important in how a sensor network's overall power usage is
>handled and may well determine whether flooding within the
>sensor network is the "right" approach to routing bundles.
>
>Anyway - is that contact intermittent scheduled or intermittent
>opportunistic?

It's intermittent opportunistic, since you don't assume connectivity at a 
given time and act on that assumption (i.e., start transmitting): you 
listen for a hail of some sort before you start acting on a presumption of 
connectivity.

The schedule element does seem to fog the issue a little, but I think the 
way to clarify things is to recognize what is being 
scheduled.  Connectivity itself is not scheduled in this scenario; all that 
is scheduled is the period when it's worthwhile to spend power listening 
for a hail.

>I guess I could argue either way. (Though since you kind of
>outlawed flooding in the draft, maybe my scenario is a bit of
>a cheat?)
>
>I guess what I'm stumbling towards is a classication based not
>on named/defined classes, but rather on numbers related to the
>independent variables that (primarily) determine how many bytes
>are likely to be transferred per contact. (As you hinted when
>you talked about on-demand in terms of probability.)

Except that in this case we can do better than a single number, such as 
expected number of bytes transferred over a given interval, because we've 
got better information (a white box rather than a black box).

One number is the availability of hailing, which is a Boolean: during the 
scheduled times when you know there's no one to talk to, you will conserver 
power by turning off your receiver, so this value is False.

Only when the availability of hailing is True does the probability of a 
contact (1%) become a potential factor in your routing decisions.  You 
could route on this probability (a pretty low-quality intermittent 
predicted contact), but if you're in a low-delay environment as described 
you are way better off if you wait for a real contact before routing (an 
intermittent opportunistic contact).

And data rate -- which might be either scheduled or negotiated, I guess -- 
is yet another number that you could use in making routing decisions.

The classification scheme is helpful conceptually, and it is probably 
helpful in thinking about the organization of code in the implementation of 
the protocol.  I agree with you that routing decisions should be made on 
better information than just class of contact, i.e., on numbers, but I 
don't think we would gain much by basing the contact classification scheme 
on those numbers.  The classes derive their value from precisely the fact 
that they are qualitative rather than quantitative.

>Scott Burleigh wrote:
>>At 04:36 PM 4/21/2003 -0700, Warthman Associates wrote:
>>
>>>>>Sec. 3.8.1 (p. 10): Type of Routes
>>>>>----------------------------------
>>>>>
>>>>>"On-Demand Contacts": What is the functional difference between 
>>>>>"On-Demand Contacts" and "Intermittent - Opportunistic Contacts"?
>>>>
>>>>
>>>>I think it's this:
>>>>
>>>>         Permanent contacts never start and never stop.
>>>>
>>>>         On-demand contacts start whenever you want them to and never 
>>>> stop until you're done with them.
>>>>
>>>>         Intermittent scheduled contacts start when a predefined plan 
>>>> says they will and stop when that plan says they stop.
>>>>
>>>>         Intermittent opportunistic contacts start at an unpredictable 
>>>> time and stop at some subsequent unpredictable time.
>>>
>>>
>>>I still don't see any difference between "On-Demand Contacts" and 
>>>"Intermittent - Opportunistic Contacts". You have used different words 
>>>for each, but the meanings can be viewed as identical: "start whenever 
>>>you want" = "start at an unpredictable time", and "never stop until 
>>>you're done with them" = "stop at some subsequent unpredictable time".
>>
>>No, I think the difference between these is clear and critical.  "start 
>>whenever you want them to" means that YOU are in control of the contact's 
>>beginning and ending times; the link capacity is a freely available 
>>resource, like tap water, which you turn on and off as you like.  "start 
>>at an unpredictable time" means that events beyond not only your control 
>>but also your understanding will determine the contact's beginning and 
>>ending times; the link capacity is a caprice of the gods, like rainfall, 
>>which will happen whenever it feels like it.
>>In some apartment buildings, of course, the line between the two may blur 
>>somewhat.
>>
>>>>         Intermittent predicted contacts are like intermittent 
>>>> opportunistic contacts except that the predictability of their start 
>>>> and stop times is some value between zero (opportunistic) and 1 (scheduled).
>>>
>>>
>>>Right. A related issue, however: the predictability of actually 
>>>achieving contact for a scheduled contact will sometimes be less than 1, 
>>>because the scheduled contact may not occur due to unknown circumstances.
>>
>>Very true, but that deviation from absolute predictability is something 
>>you ignore in operations (although you certainly give it due attention in 
>>crafting your fault protection and recovery procedures).

From: Bob Braden <[email-masked]>
Date: Fri, 25 Apr 2003 09:23:55 -0700 (PDT)
To: [email-masked], [email-masked]
Subject: Re: [dtn-interest] summary thoughts about "should"
Cc: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Sender: [email-masked]

  *> 
  *> 
  *> Even in documents intended for general discussion, as the name "Request for 
  *> Comments" implies, I think it is useful for writers to ask what they really 
  *> mean by "should". For example, saying "implementations should split 
  *> available bandwidth into subcarriers" has less information then "to 
  *> mitigate the effects of time-dispersion, implementations should split 
  *> available bandwidth into subcarriers". The second version states the 
  *> condition of the "should". In this sense, "shoulds" can be viewed as 
  *> if-then conditionals:
  *> 
  *>    ... if <condition> ... should <action>
  *> 
  *> Unlike if-then conditionals, however, the above syntax leaves open the 
  *> question of whether the should <action> is a "must" or a "may" -- and 
  *> perhaps the *expression of that uncertainty* is the unique value of the 
  *> word "should".
  *> 

It seems a bit wierd to me that this mailing list should be discussing
this topic, but I can't stay out, since it happens that I invented the
MUST/SHOULD/MAY terminology myself while writing RFCs 1122-1123.

The Internet pioneers were masters of carefully=crafted ambiguity.
(They were Computer Scientists, not engineers; they believed in
specifying precisely what has to be specified, but no more.)  I
personally believe that the long-lasting success of their work is
partly a result of this ambiguity, as it allowed scope for adapting to
new circumstances.  [Just because you CAN specify every last detail of
a protocol implementation, that does not mean you *should*. ;-))

Now, SHOULD is an good example of this deliberate ambiguity.  The main
reason for using SHOULD is that you cannot foresee the complete set of
conditions that may in the future lead to a violation of the SHOULD.
"SHOULD " means that the preponderance of current wisdom says X is far
preferable and it will make things work better if everyone does X, but
that we can imagine some circumstances that may be exceptional or
special-case where one might decide to not do X.

Compliance is not a Boolean quantity.  That is meant to be the lesson
of RFCs 1122-1123.

Bob Braden

Date: Thu, 24 Apr 2003 21:09:11 -0400 (EDT)
From: Scott  Bradner <[email-masked]>
To: [email-masked], [email-masked]
Subject: Re: [dtn-interest] summary thoughts about "should"
Cc: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Sender: [email-masked]

as a general rule the IRTF does not produce standards
track douments - <draft-irtf-dtnrg-arch-00> will be published
as an informational RFC (when it comes time to publish it)

> Here's a quick summary of my concerns about "should" and "should not" in 
> precise specifications:
> 
> - UNKNOWABILITY: Both RFCs 1122 and 2119 say "SHOULD ... means ... there 
> may exist valid reasons [to not implement a feature] ... but the full 
> implications must be understood ...". The "full" implications, however, are 
> never knowable and therefore always (at least partially) undefined, in the 
> same sense that the set of "all future events" is unknowable and undefined. 
> (This unknowability is probably one reason we have a growing 
> software-interoperability problem.)

the intent is that a vendor needs to think very hard before deciding to not
implement a SHOULD - and, to the best of their ability, need to
try to understand as many of the consequences of not implementing the 
feature

> - CONFUSED INTERPRETATION: Most dictionaries define "should" as expressing 
> "duty or obligation" or "conditionality". The former is close to "must", 
> and my unabridged dictionary says "should" and "must" can be synonyms, but 
> RFCs 1122 and 2119 imply that "should" means "may". When "should" is 
> intended to express conditionality, as in "Were she to have spoken, I 
> should have listened", many such uses don't specify the condition: they 
> just say, "I should have listened". So, there is potential confusion about 
> the interpretation of the word. Is it "must" or "may", and what is the 
> condition?

SHOULD != MAY
SHOULD == MUST unless you think you have a very good reason not to
MAY == ok to implement, ok to not implement

> - AFFECT ON UNIFORM IMPLEMENTATIONS: To ensure uniformity of architectural 
> implementations, each implementation need only implement all "musts" and 
> avoid all "must nots". Any "shoulds", "should nots", or "may omits" can be 
> ignored, misunderstood, or lied about, because their handling doesn't 
> affect implementation uniformity and the motives for their handling cannot 
> be detected by an external observer (such as executable code) that tests 
> uniformity.

if a vendor lies about what they implement it will not do them much
good in the long run

to me conformant a vendor must implement all SHOULD unless they can 
explain to their potential customers whay they did not and the customer
accepts that explanation

> Even in documents intended for general discussion, as the name "Request for 
> Comments" implies, I think it is useful for writers to ask what they really 
> mean by "should". For example, saying "implementations should split 
> available bandwidth into subcarriers" has less information then "to 
> mitigate the effects of time-dispersion, implementations should split 
> available bandwidth into subcarriers". The second version states the 
> condition of the "should". In this sense, "shoulds" can be viewed as 
> if-then conditionals:
>    ... if <condition> ... should <action>

> Unlike if-then conditionals, however, the above syntax leaves open the 
> question of whether the should <action> is a "must" or a "may" -- and 
> perhaps the *expression of that uncertainty* is the unique value of the 
> word "should".

RFC != Request for Comments (and has not for quite a few years
RFC is a brand name and means "RFC"

in the (many) years that the IETF has been using this termonology 
few people have said that they were confused - maybe they suppress
their confusion well, but I've not seen an issue with vendors
or working groups

Scott

Date: Thu, 24 Apr 2003 17:53:53 -0700
To: "vinton g. cerf" <[email-masked]>
From: Warthman Associates <[email-masked]>
Subject: [dtn-interest] summary thoughts about "should"
Cc: [email-masked], Scott Bradner <[email-masked]>, Craig Partridge <[email-masked]>, "J. Leigh Torgerson" <[email-masked]>, Kevin Fall <[email-masked]>, Scott Burleigh <[email-masked]>, "Adrian J. Hooke" <[email-masked]>
Sender: [email-masked]

--=====================_20651955==.ALT
Content-Type: text/plain; charset="us-ascii"; format=flowed

Vint,

At 03:31 AM 4/23/2003, vinton g. cerf wrote:
>"May omit" suggests that the item is not particularly important
>"should include" suggests it is important and should [that word!!] be 
>omitted ONLY if there is a good reason.
>
>there IS a nuance there that should [that word again!] not be overlooked.
>
>:-)
>
>vint

Yes, I certainly agree such nuances may be useful in general discussions 
about ideas.

Perhaps the divergent views on this issue stem from different assumptions 
about the purpose of the <draft-irtf-dtnrg-arch-00> document and the IETF's 
various categories of RFCs: which of them are intended for general 
discussions about ideas, and which are intended as precise technical 
specifications?

I have assumed (perhaps incorrectly) that the <draft-irtf-dtnrg-arch-00> 
falls into the latter group, because in my world of commercial 
microprocessors an "architecture document" normally implies a precise 
technical specification. I also have assumed that an essential purpose of 
an architectural specification is to ensure *uniform implementation*, so 
that the implementations are compatible.

Here's a quick summary of my concerns about "should" and "should not" in 
precise specifications:

- UNKNOWABILITY: Both RFCs 1122 and 2119 say "SHOULD ... means ... there 
may exist valid reasons [to not implement a feature] ... but the full 
implications must be understood ...". The "full" implications, however, are 
never knowable and therefore always (at least partially) undefined, in the 
same sense that the set of "all future events" is unknowable and undefined. 
(This unknowability is probably one reason we have a growing 
software-interoperability problem.)

- CONFUSED INTERPRETATION: Most dictionaries define "should" as expressing 
"duty or obligation" or "conditionality". The former is close to "must", 
and my unabridged dictionary says "should" and "must" can be synonyms, but 
RFCs 1122 and 2119 imply that "should" means "may". When "should" is 
intended to express conditionality, as in "Were she to have spoken, I 
should have listened", many such uses don't specify the condition: they 
just say, "I should have listened". So, there is potential confusion about 
the interpretation of the word. Is it "must" or "may", and what is the 
condition?

- AFFECT ON UNIFORM IMPLEMENTATIONS: To ensure uniformity of architectural 
implementations, each implementation need only implement all "musts" and 
avoid all "must nots". Any "shoulds", "should nots", or "may omits" can be 
ignored, misunderstood, or lied about, because their handling doesn't 
affect implementation uniformity and the motives for their handling cannot 
be detected by an external observer (such as executable code) that tests 
uniformity.

Even in documents intended for general discussion, as the name "Request for 
Comments" implies, I think it is useful for writers to ask what they really 
mean by "should". For example, saying "implementations should split 
available bandwidth into subcarriers" has less information then "to 
mitigate the effects of time-dispersion, implementations should split 
available bandwidth into subcarriers". The second version states the 
condition of the "should". In this sense, "shoulds" can be viewed as 
if-then conditionals:

   ... if <condition> ... should <action>

Unlike if-then conditionals, however, the above syntax leaves open the 
question of whether the should <action> is a "must" or a "may" -- and 
perhaps the *expression of that uncertainty* is the unique value of the 
word "should".

All the best,
Forrest

--=====================_20651955==.ALT
Content-Type: text/html; charset="us-ascii"

<html>
<body>
Vint,<br><br>
At 03:31 AM 4/23/2003, vinton g. cerf wrote:<br>
<blockquote type=cite class=cite cite>&quot;May omit&quot; suggests that
the item is not particularly important<br>
&quot;should include&quot; suggests it is important and should [that
word!!] be omitted ONLY if there is a good reason.<br><br>
there IS a nuance there that should [that word again!] not be
overlooked.<br><br>
:-)<br><br>
vint</blockquote><br><br>
Yes, I certainly agree such nuances may be useful in general discussions
about ideas. <br><br>
Perhaps the divergent views on this issue stem from different assumptions
about the purpose of the &lt;draft-irtf-dtnrg-arch-00&gt; document and
the IETF's various categories of RFCs: which of them are intended for
general discussions about ideas, and which are intended as precise
technical specifications? <br><br>
I have assumed (perhaps incorrectly) that the
&lt;draft-irtf-dtnrg-arch-00&gt; falls into the latter group, because in
my world of commercial microprocessors an &quot;architecture
document&quot; normally implies a precise technical specification. I also
have assumed that an essential purpose of an architectural specification
is to ensure *uniform implementation*, so that the implementations are
compatible. <br><br>
<br>
Here's a quick summary of my concerns about &quot;should&quot; and
&quot;should not&quot; in precise specifications:<br><br>
- UNKNOWABILITY: Both RFCs 1122 and 2119 say &quot;SHOULD ... means ...
there may exist valid reasons [to not implement a feature] ... but the
full implications must be understood ...&quot;. The &quot;full&quot;
implications, however, are never knowable and therefore always (at least
partially) undefined, in the same sense that the set of &quot;all future
events&quot; is unknowable and undefined. (This unknowability is probably
one reason we have a growing software-interoperability problem.)
<br><br>
- CONFUSED INTERPRETATION: Most dictionaries define &quot;should&quot; as
expressing &quot;duty or obligation&quot; or &quot;conditionality&quot;.
The former is close to &quot;must&quot;, and my unabridged dictionary
says &quot;should&quot; and &quot;must&quot; can be synonyms, but RFCs
1122 and 2119 imply that &quot;should&quot; means &quot;may&quot;. When
&quot;should&quot; is intended to express conditionality, as in
&quot;Were she to have spoken, I should have listened&quot;, many such
uses don't specify the condition: they just say, &quot;I should have
listened&quot;. So, there is potential confusion about the interpretation
of the word. Is it &quot;must&quot; or &quot;may&quot;, and what is the
condition?<br><br>
- AFFECT ON UNIFORM IMPLEMENTATIONS: To ensure uniformity of
architectural implementations, each implementation need only implement
all &quot;musts&quot; and avoid all &quot;must nots&quot;. Any
&quot;shoulds&quot;, &quot;should nots&quot;, or &quot;may omits&quot;
can be ignored, misunderstood, or lied about, because their handling
doesn't affect implementation uniformity and the motives for their
handling cannot be detected by an external observer (such as executable
code) that tests uniformity. <br><br>
<br>
Even in documents intended for general discussion, as the name
&quot;Request for Comments&quot; implies, I think it is useful for
writers to ask what they really mean by &quot;should&quot;. For example,
saying &quot;implementations should split available bandwidth into
subcarriers&quot; has less information then &quot;to mitigate the effects
of time-dispersion, implementations should split available bandwidth into
subcarriers&quot;. The second version states the condition of the
&quot;should&quot;. In this sense, &quot;shoulds&quot; can be viewed as
if-then conditionals:<br><br>
&nbsp; ... <b>if </b><i>&lt;condition&gt; </i>... <b>should
</b><i>&lt;action&gt;</i> <br><br>
Unlike if-then conditionals, however, the above syntax leaves open the
question of whether the <b>should </b><i>&lt;action&gt;</i> is a
&quot;must&quot; or a &quot;may&quot; -- and perhaps the *expression of
that uncertainty* is the unique value of the word &quot;should&quot;.
<br><br>
<br>
All the best,<br>
Forrest<br>
</body>
</html>

--=====================_20651955==.ALT--

Date: Thu, 24 Apr 2003 14:18:18 -0400
From: Ozgur Baris Akan <[email-masked]>
To: Stephen Farrell <[email-masked]>
CC: [email-masked], "Ian F. Akyildiz" <[email-masked]>, Jian Fang <[email-masked]>
Subject: Re: [dtn-interest] Our work on InterPlaNetary Internet: TCP-Planet
Sender: [email-masked]

Hi,

Thank you very much for your interest in our work and for your feedback. 
Please find below our explanations:

Stephen Farrell wrote:

>
> Hi,
>
> Nice paper. One thing confused me though - the blackout state.
>
> That state seems a bit strange - the TCP-planet layer is detecting the 
> blackout when (as far as I can see) the same transmitter could predict 
> the blackout in advance (and its duration) based on ephemeris data - so
> why detect it this way? 

Although the blackouts caused by movement of planets could be obtained 
from ephemeris data, there is still possibility of unexpected blackouts 
due to obscuration by some stars or spacecrafts. This also depends on 
the physical communication technology in use. For example, in case of 
usage of point-to-point optical links (which might be a case in the far 
term deployment scenario as pointed out in [Bhasin99]), these blackouts 
are more likely to occur. Therefore, TCP-Planet does not assume 
existence of ephemeris data, which enables it to handle blackouts which 
cannot be predicted from ephemeris data.

>
>
> And, even if the TCP-Planet transmitter is one or more IP hops away
> from that knowledge, then maybe something like an extension to ECN [1]
> is a better approach? What I'm suggesting is to have the router that
> does have the ephemeris data (and there has to be one I guess) signal
> a blackout using an extended ECN message which includes the predicted
> time when contact will be regained.
>
> But, perhaps you considered this but it doesn't work for some reason?

The "blackout state" in TCP-Planet can enable the sender to take actions
even before the ECN messages arrive as you suggested. Take Figure 7 on 
page 8 as an
example, during t2-t3 interval, the ACKs received at the source were sent
before the sink detected the blackout. As long as the source received those
ACKs, it can resume transmitting data at time t2. If we use ECN messages,
the source can only know that the blackout period is over at time t4.
Our Zero NIX ACKs also perform the similar functions of ECN messages, 
but it does not
require ECN capability at the router (If ECN messages are adopted, the 
router must
keep sending ECN messages before it eventually gets packets again from
the sender because it might not be able to know when the blackout is over,
after it detects that blackout is over, it also needs to send a signal to
the source to inform that the blackout is over, which should arrive the
source at time t4). Because of the very long RTT, t2-t4 interval can also
be very long and greatly affect TCP-Planet performance.
(3)The blackout scheme in TCP-Planet can also avoid blackout
mispredictions. In Figure 7, if there were no NIX ACKs received at 
t3-t4, the source
would assume that it is another blackout period. While in our scheme, 
the source
knows the blackout is over and hence keeps sending data.

>
> Cheers,
> Stephen.
>
> [1] http://www.ietf.org/rfc/rfc3168.txt

[Bhasin99] K. Bhasin, J. Hayden, J. R. Agre, L. P. Clare, T. Y. Yan, 
Advanced Communication and Networking Technologies for Mars Exploration, 
19th Annual AIAA International Communications Satellite Systems 
Conference, Toulouse, France, April 2001.

Sincerely,
Ozgur Baris Akan

Date: Thu, 24 Apr 2003 17:17:39 +0100
From: Stephen Farrell <[email-masked]>
To: "Scott,Keith L." <[email-masked]>
Cc: Ozgur Baris Akan <[email-masked]>, [email-masked], "Ian F. Akyildiz" <[email-masked]>, "Adrian J. Hooke" <[email-masked]>, "vinton.g.cerf" <[email-masked]>
Subject: Re: [dtn-interest] Our work on InterPlaNetary Internet: TCP-Planet
Sender: [email-masked]

Yep. I must read those ccsds specs someday:-)

Just a query - does SCPS-TP handle the potential for DoS and/or
the eqivalent of unexpected cleartext traffic appearing in a VPN
tunnel (which I guess TRIGTRANS will get stuck on for quite a
while;-)

I've never been quite sure of the "proper" security handling
for that situation myself.

Stephen.

Scott,Keith L. wrote:
> Stephen,
> 
> The approach does indeed work, and is spec'ed in the Space 
> Communications Protocol Standards Transport Protocol (SCPS-TP) 
> (http://www.ccsds.org/CCSDS/recommandreports.jsp#713x0b1).  SCPS-TP is a 
> set of extenstions to TCP to extend/move its operating regime.  Like TCP 
> (and Planet, I believe) SCPS-TP works in environments where you have 
> end-to-end connectivity.
> 
> SCPS-TP has a notion similar to a 'blackout state' (it causes the sender 
> to enter the TCP persist state _and_ freeze the retransmission timer). 
> In SCPS this state is signaled by both an ICMP-like message and a 
> transport layer option.  The throught is that as a link goes bad (may be 
> predicted or detected), the router can notify near-side endpoints (say 
> by keeping an LRU queue of source-destination pairs).  This notification 
> is via an ICMP-type message, so the endpoints can be several hops away 
> from the router that detects the problem.  The message causes SCPS-TP 
> senders to respond by entering the persist state.  The SCPS-TP receiver 
> also echoes a transport layer option back to the sender in case it's 
> just the receiver-side that's gone bad (and receiver->sender 
> communication is still up).  The IETF TRIGTRANS working group is just 
> now getting around to looking at things like this.
> 
>        --keith
> 
> Stephen Farrell wrote:
> 
>>
>> Hi,
>>
>> Nice paper. One thing confused me though - the blackout state.
>>
>> That state seems a bit strange - the TCP-planet layer is detecting the 
>> blackout when (as far as I can see) the same transmitter could predict 
>> the blackout in advance (and its duration) based on ephemeris data - so
>> why detect it this way?
>>
>> And, even if the TCP-Planet transmitter is one or more IP hops away
>> from that knowledge, then maybe something like an extension to ECN [1]
>> is a better approach? What I'm suggesting is to have the router that
>> does have the ephemeris data (and there has to be one I guess) signal
>> a blackout using an extended ECN message which includes the predicted
>> time when contact will be regained.
>>
>> But, perhaps you considered this but it doesn't work for some reason?
>>
>> Cheers,
>> Stephen.
>>
>> [1] http://www.ietf.org/rfc/rfc3168.txt
>>
>>
> 
> 

Date: Thu, 24 Apr 2003 11:58:14 -0400
From: "Scott,Keith L." <[email-masked]>
To: Stephen Farrell <[email-masked]>
CC: Ozgur Baris Akan <[email-masked]>, [email-masked], "Ian F. Akyildiz" <[email-masked]>, "Adrian J. Hooke" <[email-masked]>, "vinton.g.cerf" <[email-masked]>
Subject: Re: [dtn-interest] Our work on InterPlaNetary Internet: TCP-Planet
Sender: [email-masked]

Stephen,

The approach does indeed work, and is spec'ed in the Space 
Communications Protocol Standards Transport Protocol (SCPS-TP) 
(http://www.ccsds.org/CCSDS/recommandreports.jsp#713x0b1).  SCPS-TP is a 
set of extenstions to TCP to extend/move its operating regime.  Like TCP 
(and Planet, I believe) SCPS-TP works in environments where you have 
end-to-end connectivity.

SCPS-TP has a notion similar to a 'blackout state' (it causes the sender 
to enter the TCP persist state _and_ freeze the retransmission timer). 
 In SCPS this state is signaled by both an ICMP-like message and a 
transport layer option.  The throught is that as a link goes bad (may be 
predicted or detected), the router can notify near-side endpoints (say 
by keeping an LRU queue of source-destination pairs).  This notification 
is via an ICMP-type message, so the endpoints can be several hops away 
from the router that detects the problem.  The message causes SCPS-TP 
senders to respond by entering the persist state.  The SCPS-TP receiver 
also echoes a transport layer option back to the sender in case it's 
just the receiver-side that's gone bad (and receiver->sender 
communication is still up).  The IETF TRIGTRANS working group is just 
now getting around to looking at things like this.

        --keith

Stephen Farrell wrote:

>
> Hi,
>
> Nice paper. One thing confused me though - the blackout state.
>
> That state seems a bit strange - the TCP-planet layer is detecting the 
> blackout when (as far as I can see) the same transmitter could predict 
> the blackout in advance (and its duration) based on ephemeris data - so
> why detect it this way?
>
> And, even if the TCP-Planet transmitter is one or more IP hops away
> from that knowledge, then maybe something like an extension to ECN [1]
> is a better approach? What I'm suggesting is to have the router that
> does have the ephemeris data (and there has to be one I guess) signal
> a blackout using an extended ECN message which includes the predicted
> time when contact will be regained.
>
> But, perhaps you considered this but it doesn't work for some reason?
>
> Cheers,
> Stephen.
>
> [1] http://www.ietf.org/rfc/rfc3168.txt
>
>

Date: Thu, 24 Apr 2003 13:06:04 +0100
From: Stephen Farrell <[email-masked]>
To: Ozgur Baris Akan <[email-masked]>
Cc: [email-masked], "Ian F. Akyildiz" <[email-masked]>, "Adrian J. Hooke" <[email-masked]>, "vinton.g.cerf" <[email-masked]>
Subject: Re: [dtn-interest] Our work on InterPlaNetary Internet: TCP-Planet
Sender: [email-masked]

Hi,

Nice paper. One thing confused me though - the blackout state.

That state seems a bit strange - the TCP-planet layer is detecting the 
blackout when (as far as I can see) the same transmitter could predict 
the blackout in advance (and its duration) based on ephemeris data - so
why detect it this way?

And, even if the TCP-Planet transmitter is one or more IP hops away
from that knowledge, then maybe something like an extension to ECN [1]
is a better approach? What I'm suggesting is to have the router that
does have the ephemeris data (and there has to be one I guess) signal
a blackout using an extended ECN message which includes the predicted
time when contact will be regained.

But, perhaps you considered this but it doesn't work for some reason?

Cheers,
Stephen.

[1] http://www.ietf.org/rfc/rfc3168.txt

Ozgur Baris Akan wrote:
> Dear DTN Community,
> 
> We would like to introduce our research results on transport protocols
> for the InterPlaNetary Internet. Please find our paper
> 
> Ian F. Akyildiz, Ozgur B. Akan, Jian Fang, "TCP-Planet: A Reliable
> Transport Protocol for InterPlaNetary Internet", December 2002 (revised
> March 2003).
> 
> at the link
> 
> http://users.ece.gatech.edu/%7Ejfang/deepspace/TCP-Planet.pdf
> 
> 
> Any feedback is greatly appreciated. Thank you very much in advance.
> 
> Sincerely,
> 
> Ozgur B. Akan
> Research Assistant
> Broadband & Wireless Networking Laboratory
> School of Electrical & Computer Engineering
> Georgia Institute of Technology, Atlanta GA
> 
> 
> 
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> http://mailman.dtnrg.org/mailman/listinfo/dtn-interest
> 

To: [email-masked]
Date: Wed, 23 Apr 2003 13:29:22 -0700
From: Kevin Fall <[email-masked]>
Subject: [dtn-interest] list administration: subscriptions / list posting approvals / e-mail addresses
Sender: [email-masked]

A number of people have been asking me about this, so I thought I would
just remind everyone:

the dtn-interest list is currently set up so that incoming posts from
non-subscribers are not immediately delivered to the list but instead
end up in a 'pending approval queue' that I service from time to time.
The purpose of this mechanism is to avoid spam, and as far as I can tell
it does a pretty good job of it.

Now,  that said, if you change your e-mail address, you may find that
your posts are getting sent to the queue.  You can avoid this by
keeping your own subscribed address up to date.
If you want to make changes to your subscription address (or delivery
options, such as whether you want batching, etc), GO TO THIS LINK:

	http://mailman.dtnrg.org/mailman/listinfo/dtn-interest

Note that this link is also on the www.dtnrg.org web site.

Also, for inquiring minds..  at present, the e-mail list is homed
on a server at GST (east coast of USA) while the rest of dtnrg
(web site) is housed at Intel Research in Berkeley (west coast of USA).  I am
intending on migrating the home of the e-mail list to Berkeley soon, so
expect to see some sort of announcement to this effect in the next couple
of weeks.

- Kevin

Date: Wed, 23 Apr 2003 13:58:24 -0400
From: Howard Weiss <[email-masked]>
To: "vinton g. cerf" <[email-masked]>
CC: Scott Burleigh <[email-masked]>, [email-masked]
Subject: Re: [dtn-interest] Comments on draft-irtf-dtnrg-arch-00.txt
Sender: [email-masked]

Vint,

Its captured in RFC 2119/BCP 14

ftp://ftp.rfc-editor.org/in-notes/rfc2119.txt

Howie

vinton g. cerf wrote:

>scott,
>
>the rfc editor(s) learned that precision for protocol specs is vital - isn't there an RFC guide
>for Shall, May and Should (if the latter is permitted at all)?
>
>vint
>
>At 02:46 PM 4/21/2003 -0700, Scott Burleigh wrote:
>  
>
>>Loath as I am to quarrel with anybody who cares enough about English usage to raise this sort of issue (and, better yet, tell me something I didn't know), I will briefly object.  My Webster's Ninth New Collegiate gives the following as the second definition of "should": "used in auxiliary function to express obligation, propriety, or expediency".  As an example of expediency it offers "you should brush your teeth after each meal".  [Actually, the first definition listed is as an expression of condition rather than duty, as in "should you ever need us, just send up a flare".]
>>
>>In that sense it serves a valuable function in the language, occupying the ground between "must" and "may" as an alternative to the generally awkward "ought to" -- that is, going beyond permission to advocacy but stopping well short of mandate -- and is well understood in colloquial discourse.  I should hate to lose it.
>>    
>>
>
>Vint Cerf
>SVP Architecture & Technology
>MCI
>22001 Loudoun County Parkway, F2-4115
>Ashburn, VA 20147
>703 886 1690 (v806 1690)
>703 886 0047 fax
>[email-masked]
>www.mci.com/cerfsup 
>
>_______________________________________________
>dtn-interest mailing list
>[email-masked]
>http://mailman.dtnrg.org/mailman/listinfo/dtn-interest
>  
>

-- 
                                                                    
Howard Weiss      
SPARTA, Inc.
7075 Samuel Morse Drive
Columbia, MD 21046
410.872.1515 x201
410.872.8079 (fax)

Subject: Re: [dtn-interest] Comments on draft-irtf-dtnrg-arch-00.txt
From: Michael Mealling <[email-masked]>
To: "vinton g. cerf" <[email-masked]>
Cc: Scott Burleigh <[email-masked]>, [email-masked]
Organization: Harriman Heavy Industries, Inc.
Date: 23 Apr 2003 13:29:19 -0400
Sender: [email-masked]

On Mon, 2003-04-21 at 18:47, vinton g. cerf wrote:
> the rfc editor(s) learned that precision for protocol specs is vital - isn't there an RFC guide
> for Shall, May and Should (if the latter is permitted at all)?

RFC 2119....

http://www.ietf.org/rfc/rfc2119.txt

-MM

> At 02:46 PM 4/21/2003 -0700, Scott Burleigh wrote:
> >Loath as I am to quarrel with anybody who cares enough about English usage to raise this sort of issue (and, better yet, tell me something I didn't know), I will briefly object.  My Webster's Ninth New Collegiate gives the following as the second definition of "should": "used in auxiliary function to express obligation, propriety, or expediency".  As an example of expediency it offers "you should brush your teeth after each meal".  [Actually, the first definition listed is as an expression of condition rather than duty, as in "should you ever need us, just send up a flare".]
> >
> >In that sense it serves a valuable function in the language, occupying the ground between "must" and "may" as an alternative to the generally awkward "ought to" -- that is, going beyond permission to advocacy but stopping well short of mandate -- and is well understood in colloquial discourse.  I should hate to lose it.
> 
> Vint Cerf
> SVP Architecture & Technology
> MCI
> 22001 Loudoun County Parkway, F2-4115
> Ashburn, VA 20147
> 703 886 1690 (v806 1690)
> 703 886 0047 fax
> [email-masked]
> www.mci.com/cerfsup
> 
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> http://mailman.dtnrg.org/mailman/listinfo/dtn-interest

Date: Wed, 23 Apr 2003 12:58:44 -0400
From: Ozgur Baris Akan <[email-masked]>
To: [email-masked]
CC: "Ian F. Akyildiz" <[email-masked]>, "Adrian J. Hooke" <[email-masked]>, "vinton.g.cerf" <[email-masked]>
Subject: [dtn-interest] Our work on InterPlaNetary Internet: TCP-Planet
Sender: [email-masked]

Dear DTN Community,

We would like to introduce our research results on transport protocols
for the InterPlaNetary Internet. Please find our paper

Ian F. Akyildiz, Ozgur B. Akan, Jian Fang, "TCP-Planet: A Reliable
Transport Protocol for InterPlaNetary Internet", December 2002 (revised
March 2003).

at the link

http://users.ece.gatech.edu/%7Ejfang/deepspace/TCP-Planet.pdf

Any feedback is greatly appreciated. Thank you very much in advance.

Sincerely,

Ozgur B. Akan
Research Assistant
Broadband & Wireless Networking Laboratory
School of Electrical & Computer Engineering
Georgia Institute of Technology, Atlanta GA

Date: Wed, 23 Apr 2003 06:31:08 -0400
From: "vinton g. cerf" <[email-masked]>
Subject: Re: [dtn-interest] Comments on draft-irtf-dtnrg-arch-00.txt
To: Warthman Associates <[email-masked]>, Craig Partridge <[email-masked]>, Kevin Fall <[email-masked]>, [email-masked]
Cc: "Adrian J. Hooke" <[email-masked]>, "J. Leigh Torgerson" <[email-masked]>, Scott Bradner <[email-masked]>, Scott Burleigh <[email-masked]>
Sender: [email-masked]

"May omit" suggests that the item is not particularly important
"should include" suggests it is important and should [that word!!] be omitted ONLY if there is a good reason.

there IS a nuance there that should [that word again!] not be overlooked.

:-)

vint

At 10:33 AM 4/22/2003 -0700, Warthman Associates wrote:
>I've copied Scott Bradner at Harvard on this discussion, because he is the author of RFC 2119. Scott, I welcome your comments.
>
>And, after I have another coffee and read the OED dictionary again, I'll get together -- perhaps in Cleveland -- with Adrian, Leigh, and other alleged truth-tellers to start working on DTNRG Resolution 1441.
>
>Forrest

Vint Cerf
SVP Architecture & Technology
MCI
22001 Loudoun County Parkway, F2-4115
Ashburn, VA 20147
703 886 1690 (v806 1690)
703 886 0047 fax
[email-masked]
www.mci.com/cerfsup 

Date: Tue, 22 Apr 2003 20:03:45 +0100
From: Stephen Farrell <[email-masked]>
To: Scott Burleigh <[email-masked]>
Cc: [email-masked]
Subject: types of contact (was: Re: [dtn-interest] Comments on draft-irtf-dtnrg-arch-00.txt)
Sender: [email-masked]

Scott,

As I said, I really like the idea of trying to classify
the types of contact that exist and we might even have
the right classification in front of us already, but I'm
not yet sure of that.

Perhaps we need to make a list of the different contact
scenarios we envisage and then show how each falls under
one of the classes and also that the classes are handled
differently by bundle routing software. Sounds like a lot
of work though (you guys almost certainly did some of
that already), but maybe something to chat about in LA.

Let me give an example of where I'm not sure whether the
current classes are right.

Assume that lots of sensor nodes can be edge routers and
that bundles are (somehow) flooded out to all edge routers
to await a contact with the outside world. Once bundles are
picked up (taken into custody by the peer router), the custody
ACKs need to be flooded back to release storage at the sensor
network's edge routers.

An edge router in that case might be aware that contacts will
occur between 9am and 10am (when the person carrying the peer
router goes by) but with a quite low probability (say just 1%
for a given sensor node/edge router) that a contact will occur
on any given day. I think (but am not sure really) that the
number of nodes involved, the success probability and the
duration and frequency of the time windows involved may be
important in how a sensor network's overall power usage is
handled and may well determine whether flooding within the
sensor network is the "right" approach to routing bundles.

Anyway - is that contact intermittent scheduled or intermittent
opportunistic?

I guess I could argue either way. (Though since you kind of
outlawed flooding in the draft, maybe my scenario is a bit of
a cheat?)

I guess what I'm stumbling towards is a classication based not
on named/defined classes, but rather on numbers related to the
independent variables that (primarily) determine how many bytes
are likely to be transferred per contact. (As you hinted when
you talked about on-demand in terms of probability.)

Stephen.

PS: As if to prove the point, I'm here late today due to a
classic bulldozer/cable intersection that cut off our
department for a couple of hours!

Scott Burleigh wrote:
> At 04:36 PM 4/21/2003 -0700, Warthman Associates wrote:
> 
>>>> Sec. 3.8.1 (p. 10): Type of Routes
>>>> ----------------------------------
>>>>
>>>> "On-Demand Contacts": What is the functional difference between 
>>>> "On-Demand Contacts" and "Intermittent - Opportunistic Contacts"?
>>>
>>>
>>> I think it's this:
>>>
>>>         Permanent contacts never start and never stop.
>>>
>>>         On-demand contacts start whenever you want them to and never 
>>> stop until you're done with them.
>>>
>>>         Intermittent scheduled contacts start when a predefined plan 
>>> says they will and stop when that plan says they stop.
>>>
>>>         Intermittent opportunistic contacts start at an unpredictable 
>>> time and stop at some subsequent unpredictable time.
>>
>>
>> I still don't see any difference between "On-Demand Contacts" and 
>> "Intermittent - Opportunistic Contacts". You have used different words 
>> for each, but the meanings can be viewed as identical: "start whenever 
>> you want" = "start at an unpredictable time", and "never stop until 
>> you're done with them" = "stop at some subsequent unpredictable time".
> 
> 
> No, I think the difference between these is clear and critical.  "start 
> whenever you want them to" means that YOU are in control of the 
> contact's beginning and ending times; the link capacity is a freely 
> available resource, like tap water, which you turn on and off as you 
> like.  "start at an unpredictable time" means that events beyond not 
> only your control but also your understanding will determine the 
> contact's beginning and ending times; the link capacity is a caprice of 
> the gods, like rainfall, which will happen whenever it feels like it.
> 
> In some apartment buildings, of course, the line between the two may 
> blur somewhat.
> 
>>>         Intermittent predicted contacts are like intermittent 
>>> opportunistic contacts except that the predictability of their start 
>>> and stop times is some value between zero (opportunistic) and 1 
>>> (scheduled).
>>
>>
>> Right. A related issue, however: the predictability of actually 
>> achieving contact for a scheduled contact will sometimes be less than 
>> 1, because the scheduled contact may not occur due to unknown 
>> circumstances.
> 
> 
> Very true, but that deviation from absolute predictability is something 
> you ignore in operations (although you certainly give it due attention 
> in crafting your fault protection and recovery procedures).
> 
>>>> "Intermittent - Opportunistic Contacts": What does "... present 
>>>> themselves ..." mean in the first sentence? Are 
>>>> pre-bundle-transmission beacons involved? If so, how and by whom?
>>>
>>>
>>> I would say yes, some sort of hailing protocol is needed, but it's 
>>> beyond the scope of Bundling.  The protocols at the convergence layer 
>>> (or sub-layer) are responsible for detecting the contact beginnings 
>>> and ends and telling the Bundling layer about them.
>>
>>
>> But isn't the convergence sublayer part of the bundle layer? If the 
>> convergence-sublayer architecture is not described in this 
>> bundle-layer architecture document, will there be a 
>> convergence-sublayer architecture document in the future?
> 
> 
> I misspoke.  The convergence layer is where the capabilities of 
> underlying transport (or reliable-link) protocols are mapped into the 
> requirements of the Bundling protocol; there is no actual protocol 
> there, so my expectation is that it doesn't get its own architecture 
> definition -- it's an element of the definition of the DTN architecture.
> 
>>>> Sec. 7 (p. 20): Convergence Layer
>>>> ---------------------------------
>>>>
>>>> I suggest calling this a "sublayer", not a "layer". Calling it a 
>>>> "layer" implies the same hierarchical level at other OSI layers, and 
>>>> it may imply that the Convergence Sublayer can exist by itself, 
>>>> without the Bundle Layer. The text seems to imply that the 
>>>> Convergence Layer exists only in the context of a Bundle Layer.
>>>
>>>
>>> Good point, but can we think of a better word than "sublayer"?
>>
>>
>> The term "sublayer" has precedence in, for example, the 
>> "Reconciliation Sublayer (RS)" of the Ethernet data-link layer, and 
>> the "Physical Coding Sublayer (PCS)" of the Ethernet physical layer.
> 
> 
> But now that I think of it as a protocol abstraction and adaptation 
> plane, I begin to wonder if we shouldn't stop referring to it as any 
> sort of layer at all.  In ISO stack context it's really more of a seam 
> than a layer.
> 
> Scott
> 
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> http://mailman.dtnrg.org/mailman/listinfo/dtn-interest
> 

Date: Tue, 22 Apr 2003 11:39:39 -0700
To: Scott Burleigh <[email-masked]>, [email-masked]
From: Warthman Associates <[email-masked]>
Subject: Re: [dtn-interest] Comments on draft-irtf-dtnrg-arch-00.txt
Sender: [email-masked]

Scott,

At 05:09 PM 4/21/2003, Scott Burleigh wrote:
>At 04:36 PM 4/21/2003 -0700, Warthman Associates wrote:
>>>>Sec. 3.8.1 (p. 10): Type of Routes
>>>>----------------------------------
>>>>
>>>>"On-Demand Contacts": What is the functional difference between 
>>>>"On-Demand Contacts" and "Intermittent - Opportunistic Contacts"?
>>>
>>>I think it's this:
>>>
>>>         Permanent contacts never start and never stop.
>>>
>>>         On-demand contacts start whenever you want them to and never 
>>> stop until you're done with them.
>>>
>>>         Intermittent scheduled contacts start when a predefined plan 
>>> says they will and stop when that plan says they stop.
>>>
>>>         Intermittent opportunistic contacts start at an unpredictable 
>>> time and stop at some subsequent unpredictable time.
>>
>>I still don't see any difference between "On-Demand Contacts" and 
>>"Intermittent - Opportunistic Contacts". You have used different words 
>>for each, but the meanings can be viewed as identical: "start whenever 
>>you want" = "start at an unpredictable time", and "never stop until 
>>you're done with them" = "stop at some subsequent unpredictable time".
>
>No, I think the difference between these is clear and critical.  "start 
>whenever you want them to" means that YOU are in control of the contact's 
>beginning and ending times; the link capacity is a freely available 
>resource, like tap water, which you turn on and off as you like.  "start 
>at an unpredictable time" means that events beyond not only your control 
>but also your understanding will determine the contact's beginning and 
>ending times; the link capacity is a caprice of the gods, like rainfall, 
>which will happen whenever it feels like it.

Right. I think these are good clarifications to add to the architecture 
document.

>>>>"Intermittent - Opportunistic Contacts": What does "... present 
>>>>themselves ..." mean in the first sentence? Are pre-bundle-transmission 
>>>>beacons involved? If so, how and by whom?
>>>
>>>I would say yes, some sort of hailing protocol is needed, but it's 
>>>beyond the scope of Bundling.  The protocols at the convergence layer 
>>>(or sub-layer) are responsible for detecting the contact beginnings and 
>>>ends and telling the Bundling layer about them.
>>
>>But isn't the convergence sublayer part of the bundle layer? If the 
>>convergence-sublayer architecture is not described in this bundle-layer 
>>architecture document, will there be a convergence-sublayer architecture 
>>document in the future?
>
>I misspoke.  The convergence layer is where the capabilities of underlying 
>transport (or reliable-link) protocols are mapped into the requirements of 
>the Bundling protocol; there is no actual protocol there, so my 
>expectation is that it doesn't get its own architecture definition -- it's 
>an element of the definition of the DTN architecture.

So then I assume the only topic relating to the Convergence Sublayer that 
needs architectural definition is that sublayer's standard interface to the 
bundling function, not its non-standard interface to a transport layer.

>>>>Sec. 7 (p. 20): Convergence Layer
>>>>---------------------------------
>>>>
>>>>I suggest calling this a "sublayer", not a "layer". Calling it a 
>>>>"layer" implies the same hierarchical level at other OSI layers, and it 
>>>>may imply that the Convergence Sublayer can exist by itself, without 
>>>>the Bundle Layer. The text seems to imply that the Convergence Layer 
>>>>exists only in the context of a Bundle Layer.
>>>
>>>Good point, but can we think of a better word than "sublayer"?
>>
>>The term "sublayer" has precedence in, for example, the "Reconciliation 
>>Sublayer (RS)" of the Ethernet data-link layer, and the "Physical Coding 
>>Sublayer (PCS)" of the Ethernet physical layer.
>
>But now that I think of it as a protocol abstraction and adaptation plane, 
>I begin to wonder if we shouldn't stop referring to it as any sort of 
>layer at all.  In ISO stack context it's really more of a seam than a layer.
>
>Scott

Again, consider the precedent of the sublayers in the Ethernet data-link 
layer. It's "Reconciliation Sublayer (RS)" enables its "Media Access 
Control (MAC)" sublayer to interface with existing physical-layer 
technologies. The reconciliation sublayer maps logical MAC 
physical-layer-service primitives to and from standard electrical 
interfaces used by the physical layers. As I understand it, this is the 
kind of function that the DTN Convergence Sublayer provides.

Forrest

Date: Tue, 22 Apr 2003 19:10:00 +0100
From: Stephen Farrell <[email-masked]>
To: Warthman Associates <[email-masked]>
Cc: [email-masked]
Subject: rfc2119 (was: Re: [dtn-interest] Comments on draft-irtf-dtnrg-arch-00.txt)
Sender: [email-masked]

Hi Forrest,

While I agree that SHOULD is not perfect, from a process
point of view the IRTF DTNRG is IMO not the place to address
any such shortcomings.

Nor do I think we need to get too exercised about the
general question. I'd say we're better off here arguing
about the specific uses of may/MAY/must/MUST/should/SHOULD
etc. which actually occur in our documents (though I
suppose I am assuming we all settle down happily, or
unhappily, with rfc2119 when I say that).

But, for any masochists out there, the IETF, which is the
proper "owner" of RFC2119, does have just the right venue[1],
but be warned - you really need to feel *very*, *very*
strongly about this to devote the cycles required to changing
that definition. (To get a feel for how many people you're
likely to meet along the way, just count how many references
there are to rfc2119, and not just in rfcs either!)

Best of luck if you try,
Stephen.

[1] http://www.ietf.org/html.charters/problem-charter.html
or maybe the POISED or POISSON lists are still active - I
don't know since I never subscribed to that kind of thing:-)

Warthman Associates wrote:
> Craig, Kevin, and all,
> 
> At 04:57 AM 4/22/2003, Craig Partridge wrote:
> 
>> RFC terminology was originally defined in RFC 1122 (host requirements).
>> I believe the same standard still applies, though there's likely some 
>> tweak
>> in some later document.  I attach the relevant excerpt.
>>
>> Craig
>>
>>      In this document, the words that are used to define the
>>      significance of each particular requirement are capitalized.
>>
>>      These words are:
>>
>>      *    "MUST"
>>
>>           This word or the adjective "REQUIRED" means that the item
>>           is an absolute requirement of the specification.
>>
>>      *    "SHOULD"
>>
>>           This word or the adjective "RECOMMENDED" means that there
>>           may exist valid reasons in particular circumstances to
>>           ignore this item, but the full implications should be
>>           understood and the case carefully weighed before choosing
>>           a different course.
>>
>>      *    "MAY"
>>
>>           This word or the adjective "OPTIONAL" means that this item
>>           is truly optional.  One vendor may choose to include the
>>           item because a particular marketplace requires it or
>>           because it enhances the product, for example; another
>>           vendor may omit the same item.
>>
>>
>>      An implementation is not compliant if it fails to satisfy one
>>      or more of the MUST requirements for the protocols it
>>      implements.  An implementation that satisfies all the MUST and
>>      all the SHOULD requirements for its protocols is said to be
>>      "unconditionally compliant"; one that satisfies all the MUST
>>      requirements but not all the SHOULD requirements for its
>>      protocols is said to be "conditionally compliant".
> 
> 
> 
> The last paragraph, above, explains the terms "unconditionally 
> compliant" and "conditionally compliant". However, both the above 
> excerpt and RFC 2119, to which Kevin refers, have the same ambiguity 
> problems with respect to "should", "should not", "must" and "may".
> 
> For example, both RFC 1122 and RFC 2119 says such things as:
> 
> '"SHOULD" ... mean[s] that there may exist valid reasons [to not 
> implement a feature] ... but the full implications must be understood 
> and carefully weighed before choosing a different [non-should] course'.
> 
> First, an external-observer (testability) problem: Saying that "there 
> may exist valid reasons" to not implement a feature has the same effect, 
> from the viewpoint of an external observer who is not privy to those 
> reasons or to your private thoughts and motives, as saying that you 
> *may* omit the feature. There is no test of actual or potential 
> architecture-implementations that can distinguish between whether the 
> RFC used the words "should", "should not", or "may" for a particular 
> feature, or whether the implementer actually considered the 
> implications, or misunderstood them, or simply lied. All an external 
> observer can determine is whether that feature was implemented or not.
> 
> Second, an epistemological (know-ability) problem: Neither the 
> implementer, nor anyone else, can ever know whether the implementer has 
> considered the *full* implications, because "full implications" is 
> undefined and unknowable. (This type of argument was used with respect 
> to the concept of God by Bertrand Russell in his "Why I Am An Agnostic".)
> 
> 
> I continue to maintain that the word "should" and "should not" are 
> ambiguous, and that  eventually they end up in practice as "may". 
> Instead of using "should" or "should not", I suggest we content 
> ourselves only with "must" or "may".
> 
> My personal view is that when we use the word "should" as a replacement 
> for "must", we do so because we don't like the in-your-face feeling of 
> the dogmatic and dictatorial word "must". But logic and programming are, 
> for the most part, dogmatic and dictatorial. As long as programmers 
> write predictably executable code rather than poetry, and hardware 
> developers design predictable circuits rather than art, we will have 
> this ambiguity problem with "should" and "should not".
> 
> I've copied Scott Bradner at Harvard on this discussion, because he is 
> the author of RFC 2119. Scott, I welcome your comments.
> 
> And, after I have another coffee and read the OED dictionary again, I'll 
> get together -- perhaps in Cleveland -- with Adrian, Leigh, and other 
> alleged truth-tellers to start working on DTNRG Resolution 1441.
> 
> Forrest
> 
> -----------------------------------------------------------------
> Forrest Warthman       Warthman Associates      Technical Writers
> 2417 Embarcadero Way   Palo Alto, CA 94303   [email-masked]
> (650)494-8555          (650)857-1815 fax         www.warthman.com
> 
> 
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> http://mailman.dtnrg.org/mailman/listinfo/dtn-interest
> 

Date: Tue, 22 Apr 2003 14:11:03 -0400
From: Ozgur Baris Akan <[email-masked]>
To: [email-masked]
CC: "Ian F. Akyildiz" <[email-masked]>, jfang <[email-masked]>
Subject: [dtn-interest] Our work on InterPlaNetary Internet: TCP-Planet
Sender: [email-masked]

This is a multi-part message in MIME format.
--------------020602010906050108010806
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Dear All,

We are glad to introduce our research results on transport protocols in 
the InterPlaNetary Internet.  Please find attached our paper:

Ian F. Akyildiz, Ozgur B. Akan, Jian Fang, "TCP-Planet: A Reliable 
Transport Protocol for InterPlaNetary Internet", December 2002 (revised 
March 2003).

Any feedback is greatly appreciated. Thank you very much in advance.

Sincerely,

Ozgur B. Akan
Research Assistant
Broadband & Wireless Networking Laboratory
School of Electrical & Computer Engineering
Georgia Institute of Technology, Atlanta GA
Tel: (404) 385 3011 Email: [email-masked]

--------------020602010906050108010806
Content-Type: application/pdf;
 name="TCP_Planet.pdf"
Content-Transfer-Encoding: base64
Content-Disposition: inline;
 filename="TCP_Planet.pdf"

--------------020602010906050108010806--

Date: Tue, 22 Apr 2003 10:33:50 -0700
To: Craig Partridge <[email-masked]>, Kevin Fall <[email-masked]>, [email-masked]
From: Warthman Associates <[email-masked]>
Subject: Re: [dtn-interest] Comments on draft-irtf-dtnrg-arch-00.txt 
Cc: "Adrian J. Hooke" <[email-masked]>, "J. Leigh Torgerson" <[email-masked]>, Scott Bradner <[email-masked]>, Scott Burleigh <[email-masked]>
Sender: [email-masked]

Craig, Kevin, and all,

At 04:57 AM 4/22/2003, Craig Partridge wrote:

>RFC terminology was originally defined in RFC 1122 (host requirements).
>I believe the same standard still applies, though there's likely some tweak
>in some later document.  I attach the relevant excerpt.
>
>Craig
>
>      In this document, the words that are used to define the
>      significance of each particular requirement are capitalized.
>
>      These words are:
>
>      *    "MUST"
>
>           This word or the adjective "REQUIRED" means that the item
>           is an absolute requirement of the specification.
>
>      *    "SHOULD"
>
>           This word or the adjective "RECOMMENDED" means that there
>           may exist valid reasons in particular circumstances to
>           ignore this item, but the full implications should be
>           understood and the case carefully weighed before choosing
>           a different course.
>
>      *    "MAY"
>
>           This word or the adjective "OPTIONAL" means that this item
>           is truly optional.  One vendor may choose to include the
>           item because a particular marketplace requires it or
>           because it enhances the product, for example; another
>           vendor may omit the same item.
>
>
>      An implementation is not compliant if it fails to satisfy one
>      or more of the MUST requirements for the protocols it
>      implements.  An implementation that satisfies all the MUST and
>      all the SHOULD requirements for its protocols is said to be
>      "unconditionally compliant"; one that satisfies all the MUST
>      requirements but not all the SHOULD requirements for its
>      protocols is said to be "conditionally compliant".

The last paragraph, above, explains the terms "unconditionally compliant" 
and "conditionally compliant". However, both the above excerpt and RFC 
2119, to which Kevin refers, have the same ambiguity problems with respect 
to "should", "should not", "must" and "may".

For example, both RFC 1122 and RFC 2119 says such things as:

'"SHOULD" ... mean[s] that there may exist valid reasons [to not implement 
a feature] ... but the full implications must be understood and carefully 
weighed before choosing a different [non-should] course'.

First, an external-observer (testability) problem: Saying that "there may 
exist valid reasons" to not implement a feature has the same effect, from 
the viewpoint of an external observer who is not privy to those reasons or 
to your private thoughts and motives, as saying that you *may* omit the 
feature. There is no test of actual or potential 
architecture-implementations that can distinguish between whether the RFC 
used the words "should", "should not", or "may" for a particular feature, 
or whether the implementer actually considered the implications, or 
misunderstood them, or simply lied. All an external observer can determine 
is whether that feature was implemented or not.

Second, an epistemological (know-ability) problem: Neither the implementer, 
nor anyone else, can ever know whether the implementer has considered the 
*full* implications, because "full implications" is undefined and 
unknowable. (This type of argument was used with respect to the concept of 
God by Bertrand Russell in his "Why I Am An Agnostic".)

I continue to maintain that the word "should" and "should not" are 
ambiguous, and that  eventually they end up in practice as "may". Instead 
of using "should" or "should not", I suggest we content ourselves only with 
"must" or "may".

My personal view is that when we use the word "should" as a replacement for 
"must", we do so because we don't like the in-your-face feeling of the 
dogmatic and dictatorial word "must". But logic and programming are, for 
the most part, dogmatic and dictatorial. As long as programmers write 
predictably executable code rather than poetry, and hardware developers 
design predictable circuits rather than art, we will have this ambiguity 
problem with "should" and "should not".

I've copied Scott Bradner at Harvard on this discussion, because he is the 
author of RFC 2119. Scott, I welcome your comments.

And, after I have another coffee and read the OED dictionary again, I'll 
get together -- perhaps in Cleveland -- with Adrian, Leigh, and other 
alleged truth-tellers to start working on DTNRG Resolution 1441.

Forrest

-----------------------------------------------------------------
Forrest Warthman       Warthman Associates      Technical Writers
2417 Embarcadero Way   Palo Alto, CA 94303   [email-masked]
(650)494-8555          (650)857-1815 fax         www.warthman.com

To: [email-masked]
Subject: Re: [dtn-interest] Comments on draft-irtf-dtnrg-arch-00.txt 
Date: Tue, 22 Apr 2003 07:57:37 -0400
From: Craig Partridge <[email-masked]>
Sender: [email-masked]

RFC terminology was originally defined in RFC 1122 (host requirements).
I believe the same standard still applies, though there's likely some tweak
in some later document.  I attach the relevant excerpt.

Craig

     In this document, the words that are used to define the
     significance of each particular requirement are capitalized.

     These words are:

     *    "MUST"

	  This word or the adjective "REQUIRED" means that the item
	  is an absolute requirement of the specification.

     *    "SHOULD"

	  This word or the adjective "RECOMMENDED" means that there
	  may exist valid reasons in particular circumstances to
	  ignore this item, but the full implications should be
	  understood and the case carefully weighed before choosing
	  a different course.

     *    "MAY"

	  This word or the adjective "OPTIONAL" means that this item
	  is truly optional.  One vendor may choose to include the
	  item because a particular marketplace requires it or
	  because it enhances the product, for example; another
	  vendor may omit the same item.

     An implementation is not compliant if it fails to satisfy one
     or more of the MUST requirements for the protocols it
     implements.  An implementation that satisfies all the MUST and
     all the SHOULD requirements for its protocols is said to be
     "unconditionally compliant"; one that satisfies all the MUST
     requirements but not all the SHOULD requirements for its
     protocols is said to be "conditionally compliant".

Date: Mon, 21 Apr 2003 20:39:06 -0700 (PDT)
From: Bob Braden <[email-masked]>
To: [email-masked], [email-masked]
Subject: Re: [dtn-interest] Comments on draft-irtf-dtnrg-arch-00.txt
Cc: [email-masked], [email-masked]
Sender: [email-masked]

  *> 
  *> There has been a somewhat formalized notion of "should" in RFCs.
  *> That is, if you fail to implement a "should" thing you are not
  *> in "strict compliance" (by definition I believe).
  *> 

If you fail to implement a 'SHOULD' without very strong cause, you are
out of compliance.  (Otherwise, there would be no distinction between
'SHOULD' and 'MUST'.)  When used with these precise meanings,
the words are capitalized.  If you lower-case them, they have
only their standard meanings in the English language.

Bob Braden

  *> - K
  *> _______________________________________________
  *> dtn-interest mailing list
  *> [email-masked]
  *> http://mailman.dtnrg.org/mailman/listinfo/dtn-interest
  *> 

Date: Mon, 21 Apr 2003 20:36:15 -0400 (EDT)
From: "Armando L. Caro Jr." <[email-masked]>
Reply-To: "Armando L. Caro Jr." <[email-masked]>
To: Warthman Associates <[email-masked]>
Cc: Kevin Fall <[email-masked]>, Scott Burleigh <[email-masked]>, <[email-masked]>
Subject: Re: [dtn-interest] Comments on draft-irtf-dtnrg-arch-00.txt 
Sender: [email-masked]

On Mon, 21 Apr 2003, Warthman Associates wrote:

> At 04:58 PM 4/21/2003, Kevin Fall wrote:
>
> >There has been a somewhat formalized notion of "should" in RFCs.
> >That is, if you fail to implement a "should" thing you are not
> >in "strict compliance" (by definition I believe).
>
> Thanks for this note. I suppose the remaining question is: If I am not in
> "strict compliance", then what kind of compliance am I in? Has "non-strict
> compliance" been defined precisely?

My understanding has always been that a MUST is just that... a must.
SHOULD is used when there may be valid reasons for not doing something.
Without such a valid reason, the item is expected to be done. RFC2119 has
more info.

~armando

0--                                                  --0
| Armando L. Caro Jr.      |  Protocol Engineering Lab |
| www.cis.udel.edu/~acaro  |    University of Delaware |
0--                                                  --0

To: Warthman Associates <[email-masked]>
cc: Scott Burleigh <[email-masked]>, [email-masked]
Subject: Re: [dtn-interest] Comments on draft-irtf-dtnrg-arch-00.txt 
Date: Mon, 21 Apr 2003 17:21:56 -0700
From: Kevin Fall <[email-masked]>
Sender: [email-masked]

>
> From:  Warthman Associates <[email-masked]>
> To:    Kevin Fall <[email-masked]>
> cc:    Scott Burleigh <[email-masked]>,
	 [email-masked]
> Subject: Re: [dtn-interest] Comments on draft-irtf-dtnrg-arch-00.txt 
> Date:  Mon, 21 Apr 2003 17:03:08 PDT
>
> Kevin,
> 
> At 04:58 PM 4/21/2003, Kevin Fall wrote:
> 
> >There has been a somewhat formalized notion of "should" in RFCs.
> >That is, if you fail to implement a "should" thing you are not
> >in "strict compliance" (by definition I believe).
> 
> Thanks for this note. I suppose the remaining question is: If I am not in 
> "strict compliance", then what kind of compliance am I in? Has "non-strict 
> compliance" been defined precisely?
> 
> Forrest
> 
> 
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> http://mailman.dtnrg.org/mailman/listinfo/dtn-interest

yes, non-strict compliance means you implement all the "must" things,
and you don't do any of the things that say "must not".

See RFC 2119 for more detail on must/should/etc.   http://www.faqs.org/rfcs/rfc2119.html
I'm not sure where 'strict compliance' is actually defined, tho.

- K

Date: Mon, 21 Apr 2003 17:09:51 -0700
To: [email-masked]
From: Scott Burleigh <[email-masked]>
Subject: Re: [dtn-interest] Comments on draft-irtf-dtnrg-arch-00.txt
Sender: [email-masked]

At 04:36 PM 4/21/2003 -0700, Warthman Associates wrote:
>>>Sec. 3.8.1 (p. 10): Type of Routes
>>>----------------------------------
>>>
>>>"On-Demand Contacts": What is the functional difference between 
>>>"On-Demand Contacts" and "Intermittent - Opportunistic Contacts"?
>>
>>I think it's this:
>>
>>         Permanent contacts never start and never stop.
>>
>>         On-demand contacts start whenever you want them to and never 
>> stop until you're done with them.
>>
>>         Intermittent scheduled contacts start when a predefined plan 
>> says they will and stop when that plan says they stop.
>>
>>         Intermittent opportunistic contacts start at an unpredictable 
>> time and stop at some subsequent unpredictable time.
>
>I still don't see any difference between "On-Demand Contacts" and 
>"Intermittent - Opportunistic Contacts". You have used different words for 
>each, but the meanings can be viewed as identical: "start whenever you 
>want" = "start at an unpredictable time", and "never stop until you're 
>done with them" = "stop at some subsequent unpredictable time".

No, I think the difference between these is clear and critical.  "start 
whenever you want them to" means that YOU are in control of the contact's 
beginning and ending times; the link capacity is a freely available 
resource, like tap water, which you turn on and off as you like.  "start at 
an unpredictable time" means that events beyond not only your control but 
also your understanding will determine the contact's beginning and ending 
times; the link capacity is a caprice of the gods, like rainfall, which 
will happen whenever it feels like it.

In some apartment buildings, of course, the line between the two may blur 
somewhat.

>>         Intermittent predicted contacts are like intermittent 
>> opportunistic contacts except that the predictability of their start and 
>> stop times is some value between zero (opportunistic) and 1 (scheduled).
>
>Right. A related issue, however: the predictability of actually achieving 
>contact for a scheduled contact will sometimes be less than 1, because the 
>scheduled contact may not occur due to unknown circumstances.

Very true, but that deviation from absolute predictability is something you 
ignore in operations (although you certainly give it due attention in 
crafting your fault protection and recovery procedures).

>>>"Intermittent - Opportunistic Contacts": What does "... present 
>>>themselves ..." mean in the first sentence? Are pre-bundle-transmission 
>>>beacons involved? If so, how and by whom?
>>
>>I would say yes, some sort of hailing protocol is needed, but it's beyond 
>>the scope of Bundling.  The protocols at the convergence layer (or 
>>sub-layer) are responsible for detecting the contact beginnings and ends 
>>and telling the Bundling layer about them.
>
>But isn't the convergence sublayer part of the bundle layer? If the 
>convergence-sublayer architecture is not described in this bundle-layer 
>architecture document, will there be a convergence-sublayer architecture 
>document in the future?

I misspoke.  The convergence layer is where the capabilities of underlying 
transport (or reliable-link) protocols are mapped into the requirements of 
the Bundling protocol; there is no actual protocol there, so my expectation 
is that it doesn't get its own architecture definition -- it's an element 
of the definition of the DTN architecture.

>>>Sec. 7 (p. 20): Convergence Layer
>>>---------------------------------
>>>
>>>I suggest calling this a "sublayer", not a "layer". Calling it a "layer" 
>>>implies the same hierarchical level at other OSI layers, and it may 
>>>imply that the Convergence Sublayer can exist by itself, without the 
>>>Bundle Layer. The text seems to imply that the Convergence Layer exists 
>>>only in the context of a Bundle Layer.
>>
>>Good point, but can we think of a better word than "sublayer"?
>
>The term "sublayer" has precedence in, for example, the "Reconciliation 
>Sublayer (RS)" of the Ethernet data-link layer, and the "Physical Coding 
>Sublayer (PCS)" of the Ethernet physical layer.

But now that I think of it as a protocol abstraction and adaptation plane, 
I begin to wonder if we shouldn't stop referring to it as any sort of layer 
at all.  In ISO stack context it's really more of a seam than a layer.

Scott

Date: Mon, 21 Apr 2003 17:03:08 -0700
To: Kevin Fall <[email-masked]>
From: Warthman Associates <[email-masked]>
Subject: Re: [dtn-interest] Comments on draft-irtf-dtnrg-arch-00.txt 
Cc: Scott Burleigh <[email-masked]>, [email-masked]
Sender: [email-masked]

Kevin,

At 04:58 PM 4/21/2003, Kevin Fall wrote:

>There has been a somewhat formalized notion of "should" in RFCs.
>That is, if you fail to implement a "should" thing you are not
>in "strict compliance" (by definition I believe).

Thanks for this note. I suppose the remaining question is: If I am not in 
"strict compliance", then what kind of compliance am I in? Has "non-strict 
compliance" been defined precisely?

Forrest

Date: Mon, 21 Apr 2003 16:58:18 -0700
To: Scott Burleigh <[email-masked]>, [email-masked]
From: Warthman Associates <[email-masked]>
Subject: Re: [dtn-interest] Comments on draft-irtf-dtnrg-arch-00.txt
Sender: [email-masked]

Scott,

At 04:11 PM 4/21/2003, Scott Burleigh wrote:
>At 06:47 PM 4/21/2003 -0400, vinton g. cerf wrote:
>>scott,
>>
>>the rfc editor(s) learned that precision for protocol specs is vital - 
>>isn't there an RFC guide
>>for Shall, May and Should (if the latter is permitted at all)?
>
>There may very well be, and I would certainly agree that precision in a 
>protocol spec is indispensable.
>
>I think I've seen clauses in specs (maybe not RFCs) labeled "Recommended" 
>or possibly described using the word "should" as a hint to the 
>implementer, with the clear implication that such clauses are not part of 
>the formal protocol and have no bearing on interoperability.  In my 
>experience that hasn't been harmful.
>
>In any case, it seems to me that the rules may be a little different in an 
>architecture description.  Architecture isn't anything anyone will be 
>coding to anyway; the purpose of the architecture document is to convey 
>some key concepts to the reader, and language that is neither commentary 
>nor mandate -- just advice -- doesn't seem too out of place.

I make most of my living writing architecture documents for commercial 
microprocessors. I and most of the really good microprocessor architects 
with whom I have worked assume that the architecture document must be the 
most precise of any document relating to a product. After all, it is the 
blueprint for implementations, and implementations often need to be 
compatible. Among commercial microprocessors, the architecture document 
(the instruction-set architecture) *is* the prime source of information on 
how instructions work and how to use them in coding.

You mention using the word "should" as a hint to the implementer, with the 
clear implication that such clauses are not part of the formal protocol: 
When my company wrote IBM's PowerPC Compiler Writer's Guide, I had 
discussions with the PowerPC architects at IBM about their use of "should" 
in their architecture document. They never understood the problem, which 
was that the several compiler-writer companies we were working with as 
reviewers did not know the consequences of ignoring the "shoulds"; they 
were concerned that if they wrote a compiler without implementing the 
"shoulds", their compiler might produce code incompatible with code 
produced by another company's compiler.

In general, I try to write English the way a good programmer writes code. 
If the writing is not precise, it won't execute correctly in the brains of 
readers. Imagine, for example, what a program would do with undefined 
aliases, one of the most common problems in engineering documentation.

Forrest 

To: Warthman Associates <[email-masked]>
cc: Scott Burleigh <[email-masked]>, [email-masked]
Subject: Re: [dtn-interest] Comments on draft-irtf-dtnrg-arch-00.txt 
Date: Mon, 21 Apr 2003 16:58:10 -0700
From: Kevin Fall <[email-masked]>
Sender: [email-masked]

There has been a somewhat formalized notion of "should" in RFCs.
That is, if you fail to implement a "should" thing you are not
in "strict compliance" (by definition I believe).

- K

Date: Mon, 21 Apr 2003 16:36:52 -0700
To: Scott Burleigh <[email-masked]>, [email-masked], "Fall, Kevin R" <[email-masked]>
From: Warthman Associates <[email-masked]>
Subject: Re: [dtn-interest] Comments on draft-irtf-dtnrg-arch-00.txt
Sender: [email-masked]

Scott,

At 02:46 PM 4/21/2003, Scott Burleigh wrote:
>At 04:14 PM 4/19/2003 -0700, Warthman Associates wrote:
>>"should"
>>--------
>>
>>The word "should" is ambiguous in this and most documents. "Should" is 
>>the past tense of the auxiliary verb "shall". In most English 
>>dictionaries, the primary meaning of "should" expresses duty or 
>>obligation - much closer to "must" than to "may". Lawyers use "shall" to 
>>mean "must", as in "you shall do this" and "you shall not do that".
>>
>>In place of "should", I suggest using "must" or "may", which are unambiguous.
>
>Loath as I am to quarrel with anybody who cares enough about English usage 
>to raise this sort of issue (and, better yet, tell me something I didn't 
>know), I will briefly object.  My Webster's Ninth New Collegiate gives the 
>following as the second definition of "should": "used in auxiliary 
>function to express obligation, propriety, or expediency".  As an example 
>of expediency it offers "you should brush your teeth after each 
>meal".  [Actually, the first definition listed is as an expression of 
>condition rather than duty, as in "should you ever need us, just send up a 
>flare".]
>
>In that sense it serves a valuable function in the language, occupying the 
>ground between "must" and "may" as an alternative to the generally awkward 
>"ought to" -- that is, going beyond permission to advocacy but stopping 
>well short of mandate -- and is well understood in colloquial 
>discourse.  I should hate to lose it.

I always welcome objections; they make me think more. As I see it, however, 
the problem with "should" is that the reader does not *know* whether the 
writer intends "must" or "may" as the meaning, or (in an alternative 
meaning of "should" that many dictionaries describe) the *condition* that 
must be met or will ensue (as in "If the receiving node should omit the 
acknowledgement, the sending node would explode").

Yes, the word serves a middle ground, but the middle ground is usually 
undefined, except in cases (such as my parenthetical, above) in which a 
condition is explicitly stated. How might we give a rational explanation 
(in the context of computer architecture) of what "ought to" means? Does it 
mean that I don't need to implement a feature, but that I should feel 
guilty if I do not, or that some specified consequence will follow? In the 
absence of a stated consequence for not doing the "ought to", I can't know 
what it means.

>>Sec. 3.6 (p. 9 and elsewhere): "Tuple"
>>--------------------------------------
>>
>>The term "tuple" is generic, meaning "n-tuple" and implying, to readers 
>>outside the immediate circle of DTN architects, that the n-tuple may have 
>>any number of elements. To avoid misunderstandings, I suggest using 
>>"2-tuple". Alternatively, a simpler designation would be "node name".
>
>I completely agree.  We've got a sentimental attachment to "tuple", but I 
>think it's time to start moving to a different term.
>
>>Sec. 3.8.1 (p. 10): Type of Routes
>>----------------------------------
>>
>>"On-Demand Contacts": What is the functional difference between 
>>"On-Demand Contacts" and "Intermittent - Opportunistic Contacts"?
>
>I think it's this:
>
>         Permanent contacts never start and never stop.
>
>         On-demand contacts start whenever you want them to and never stop 
> until you're done with them.
>
>         Intermittent scheduled contacts start when a predefined plan says 
> they will and stop when that plan says they stop.
>
>         Intermittent opportunistic contacts start at an unpredictable 
> time and stop at some subsequent unpredictable time.

I still don't see any difference between "On-Demand Contacts" and 
"Intermittent - Opportunistic Contacts". You have used different words for 
each, but the meanings can be viewed as identical: "start whenever you 
want" = "start at an unpredictable time", and "never stop until you're done 
with them" = "stop at some subsequent unpredictable time".

>         Intermittent predicted contacts are like intermittent 
> opportunistic contacts except that the predictability of their start and 
> stop times is some value between zero (opportunistic) and 1 (scheduled).

Right. A related issue, however: the predictability of actually achieving 
contact for a scheduled contact will sometimes be less than 1, because the 
scheduled contact may not occur due to unknown circumstances.

>>"Intermittent - Scheduled Contacts": Must the contact be confirmed to 
>>exist before bundle-transmission begins? If so, by what mechanism?
>
>I would say no.  The whole point of scheduled contacts is to believe in 
>them.  Over a 40-minute round-trip time you clearly don't want to wait for 
>confirmation before using a scheduled contact.

I agree.

>>"Intermittent - Opportunistic Contacts": What does "... present 
>>themselves ..." mean in the first sentence? Are pre-bundle-transmission 
>>beacons involved? If so, how and by whom?
>
>I would say yes, some sort of hailing protocol is needed, but it's beyond 
>the scope of Bundling.  The protocols at the convergence layer (or 
>sub-layer) are responsible for detecting the contact beginnings and ends 
>and telling the Bundling layer about them.

But isn't the convergence sublayer part of the bundle layer? If the 
convergence-sublayer architecture is not described in this bundle-layer 
architecture document, will there be a convergence-sublayer architecture 
document in the future?

>>Sec. 7 (p. 20): Convergence Layer
>>---------------------------------
>>
>>I suggest calling this a "sublayer", not a "layer". Calling it a "layer" 
>>implies the same hierarchical level at other OSI layers, and it may imply 
>>that the Convergence Sublayer can exist by itself, without the Bundle 
>>Layer. The text seems to imply that the Convergence Layer exists only in 
>>the context of a Bundle Layer.
>
>Good point, but can we think of a better word than "sublayer"?

The term "sublayer" has precedence in, for example, the "Reconciliation 
Sublayer (RS)" of the Ethernet data-link layer, and the "Physical Coding 
Sublayer (PCS)" of the Ethernet physical layer.

Another topic I forgot to mention: I don't know whether you, Kevin, and 
others saw the multiple commentaries on March 16 regarding 2-tuple naming, 
but I thought Vint's usage of "correspondent ID" as the generic term 
covering *either* a source or destination node was the best idea yet for a 
replacement to "entity ID". This usage would have the 2-tuple node name 
consisting of "region ID" and "correspondent ID". The benefit of 
"correspondent ID" over "entity ID" is that the former carries specific 
meaning about the kind of entity we mean to reference.

By the way, it looks like you and Keith did a great job on your Bundle 
Protocol Specification. I had only a short time to browse it, but it looks 
excellent and I hope to read more.

Forrest

Date: Mon, 21 Apr 2003 16:11:58 -0700
To: [email-masked]
From: Scott Burleigh <[email-masked]>
Subject: Re: [dtn-interest] Comments on draft-irtf-dtnrg-arch-00.txt
Sender: [email-masked]

At 06:47 PM 4/21/2003 -0400, vinton g. cerf wrote:
>scott,
>
>the rfc editor(s) learned that precision for protocol specs is vital - 
>isn't there an RFC guide
>for Shall, May and Should (if the latter is permitted at all)?

There may very well be, and I would certainly agree that precision in a 
protocol spec is indispensable.

I think I've seen clauses in specs (maybe not RFCs) labeled "Recommended" 
or possibly described using the word "should" as a hint to the implementer, 
with the clear implication that such clauses are not part of the formal 
protocol and have no bearing on interoperability.  In my experience that 
hasn't been harmful.

In any case, it seems to me that the rules may be a little different in an 
architecture description.  Architecture isn't anything anyone will be 
coding to anyway; the purpose of the architecture document is to convey 
some key concepts to the reader, and language that is neither commentary 
nor mandate -- just advice -- doesn't seem too out of place.

Scott

>At 02:46 PM 4/21/2003 -0700, Scott Burleigh wrote:
> >Loath as I am to quarrel with anybody who cares enough about English 
> usage to raise this sort of issue (and, better yet, tell me something I 
> didn't know), I will briefly object.  My Webster's Ninth New Collegiate 
> gives the following as the second definition of "should": "used in 
> auxiliary function to express obligation, propriety, or expediency".  As 
> an example of expediency it offers "you should brush your teeth after 
> each meal".  [Actually, the first definition listed is as an expression 
> of condition rather than duty, as in "should you ever need us, just send 
> up a flare".]
> >
> >In that sense it serves a valuable function in the language, occupying 
> the ground between "must" and "may" as an alternative to the generally 
> awkward "ought to" -- that is, going beyond permission to advocacy but 
> stopping well short of mandate -- and is well understood in colloquial 
> discourse.  I should hate to lose it.

Date: Mon, 21 Apr 2003 18:47:06 -0400
From: "vinton g. cerf" <[email-masked]>
Subject: Re: [dtn-interest] Comments on draft-irtf-dtnrg-arch-00.txt
To: Scott Burleigh <[email-masked]>, [email-masked]
Sender: [email-masked]

scott,

the rfc editor(s) learned that precision for protocol specs is vital - isn't there an RFC guide
for Shall, May and Should (if the latter is permitted at all)?

vint

At 02:46 PM 4/21/2003 -0700, Scott Burleigh wrote:
>Loath as I am to quarrel with anybody who cares enough about English usage to raise this sort of issue (and, better yet, tell me something I didn't know), I will briefly object.  My Webster's Ninth New Collegiate gives the following as the second definition of "should": "used in auxiliary function to express obligation, propriety, or expediency".  As an example of expediency it offers "you should brush your teeth after each meal".  [Actually, the first definition listed is as an expression of condition rather than duty, as in "should you ever need us, just send up a flare".]
>
>In that sense it serves a valuable function in the language, occupying the ground between "must" and "may" as an alternative to the generally awkward "ought to" -- that is, going beyond permission to advocacy but stopping well short of mandate -- and is well understood in colloquial discourse.  I should hate to lose it.

Vint Cerf
SVP Architecture & Technology
MCI
22001 Loudoun County Parkway, F2-4115
Ashburn, VA 20147
703 886 1690 (v806 1690)
703 886 0047 fax
[email-masked]
www.mci.com/cerfsup 

Date: Mon, 21 Apr 2003 14:46:30 -0700
To: [email-masked]
From: Scott Burleigh <[email-masked]>
Subject: Re: [dtn-interest] Comments on draft-irtf-dtnrg-arch-00.txt
Sender: [email-masked]

At 04:14 PM 4/19/2003 -0700, Warthman Associates wrote:
>"should"
>--------
>
>The word "should" is ambiguous in this and most documents. "Should" is the 
>past tense of the auxiliary verb "shall". In most English dictionaries, 
>the primary meaning of "should" expresses duty or obligation - much closer 
>to "must" than to "may". Lawyers use "shall" to mean "must", as in "you 
>shall do this" and "you shall not do that".
>
>In place of "should", I suggest using "must" or "may", which are unambiguous.

Loath as I am to quarrel with anybody who cares enough about English usage 
to raise this sort of issue (and, better yet, tell me something I didn't 
know), I will briefly object.  My Webster's Ninth New Collegiate gives the 
following as the second definition of "should": "used in auxiliary function 
to express obligation, propriety, or expediency".  As an example of 
expediency it offers "you should brush your teeth after each 
meal".  [Actually, the first definition listed is as an expression of 
condition rather than duty, as in "should you ever need us, just send up a 
flare".]

In that sense it serves a valuable function in the language, occupying the 
ground between "must" and "may" as an alternative to the generally awkward 
"ought to" -- that is, going beyond permission to advocacy but stopping 
well short of mandate -- and is well understood in colloquial discourse.  I 
should hate to lose it.

>Sec. 3.6 (p. 9 and elsewhere): "Tuple"
>--------------------------------------
>
>The term "tuple" is generic, meaning "n-tuple" and implying, to readers 
>outside the immediate circle of DTN architects, that the n-tuple may have 
>any number of elements. To avoid misunderstandings, I suggest using 
>"2-tuple". Alternatively, a simpler designation would be "node name".

I completely agree.  We've got a sentimental attachment to "tuple", but I 
think it's time to start moving to a different term.

>Sec. 3.8.1 (p. 10): Type of Routes
>----------------------------------
>
>"On-Demand Contacts": What is the functional difference between "On-Demand 
>Contacts" and "Intermittent - Opportunistic Contacts"?

I think it's this:

         Permanent contacts never start and never stop.

         On-demand contacts start whenever you want them to and never stop 
until you're done with them.

         Intermittent scheduled contacts start when a predefined plan says 
they will and stop when that plan says they stop.

         Intermittent opportunistic contacts start at an unpredictable time 
and stop at some subsequent unpredictable time.

         Intermittent predicted contacts are like intermittent 
opportunistic contacts except that the predictability of their start and 
stop times is some value between zero (opportunistic) and 1 (scheduled).

>"Intermittent - Scheduled Contacts": Must the contact be confirmed to 
>exist before bundle-transmission begins? If so, by what mechanism?

I would say no.  The whole point of scheduled contacts is to believe in 
them.  Over a 40-minute round-trip time you clearly don't want to wait for 
confirmation before using a scheduled contact.

>"Intermittent - Opportunistic Contacts": What does "... present themselves 
>..." mean in the first sentence? Are pre-bundle-transmission beacons 
>involved? If so, how and by whom?

I would say yes, some sort of hailing protocol is needed, but it's beyond 
the scope of Bundling.  The protocols at the convergence layer (or 
sub-layer) are responsible for detecting the contact beginnings and ends 
and telling the Bundling layer about them.

>Sec. 7 (p. 20): Convergence Layer
>---------------------------------
>
>I suggest calling this a "sublayer", not a "layer". Calling it a "layer" 
>implies the same hierarchical level at other OSI layers, and it may imply 
>that the Convergence Sublayer can exist by itself, without the Bundle 
>Layer. The text seems to imply that the Convergence Layer exists only in 
>the context of a Bundle Layer.

Good point, but can we think of a better word than "sublayer"?

Scott

Date: Sat, 19 Apr 2003 16:14:41 -0700
To: Kevin Fall <[email-masked]>, [email-masked]
From: Warthman Associates <[email-masked]>
Subject: [dtn-interest] Comments on draft-irtf-dtnrg-arch-00.txt
Sender: [email-masked]

Kevin and all,

My apologies for being late with these comments on 
draft-irtf-dtnrg-arch-00. I hope they will still be useful. I felt Draft 2 
(now Draft 0) of the architecture document was a great improvement over 
Draft 1. Most of my comments focus on the need for greater precision in the 
use of language. Stephen Farrell's excellent comments also touch on some of 
these issues.

"class of service" and "delivery options"
-----------------------------------------
The "class of service" and "delivery options" phrases (and CoS acronym) are 
used ambiguously and inconsistently. A few examples:

Sec. 2 (p. 5): "...class of service and delivery options..."
Sec. 3.2 (p. 6): "...three...classes of service [bulk, normal, expedited]"
Sec. 5 (p. 18): "...class of service flags: [Flags, CoS Selector, Security]"

I don't understand the reason for a distinction between "class of service" 
and "delivery options". All of the options can be regarded as *both* "class 
of service" and "delivery options". There is no intuitive distinction in 
common English useage between the two sets.

I think Keith Scott and Scott Burleigh have handled it best on p. 17 of 
their Bundle Protocol Specification: they treat all of these options, 
except authentication, as "class of service" options.

Sec. 3.3 (p. 7) "Return Receipt"
--------------------------------

This section says "...a return-receipt bundle is issued ... when the 
(arriving) subject bundle is consumed *by the destination application* (not 
simply the destination bundle layer)".

What does "consumed" mean? Does it mean the point at which the bundle layer 
passes the bundle to the destination application, irrespective of whether 
the destination application receives it in any useful way?

"should"
--------

The word "should" is ambiguous in this and most documents. "Should" is the 
past tense of the auxiliary verb "shall". In most English dictionaries, the 
primary meaning of "should" expresses duty or obligation - much closer to 
"must" than to "may". Lawyers use "shall" to mean "must", as in "you shall 
do this" and "you shall not do that".

In place of "should", I suggest using "must" or "may", which are unambiguous.

Sec. 3.4 (p. 7): "DTN Node"
--------------------------

"A DTN node ... is an engine for sending and receiving DTN messages 
(bundles)". I suggest adding that a "DTN node" implements a "bundle layer".

Also, what happened to the statement, in Sec. 3.8 of Draft 1, that "while 
not every node in a DTN must be capable of providing custodial services, 
all DTN gateways are expected to be able to be custodians"? Is this still 
true? I say in the DTN Tutorial, the custody-transfer service is optional 
for routers but required for gateways.

Sec. 3.6 (p. 9 and elsewhere): "Tuple"
--------------------------------------

The term "tuple" is generic, meaning "n-tuple" and implying, to readers 
outside the immediate circle of DTN architects, that the n-tuple may have 
any number of elements. To avoid misunderstandings, I suggest using 
"2-tuple". Alternatively, a simpler designation would be "node name".

Sec. 3.8.1 (p. 10): Type of Routes
----------------------------------

"On-Demand Contacts": What is the functional difference between "On-Demand 
Contacts" and "Intermittent - Opportunistic Contacts"?

"Intermittent - Scheduled Contacts": Must the contact be confirmed to exist 
before bundle-transmission begins? If so, by what mechanism?

"Intermittent - Opportunistic Contacts": What does "... present themselves 
..." mean in the first sentence? Are pre-bundle-transmission beacons 
involved? If so, how and by whom? Also, see my first question regarding 
relation to "On-Demand Contacts".

"Intermittent - Predicted Contacts": Same question as above for 
"Intermittent - Scheduled Contacts".

Sec. 3.10 (p. 13): Custody-Transfer Support
-------------------------------------------

"While not every node in a DTN must be capable of providing custodial 
services, all DTN routers ... are expected to be able to be custodians". 
See my comment above on Sec. 3.4. This statement is an alteration of the 
Draft 1 statement that says all *gateways* (but not necessarily all 
*routers*) must provide the custodian function.

Which is it: (1) routers optional, gateways required, or (2) routers *and* 
gateways required?

Sec. 3.13 (p. 15): Security Model
---------------------------------

Second paragraph: In addition to agreeing with Stephen Farrell's Hrmpf! 
("Where's the security model?), I disagree with the reference to a "postage 
stamp" concept. The concept of a postage stamp has a well-defined history: 
it implies only an agreement by an authority to a class of service, up to a 
maximum weight (comparable to max. bandwidth in a DTN), but it does not 
imply any verification of the sender's identity or of the integrity of the 
message.

Third paragraph: "Routers and principals ...". This is the first time the 
word "principals" has appeared, and it is undefined. I assume you mean 
"sources or destinations". Since this is the only paragraph in the document 
to use the undefined term, I suggest that it be avoided in favor of 
"sources or destinations", to avoid the overhead and digression of defining 
the term.

Sec. 7 (p. 20): Convergence Layer
---------------------------------

I suggest calling this a "sublayer", not a "layer". Calling it a "layer" 
implies the same hierarchical level at other OSI layers, and it may imply 
that the Convergence Sublayer can exist by itself, without the Bundle 
Layer. The text seems to imply that the Convergence Layer exists only in 
the context of a Bundle Layer.

Nits
----

Although I thought Stephen Farrell's comments were great, I don't agree 
with his nits about replacing *may* with MAY, etc.

References (p. 20): My company name is spelled wrong. It is Warthman 
Associates, not Wartham Associates.

Otherwise, thanks for a great job and a big bunch of work.

Forrest

-----------------------------------------------------------------
Forrest Warthman       Warthman Associates      Technical Writers
2417 Embarcadero Way   Palo Alto, CA 94303   [email-masked]
(650)494-8555          (650)857-1815 fax         www.warthman.com  

To: [email-masked]
Date: Thu, 17 Apr 2003 18:23:07 -0700
From: Kevin Fall <[email-masked]>
Subject: [dtn-interest] web page updated
Sender: [email-masked]

I just updated the web page with links to various projects I have
become aware of that have dtn-related problems.

If you have a project you would like to have linked to, please
let me know.

- K

To: [email-masked]
Date: Thu, 17 Apr 2003 14:34:55 -0700
From: Kevin Fall <[email-masked]>
Subject: [dtn-interest] fyi
Sender: [email-masked]

This might be of interest in case you haven't seen it.

- K

------- Forwarded Message

>
> From:  Hari Balakrishnan <[email-masked]>
> To:    [email-masked]
> Subject: [e2e] HotNets-II CFP
> Date:  Thu, 17 Apr 2003 11:03:05 EDT
>
> 
> Second Workshop on Hot Topics in Networks (HotNets-II)
> November 20-21, 2003
> Cambridge, MA USA
> http://www.acm.org/sigcomm/HotNets-II
> 
> The Second Workshop on Hot Topics in Networks (HotNets-II) will bring
> together researchers in the networking and distributed systems
> community to debate emerging research directions.  The goal of the
> workshop is to promote community-wide discussion of ideas that will
> influence and foster continued research in the field.  The workshop
> will provide a venue for researchers to present new ideas that have
> the potential to significantly impact the community in the long term,
> especially those that are architectural or design-oriented in nature.
> Each potential participant should submit a short paper describing such
> an idea; the paper could, for example, expose a new problem, advocate
> a new solution, or debunk existing work.  Attendance is limited to
> around 60 participants, by invitation based primarily on paper
> submissions. HotNets is sponsored by ACM SIGCOMM.
> 
> HotNets is intended to cover a broad range of technical issues in the
> area of networking and distributed systems.  The topics of interest
> include, but are by no means limited to:
> 
> *Internet architecture, past, present, and future
> 
> *Overlay, peer-to-peer, and programmable network infrastructures
> 
> *Sensor networks, storage area networks, and other examples of "extreme"
>  networking
> 
> *Wireless networks, mobility, and pervasive computing
> 
> *Network fault-tolerance, reliability, and security
> 
> *Network configuration, diagnosis, and resource management
> 
> *Novel distributed applications and services, including systems for
>  content distribution and real-time media.
> 
> *Lessons drawn from failed research, and controversial or disruptive
>  topics
> 
> *Architectural insights or understanding of network behavior
> 
> 
> The selection of HotNets papers will be based primarily on their
> potential to influence future research.  This influence can be
> exercised in many ways, exemplified by but not limited to the following:
> 
> *Describing a novel approach to an old problem that promises to
>  influence future research
> 
> *Describing a new problem that requires our attention
> 
> *Articulating a new perspective about networking and distributed
>  systems
> 
> *Debunking an old perspective about networking and distributed systems
> 
> 
> HotNets papers are often the nascent forms of papers that will
> eventually be published, in full-length form, at conferences like ACM
> SIGCOMM, SenSys, MobiCom, SOSP and others.  Online copies of the
> position papers will be made publicly available via the Web prior to
> the workshop.  Proceedings will be distributed at the workshop and
> will be made available through ACM's digital library.
> 
> Submission Instructions: Position papers must be no longer than 6
> pages (10 pt font, 1 inch margins). Only electronic submissions in
> PostScript or PDF will be accepted. Submissions must be written in
> English, render without error using standard tools (Ghostview or
> Acrobat Reader) and print on US-Letter sized paper. All submissions
> will be acknowledged within 24 hours of receipt.
> 
> Submission information will be posted at:
> http://nms.lcs.mit.edu/HotNets-II/
> 
> 
> 
>       IMPORTANT DATES:
> 
> Submissions due:                              18 July     2003 *(HARD)*
> Notification of Acceptance:                    1 October  2003
> Camera-ready copy due:                         1 November 2002
> Workshop:                                     20 November 2003
> 
> 
>  
> Program Committee:
> 
>         Hari Balakrishnan (MIT) (Co-chair)
>         Steve Gribble (U. Washington)
>         Mark Handley (UCL)
>         Jim Kurose (UMass)
>         Nick McKeown (Stanford)
>         Scott Shenker (ICSI and UCB) (Co-chair)
>         David Tennenhouse (Intel)
>         Ellen Zegura (Georgia Tech)
>         Hui Zhang (Turin Networks and CMU)
> 
> 
> 

------- End of Forwarded Message

Date: Thu, 10 Apr 2003 11:16:20 +0100 (IST)
Subject: Re: [dtn-interest] testing...
From: "Stephen Farrell" <[email-masked]>
To: <[email-masked]>
Importance: Normal
Cc: <[email-masked]>, <[email-masked]>
Reply-To: [email-masked]
Sender: [email-masked]

Keith,

Great stuff! And exactly what I wanted. Thanks.

I assume you're going to include this text somewhere in future
releases - it looks like it'd help a lot.

Thanks again,
Stephen.

PS: I won't get back to this 'till Monday, but will no doubt have
some more questions then.

> OK, answers to your questions inline below.  Please let me know how this
> goes and what I forgot so I can build a better 'how-to' document.
>
>                 --keith
>
> At 04:02 PM 4/9/2003 +0100, Stephen Farrell wrote:
>
>>I've now built the DTN code for cygwin (I sent Kevin the diffs, let me
>> know if you want 'em), and would like a bit more guidance on checking
>> its working.
> Cool!
>
>
>>So, two things:-
>>
>>1. Could someone who knows how, create a set of configuration files
>> that matches the "IPN example" draft recently published? (Its hard to
>> tell how to interpret the sample configurations in the release, and
>> they don't seem to quite match up, e.g. "/etc/bundles/route" mentions
>>MITRE1 which isn't in "/etc/bundles/bundleNode.conf". Ideally,
>>those config files would let me run the entire "solar system" on a
>> single host.
> The following config files should handle the example in the draft.  I
> have included one intermittent contact between Earth and Mars, just for
> kicks.  You must run the contactManager application to instantiate the
> contact in the gw1 node: "# contactManager -f /etc/bundles/contacts"
>
> While the region names are somewhat arbitrary, the administrative parts
> (e.g. gw1.ipn.sol) need to be in the right host tables.  For this
> example that means that everybody needs all of the "X.ipn.sol" names.
>
> On machine "GW1"
> /etc/bundles/bundleNode.conf
> debugCmdLineInterface 1
> debug 0
> doMutexChecking 0
> region   earth.sol      gw1.earth.sol   tcp     no
> region   ipn.sol        gw1.ipn.sol     tcp     no
>
> /etc/bundles/route
> venus.sol       gw3.ipn.sol     ONDEMAND
> jupiter.sol     gw4.ipn.sol     ONDEMAND
> # Uncomment this to have full ONDEMAND connectivity
> # mars.sol      gw2.ipn.sol     ONDEMAND
>
> /etc/bundles/local.conf
> earth.sol
>
> /etc/bundles/contacts
> # An intermittent contact that handles destination region mars.sol # via
> gw2.mars.sol  Each contact lasts 10 seconds and can handle
> # 1 megabyte.  Contact recurs every 30 seconds and the whole cycle #
> (starting with a 10 second contact) begins 5 seconds from now
> COMMENT mars.sol gw2.mars.sol INTERMITTENT 6 10 1000000 +5 30
>
>
> On machine "GW2"
> /etc/bundles/bundleNode.conf
> debugCmdLineInterface 1
> debug 0
> doMutexChecking 0
> region ipn.sol          gw2.ipn.sol     tcp     no
> region mars.sol gw2.mars.sol    tcp     no
>
> /etc/bundles/route
> earth.sol       gw1.ipn.sol     ONDEMAND
> jupiter.sol     gw4.ipn.sol     ONDEMAND
> venus.sol       gw3.ipn.sol     ONDEMAND
>
> /etc/bundles/local.conf
> mars.sol
>
> On machine "GW3"
> /etc/bundles/bundleNode.conf
> debugCmdLineInterface 1
> debug 0
> doMutexChecking 0
> region ipn.sol          gw3.ipn.sol     tcp no
> region venus.sol        gw3.venus.sol   tcp no
>
> /etc/bundles/route
> earth.sol       gw1.ipn.sol     ONDEMAND
> jupiter.sol     gw4.ipn.sol     ONDEMAND
> mars.sol        gw2.ipn.sol     ONDEMAND
>
> /etc/bundles/local.conf
> venus.sol
>
> On machine "GW4"
> /etc/bundles/bundleNode.conf
> debugCmdLineInterface 1
> debug 0
> doMutexChecking 0
> region ipn.sol          gw4.ipn.sol     tcp no
> region jupiter.sol      gw4.jupiter.sol tcp no
>
> /etc/bundles/route
> earth.sol       gw1.ipn.sol     ONDEMAND
> venus.sol       gw3.ipn.sol     ONDEMAND
> mars.sol        gw2.ipn.sol     ONDEMAND
>
> /etc/bundles/local.conf
> jupiter.sol
>
>
> If you want to add another machine in the earth.sol region, you could
> configure it like this:
>
> On machine "EarthBox"
> /etc/bundles/bundleNode.conf
> debugCmdLineInterface 1
> debug 0
> doMutexChecking 0
> region earth.sol        earthBox.earth.sol      tcp no
>
> /etc/bundles/route
> *       gw1.earth.sol   ONDEMAND
>
> /etc/bundles/local.conf
> earth.sol
>
> This box communicates with all other regions via GW1.  If you do this,
> make sure to add earthBox.earth.sol to GW1's host table.
>
>
>
>>2. Any chance of a blow-by-blow guide to what to do once you
>>(may:-) have a working build? I realise that its only the first
>> release, and I'm asking for a lot, but even an outline would be useful.
>
> I usually use the GUI rcvBundle app and the command-line sender.  Note
> that unless you managed to statically link the bundleDaemon executable,
> your LD_LIBRARY_PATH needs to be set up right to hit all the shared
> objects.  I use: setenv LD_LIBRARY_PATH
> /usr/local/BerkeleyDB.4.0/lib:$SOURCE_ROOT/libdtn/.libs:$SOURCE_ROOT/utils/.libs:$SOURCE_ROOT/tcpCL/.libs:$SOURCE_ROOT/moteCL/.libs:$SOURCE_ROOT/dtncfdp/cfdp/.libs
> where $SOURCE_ROOT is the top DTN directory.
>
> Start all the gateways, use the contact manage to get the Earth->Mars
> intermittent contact established, then start the rcvBundle app on the
> destination host (gateway or earthBox).
>
> The 'debugCmdLineInterface 1' lines in the bundleNode.conf files cause
> the bundle daemons to provide a primitive DEBUGGING command line
> interface.  Note that this interface is ONLY for programmers/developers
> -- it is not meant to be an interface to normal users --.  OK, that
> said, hit CR a few times to get a prompt and then you can type commands.
>  Useful things are 'help'  'status', 'ss' (for status, short), and
> 'evinfo'.  Status should tell you things about how many bundles are
> queued for transmission where, and the current state of intermittent
> contacts.  (I haven't cleaned out the help command since the very early
> days of debugging and hand-generation of bundles.  Anything there that
> pertains to manually generating bundles and forcing them down the
> daemon's throat is probably non-functional and will disappear in the
> next release).
>
> Start the rcvBundle application on the destination (same host as the
> destination bundleAgent).  Tell it that the bundleAgent is localhost,
> and give it the region of the receiving interface (i.e. if you start
> rcvBundle on the mars gateway and will be receiving bundles from earth,
> say 'ipn.sol' here).  Give it the hostname of the receiving interface
> (e.g. mars.ipn.sol).  Finally, the 'Demux key' is the moral equivalent
> of a port number, allowing the bundle daemon to demultiplex bundles to
> applications.  Pick something (you'll need to supply it at the sender as
> well).  Remember to click 'Register'.  Deregistration doesn't entirely
> work yet, so if you quit the bundle daemon on the destination host and
> restart it (or click Register again to attempt to deregister), you'll
> have to restart rcvBundle.
>
> If you prefer the console async_rcvr application (in the AsyncRcvr
> directory), it can be invoked with ./async_rcvr -b localhost -s demux
> (the console app uses the default region and hostname; that's why it
> takes fewer parameters than the gui app -- need to fix this).
>
> On the sending host, cd to the SndBundle2 directory and source a bundle:
> ./snd_bundle -R DEST_REGION -A DEST_HOST/DEMUX_KEY -s 2 -f /etc/motd -e
> 100 -n 1
>
> This sends a bundle to region DEST_REGION, host DEST_HOST and to the
> application that registered with the DEMUX_KEY.  '-s 2' means send a
> file, -f FILENAME is pretty obvious, bundle expires in 100 seconds and
> do this once (-n 1).
>
> Note that if you picked Mars as your destination and Earth as your
> source, the bundle may not show up immediately (it may be waiting for
> the intermittent contact to come back).  Typing 'status' repeatedly at
> the source bundle daemon will tell you when the contact starts (see
> output below).  Alternately you can use the gdtnperf application to
> graphically display the queue size and connectivity to a particular
> destination:
>
> run the gdtnperf application at the sending side of an INTERMITTENT
> contact.  In the Preferences dialog, tell it that you want to communcate
> with the bundleAgent on localhost, with the next hop destination the
> other end of the INTERMITTENT contact (using Earth -> Mars example, the
> nextHopDestination would be ipn.sol, mars.ipn.sol).  It only understands
> UDP connections for now, and doens't like setting the delay between
> samples to under ~250ms.  The most useful configuration for the dials is
> to have 'DTN Contact' and maybe 'Connect Retries' shown.  The 'DTN
> Contact' dial shows information about connectivity (and is only really
> interesting for intermittent contacts).  When the dial is in the red,
> there's not contact, when its in the green, the contact is available.
> The 'Buffer Queue' meter shows how many bundles are queued for the
> destination.
>
>
>
>
> Sample 'status' output at source bundle daemon (comments in gray):
> bundle_daemon> status
> ***** Bundle Daemon Internal Dump *****
>
> DEBUG level: 0
> Convergence Layers
>   [ 1] TCP Convergence Layer
> BRG Lists:
>   Unassigned BRGs:
>   Retained BRGs:
>
> CLISTINFOs:
>   We currently have 1 contact list structure, don't know why the
> NextHopRegion isn't printing, suspect premature excision of a
> printf(), next hop destination is ipn2.sol.int, yadda, yadda, yadda.
> This is an INTERMITTENT contact that is currently inactive (CLOSED)
> and it will become available in 9 seconds (FUTURE -9)  Other
> CLISTINFOS (0x080E4200):
>     CLISTINFO:  0x080E0E80          NextHopRegion:
>     NextHopDestination:  ipn2.sol.int
>     BytesOnList: 0      BytesRemaining: 0
> HighPriorityBytesRemaining: 0
> ContactType: INTERMITTENT       State: CLOSED   Retries: 6
>     Start (1049911399, 0) (Wed Apr  9 14:03:19 2003)  [FUTURE -9]
> Start_var: 0        Duration: 10
> Duration_var: 0 Volume: 10000000        Volume_var: 0
>     BundleInterface: 0x08079FC8
>       localRegionName:    (MITRE1, ipn1.sol.int)
>       argstr: 15
>       transportNumber:   1
>       direct:            0
>     Bundles (BRG:(nil)):
> If there were bundles queued for this contact, they'd be listed here.
>
>
> Routing Table Info:
> (0x080772a0 . : (, ) : ONDEMAND parent(0x00000000)
>   (0x080b1ea8 MITRE2 : (MITRE2, ipn3_mitre2.sol.int) : ONDEMAND
> parent(0x080772a0)  (0x080b21e0 internet : (internet,
> playground.intel-research.net) : ONDEMAND parent(0x080772a0)
> (0x080d78d0 MITRE1 : (MITRE1, ipn2.sol.int) : INTERMITENT
> parent(0x080772a0)
>
> MIB Info
>
> mib.bundlesReceived =                0
> mib.bundlesSuccessfullyTransmitted = 3
> mib.bundlesSuccessfullyDelivered =   0
>
> mib.bundlesExpired =                 0
> mib.bundlesSourced =                 0
> Bundle Database:
>      Bundle database contains 0 bundles.
>
> Registration Database:
>      Database contains no Registrations
>
>
> Demux Database:
>      Demux database contains 0 entries.
>
>
>>Ta,
>>Stephen.
>>
>>_______________________________________________
>>dtn-interest mailing list
>>[email-masked]
>>http://mailman.dtnrg.org/mailman/listinfo/dtn-interest

Date: Wed, 9 Apr 2003 16:22:58 -0400 (EDT)
From: "Andrew R. Reiter" <[email-masked]>
To: [email-masked]
Subject: is this list archived was: [dtn-interest] testing...
Sender: [email-masked]

Is this list archived anywhere?  Curious so I can know if I need to keep
track of some of these emails.

Thanks!

Cheers,
Andrew

On Wed, 9 Apr 2003, Keith Scott wrote:

:OK, answers to your questions inline below.  Please let me know how this goes and what I forgot so I can build a better 'how-to' document.
:
:                --keith
:
:At 04:02 PM 4/9/2003 +0100, Stephen Farrell wrote:
:
:>I've now built the DTN code for cygwin (I sent Kevin the diffs, let me
:>know if you want 'em), and would like a bit more guidance on checking
:>its working.
:Cool!
:
:
:>So, two things:-
:>
:>1. Could someone who knows how, create a set of configuration files
:>that matches the "IPN example" draft recently published? (Its hard to
:>tell how to interpret the sample configurations in the release, and they
:>don't seem to quite match up, e.g. "/etc/bundles/route" mentions
:>MITRE1 which isn't in "/etc/bundles/bundleNode.conf". Ideally,
:>those config files would let me run the entire "solar system" on a single
:>host.
:The following config files should handle the example in the draft.  I have included one intermittent contact between Earth and Mars, just for kicks.  You must run the contactManager application to instantiate the contact in the gw1 node: "# contactManager -f /etc/bundles/contacts"
:
:While the region names are somewhat arbitrary, the administrative parts (e.g. gw1.ipn.sol) need to be in the right host tables.  For this example that means that everybody needs all of the "X.ipn.sol" names.
:
:On machine "GW1"
:/etc/bundles/bundleNode.conf
:debugCmdLineInterface 1
:debug 0
:doMutexChecking 0
:region   earth.sol      gw1.earth.sol   tcp     no
:region   ipn.sol        gw1.ipn.sol     tcp     no
:
:/etc/bundles/route
:venus.sol       gw3.ipn.sol     ONDEMAND
:jupiter.sol     gw4.ipn.sol     ONDEMAND
:# Uncomment this to have full ONDEMAND connectivity
:# mars.sol      gw2.ipn.sol     ONDEMAND
:
:/etc/bundles/local.conf
:earth.sol
:
:/etc/bundles/contacts
:# An intermittent contact that handles destination region mars.sol
:# via gw2.mars.sol  Each contact lasts 10 seconds and can handle
:# 1 megabyte.  Contact recurs every 30 seconds and the whole cycle
:# (starting with a 10 second contact) begins 5 seconds from now
:COMMENT mars.sol gw2.mars.sol INTERMITTENT 6 10 1000000 +5 30
:
:
:On machine "GW2"
:/etc/bundles/bundleNode.conf
:debugCmdLineInterface 1
:debug 0
:doMutexChecking 0
:region ipn.sol          gw2.ipn.sol     tcp     no
:region mars.sol gw2.mars.sol    tcp     no
:
:/etc/bundles/route
:earth.sol       gw1.ipn.sol     ONDEMAND
:jupiter.sol     gw4.ipn.sol     ONDEMAND
:venus.sol       gw3.ipn.sol     ONDEMAND
:
:/etc/bundles/local.conf
:mars.sol
:
:On machine "GW3"
:/etc/bundles/bundleNode.conf
:debugCmdLineInterface 1
:debug 0
:doMutexChecking 0
:region ipn.sol          gw3.ipn.sol     tcp no
:region venus.sol        gw3.venus.sol   tcp no
:
:/etc/bundles/route
:earth.sol       gw1.ipn.sol     ONDEMAND
:jupiter.sol     gw4.ipn.sol     ONDEMAND
:mars.sol        gw2.ipn.sol     ONDEMAND
:
:/etc/bundles/local.conf
:venus.sol
:
:On machine "GW4"
:/etc/bundles/bundleNode.conf
:debugCmdLineInterface 1
:debug 0
:doMutexChecking 0
:region ipn.sol          gw4.ipn.sol     tcp no
:region jupiter.sol      gw4.jupiter.sol tcp no
:
:/etc/bundles/route
:earth.sol       gw1.ipn.sol     ONDEMAND
:venus.sol       gw3.ipn.sol     ONDEMAND
:mars.sol        gw2.ipn.sol     ONDEMAND
:
:/etc/bundles/local.conf
:jupiter.sol
:
:
:If you want to add another machine in the earth.sol region, you could configure it like this:
:
:On machine "EarthBox"
:/etc/bundles/bundleNode.conf
:debugCmdLineInterface 1
:debug 0
:doMutexChecking 0
:region earth.sol        earthBox.earth.sol      tcp no
:
:/etc/bundles/route
:*       gw1.earth.sol   ONDEMAND
:
:/etc/bundles/local.conf
:earth.sol
:
:This box communicates with all other regions via GW1.  If you do this, make sure to add earthBox.earth.sol to GW1's host table.
:
:
:
:>2. Any chance of a blow-by-blow guide to what to do once you
:>(may:-) have a working build? I realise that its only the first release,
:>and I'm asking for a lot, but even an outline would be useful.
:
:I usually use the GUI rcvBundle app and the command-line sender.  Note that unless you managed to statically link the bundleDaemon executable, your LD_LIBRARY_PATH needs to be set up right to hit all the shared objects.  I use:
:setenv LD_LIBRARY_PATH /usr/local/BerkeleyDB.4.0/lib:$SOURCE_ROOT/libdtn/.libs:$SOURCE_ROOT/utils/.libs:$SOURCE_ROOT/tcpCL/.libs:$SOURCE_ROOT/moteCL/.libs:$SOURCE_ROOT/dtncfdp/cfdp/.libs
:where $SOURCE_ROOT is the top DTN directory.
:
:Start all the gateways, use the contact manage to get the Earth->Mars intermittent contact established, then start the rcvBundle app on the destination host (gateway or earthBox).
:
:The 'debugCmdLineInterface 1' lines in the bundleNode.conf files cause the bundle daemons to provide a primitive DEBUGGING command line interface.  Note that this interface is ONLY for programmers/developers -- it is not meant to be an interface to normal users --.  OK, that said, hit CR a few times to get a prompt and then you can type commands.  Useful things are 'help'  'status', 'ss' (for status, short), and 'evinfo'.  Status should tell you things about how many bundles are queued for transmission where, and the current state of intermittent contacts.  (I haven't cleaned out the help command since the very early days of debugging and hand-generation of bundles.  Anything there that pertains to manually generating bundles and forcing them down the daemon's throat is probably non-functional and will disappear in the next release).
:
:Start the rcvBundle application on the destination (same host as the destination bundleAgent).  Tell it that the bundleAgent is localhost, and give it the region of the receiving interface (i.e. if you start rcvBundle on the mars gateway and will be receiving bundles from earth, say 'ipn.sol' here).  Give it the hostname of the receiving interface (e.g. mars.ipn.sol).  Finally, the 'Demux key' is the moral equivalent of a port number, allowing the bundle daemon to demultiplex bundles to applications.  Pick something (you'll need to supply it at the sender as well).  Remember to click 'Register'.  Deregistration doesn't entirely work yet, so if you quit the bundle daemon on the destination host and restart it (or click Register again to attempt to deregister), you'll have to restart rcvBundle.
:
:If you prefer the console async_rcvr application (in the AsyncRcvr directory), it can be invoked with
:./async_rcvr -b localhost -s demux  (the console app uses the default region and hostname; that's why it takes fewer parameters than the gui app -- need to fix this).
:
:On the sending host, cd to the SndBundle2 directory and source a bundle:
:./snd_bundle -R DEST_REGION -A DEST_HOST/DEMUX_KEY -s 2 -f /etc/motd -e 100 -n 1
:
:This sends a bundle to region DEST_REGION, host DEST_HOST and to the application that registered with the DEMUX_KEY.  '-s 2' means send a file, -f FILENAME is pretty obvious, bundle expires in 100 seconds and do this once (-n 1).
:
:Note that if you picked Mars as your destination and Earth as your source, the bundle may not show up immediately (it may be waiting for the intermittent contact to come back).  Typing 'status' repeatedly at the source bundle daemon will tell you when the contact starts (see output below).  Alternately you can use the gdtnperf application to graphically display the queue size and connectivity to a particular destination:
:
:run the gdtnperf application at the sending side of an INTERMITTENT contact.  In the Preferences dialog, tell it that you want to communcate with the bundleAgent on localhost, with the next hop destination the other end of the INTERMITTENT contact (using Earth -> Mars example, the nextHopDestination would be ipn.sol, mars.ipn.sol).  It only understands UDP connections for now, and doens't like setting the delay between samples to under ~250ms.  The most useful configuration for the dials is to have 'DTN Contact' and maybe 'Connect Retries' shown.  The 'DTN Contact' dial shows information about connectivity (and is only really interesting for intermittent contacts).  When the dial is in the red, there's not contact, when its in the green, the contact is available.  The 'Buffer Queue' meter shows how many bundles are queued for the destination.
:
:
:
:
:Sample 'status' output at source bundle daemon (comments in gray):
:bundle_daemon> status
:***** Bundle Daemon Internal Dump *****
:
:DEBUG level: 0
:Convergence Layers
:  [ 1] TCP Convergence Layer
:BRG Lists:
:  Unassigned BRGs:
:  Retained BRGs:
:
:CLISTINFOs:
:  We currently have 1 contact list structure, don't know why the NextHopRegion isn't printing, suspect premature excision of a printf(), next hop destination is ipn2.sol.int, yadda, yadda, yadda.  This is an INTERMITTENT contact that is currently inactive (CLOSED) and it will become available in 9 seconds (FUTURE -9)
:  Other CLISTINFOS (0x080E4200):
:    CLISTINFO:  0x080E0E80          NextHopRegion:
:    NextHopDestination:  ipn2.sol.int
:    BytesOnList: 0      BytesRemaining: 0       HighPriorityBytesRemaining: 0
:ContactType: INTERMITTENT       State: CLOSED   Retries: 6
:    Start (1049911399, 0) (Wed Apr  9 14:03:19 2003)  [FUTURE -9]
:    Start_var: 0        Duration: 10
:Duration_var: 0 Volume: 10000000        Volume_var: 0
:    BundleInterface: 0x08079FC8
:      localRegionName:    (MITRE1, ipn1.sol.int)
:      argstr: 15
:      transportNumber:   1
:      direct:            0
:    Bundles (BRG:(nil)):
:If there were bundles queued for this contact, they'd be listed here.
:
:
:Routing Table Info:
:(0x080772a0 . : (, ) : ONDEMAND parent(0x00000000)
:  (0x080b1ea8 MITRE2 : (MITRE2, ipn3_mitre2.sol.int) : ONDEMAND parent(0x080772a0)
:  (0x080b21e0 internet : (internet, playground.intel-research.net) : ONDEMAND parent(0x080772a0)
:  (0x080d78d0 MITRE1 : (MITRE1, ipn2.sol.int) : INTERMITENT parent(0x080772a0)
:
:MIB Info
:
:mib.bundlesReceived =                0
:mib.bundlesSuccessfullyTransmitted = 3
:mib.bundlesSuccessfullyDelivered =   0
:
:mib.bundlesExpired =                 0
:mib.bundlesSourced =                 0
:Bundle Database:
:     Bundle database contains 0 bundles.
:
:Registration Database:
:     Database contains no Registrations
:
:
:Demux Database:
:     Demux database contains 0 entries.
:
:
:>Ta,
:>Stephen.
:>
:>_______________________________________________
:>dtn-interest mailing list
:>[email-masked]
:>http://mailman.dtnrg.org/mailman/listinfo/dtn-interest
:
:

--
Andrew R. Reiter
[email-masked]
[email-masked]

Date: Wed, 09 Apr 2003 15:17:17 -0400
To: [email-masked] (Stephen Farrell), [email-masked]
From: [email-masked] (Keith Scott)
Subject: Re: [dtn-interest] testing...
Sender: [email-masked]

--=====================_9621915==.ALT
Content-Type: text/plain; charset="us-ascii"

OK, answers to your questions inline below.  Please let me know how this goes and what I forgot so I can build a better 'how-to' document.

                --keith

At 04:02 PM 4/9/2003 +0100, Stephen Farrell wrote:

>I've now built the DTN code for cygwin (I sent Kevin the diffs, let me
>know if you want 'em), and would like a bit more guidance on checking
>its working.
Cool!

>So, two things:-
>
>1. Could someone who knows how, create a set of configuration files
>that matches the "IPN example" draft recently published? (Its hard to
>tell how to interpret the sample configurations in the release, and they
>don't seem to quite match up, e.g. "/etc/bundles/route" mentions
>MITRE1 which isn't in "/etc/bundles/bundleNode.conf". Ideally,
>those config files would let me run the entire "solar system" on a single
>host.
The following config files should handle the example in the draft.  I have included one intermittent contact between Earth and Mars, just for kicks.  You must run the contactManager application to instantiate the contact in the gw1 node: "# contactManager -f /etc/bundles/contacts"

While the region names are somewhat arbitrary, the administrative parts (e.g. gw1.ipn.sol) need to be in the right host tables.  For this example that means that everybody needs all of the "X.ipn.sol" names.

On machine "GW1"
/etc/bundles/bundleNode.conf
debugCmdLineInterface 1
debug 0
doMutexChecking 0
region   earth.sol      gw1.earth.sol   tcp     no 
region   ipn.sol        gw1.ipn.sol     tcp     no 

/etc/bundles/route
venus.sol       gw3.ipn.sol     ONDEMAND
jupiter.sol     gw4.ipn.sol     ONDEMAND
# Uncomment this to have full ONDEMAND connectivity
# mars.sol      gw2.ipn.sol     ONDEMAND

/etc/bundles/local.conf
earth.sol

/etc/bundles/contacts
# An intermittent contact that handles destination region mars.sol
# via gw2.mars.sol  Each contact lasts 10 seconds and can handle
# 1 megabyte.  Contact recurs every 30 seconds and the whole cycle
# (starting with a 10 second contact) begins 5 seconds from now
COMMENT mars.sol gw2.mars.sol INTERMITTENT 6 10 1000000 +5 30

On machine "GW2"
/etc/bundles/bundleNode.conf
debugCmdLineInterface 1
debug 0
doMutexChecking 0
region ipn.sol          gw2.ipn.sol     tcp     no
region mars.sol gw2.mars.sol    tcp     no

/etc/bundles/route
earth.sol       gw1.ipn.sol     ONDEMAND
jupiter.sol     gw4.ipn.sol     ONDEMAND
venus.sol       gw3.ipn.sol     ONDEMAND

/etc/bundles/local.conf
mars.sol

On machine "GW3"
/etc/bundles/bundleNode.conf
debugCmdLineInterface 1
debug 0
doMutexChecking 0
region ipn.sol          gw3.ipn.sol     tcp no
region venus.sol        gw3.venus.sol   tcp no

/etc/bundles/route
earth.sol       gw1.ipn.sol     ONDEMAND
jupiter.sol     gw4.ipn.sol     ONDEMAND
mars.sol        gw2.ipn.sol     ONDEMAND

/etc/bundles/local.conf
venus.sol

On machine "GW4"
/etc/bundles/bundleNode.conf
debugCmdLineInterface 1
debug 0
doMutexChecking 0
region ipn.sol          gw4.ipn.sol     tcp no
region jupiter.sol      gw4.jupiter.sol tcp no

/etc/bundles/route
earth.sol       gw1.ipn.sol     ONDEMAND
venus.sol       gw3.ipn.sol     ONDEMAND
mars.sol        gw2.ipn.sol     ONDEMAND

/etc/bundles/local.conf
jupiter.sol

If you want to add another machine in the earth.sol region, you could configure it like this:

On machine "EarthBox"
/etc/bundles/bundleNode.conf
debugCmdLineInterface 1
debug 0
doMutexChecking 0
region earth.sol        earthBox.earth.sol      tcp no

/etc/bundles/route
*       gw1.earth.sol   ONDEMAND

/etc/bundles/local.conf
earth.sol

This box communicates with all other regions via GW1.  If you do this, make sure to add earthBox.earth.sol to GW1's host table.

>2. Any chance of a blow-by-blow guide to what to do once you
>(may:-) have a working build? I realise that its only the first release,
>and I'm asking for a lot, but even an outline would be useful.

I usually use the GUI rcvBundle app and the command-line sender.  Note that unless you managed to statically link the bundleDaemon executable, your LD_LIBRARY_PATH needs to be set up right to hit all the shared objects.  I use:
setenv LD_LIBRARY_PATH /usr/local/BerkeleyDB.4.0/lib:$SOURCE_ROOT/libdtn/.libs:$SOURCE_ROOT/utils/.libs:$SOURCE_ROOT/tcpCL/.libs:$SOURCE_ROOT/moteCL/.libs:$SOURCE_ROOT/dtncfdp/cfdp/.libs
where $SOURCE_ROOT is the top DTN directory.

Start all the gateways, use the contact manage to get the Earth->Mars intermittent contact established, then start the rcvBundle app on the destination host (gateway or earthBox).  

The 'debugCmdLineInterface 1' lines in the bundleNode.conf files cause the bundle daemons to provide a primitive DEBUGGING command line interface.  Note that this interface is ONLY for programmers/developers -- it is not meant to be an interface to normal users --.  OK, that said, hit CR a few times to get a prompt and then you can type commands.  Useful things are 'help'  'status', 'ss' (for status, short), and 'evinfo'.  Status should tell you things about how many bundles are queued for transmission where, and the current state of intermittent contacts.  (I haven't cleaned out the help command since the very early days of debugging and hand-generation of bundles.  Anything there that pertains to manually generating bundles and forcing them down the daemon's throat is probably non-functional and will disappear in the next release).

Start the rcvBundle application on the destination (same host as the destination bundleAgent).  Tell it that the bundleAgent is localhost, and give it the region of the receiving interface (i.e. if you start rcvBundle on the mars gateway and will be receiving bundles from earth, say 'ipn.sol' here).  Give it the hostname of the receiving interface (e.g. mars.ipn.sol).  Finally, the 'Demux key' is the moral equivalent of a port number, allowing the bundle daemon to demultiplex bundles to applications.  Pick something (you'll need to supply it at the sender as well).  Remember to click 'Register'.  Deregistration doesn't entirely work yet, so if you quit the bundle daemon on the destination host and restart it (or click Register again to attempt to deregister), you'll have to restart rcvBundle.

If you prefer the console async_rcvr application (in the AsyncRcvr directory), it can be invoked with
./async_rcvr -b localhost -s demux  (the console app uses the default region and hostname; that's why it takes fewer parameters than the gui app -- need to fix this).

On the sending host, cd to the SndBundle2 directory and source a bundle:
./snd_bundle -R DEST_REGION -A DEST_HOST/DEMUX_KEY -s 2 -f /etc/motd -e 100 -n 1

This sends a bundle to region DEST_REGION, host DEST_HOST and to the application that registered with the DEMUX_KEY.  '-s 2' means send a file, -f FILENAME is pretty obvious, bundle expires in 100 seconds and do this once (-n 1).

Note that if you picked Mars as your destination and Earth as your source, the bundle may not show up immediately (it may be waiting for the intermittent contact to come back).  Typing 'status' repeatedly at the source bundle daemon will tell you when the contact starts (see output below).  Alternately you can use the gdtnperf application to graphically display the queue size and connectivity to a particular destination:

run the gdtnperf application at the sending side of an INTERMITTENT contact.  In the Preferences dialog, tell it that you want to communcate with the bundleAgent on localhost, with the next hop destination the other end of the INTERMITTENT contact (using Earth -> Mars example, the nextHopDestination would be ipn.sol, mars.ipn.sol).  It only understands UDP connections for now, and doens't like setting the delay between samples to under ~250ms.  The most useful configuration for the dials is to have 'DTN Contact' and maybe 'Connect Retries' shown.  The 'DTN Contact' dial shows information about connectivity (and is only really interesting for intermittent contacts).  When the dial is in the red, there's not contact, when its in the green, the contact is available.  The 'Buffer Queue' meter shows how many bundles are queued for the destination.

Sample 'status' output at source bundle daemon (comments in gray):  
bundle_daemon> status 
***** Bundle Daemon Internal Dump ***** 

DEBUG level: 0 
Convergence Layers 
  [ 1] TCP Convergence Layer 
BRG Lists: 
  Unassigned BRGs:
  Retained BRGs:

CLISTINFOs: 
  We currently have 1 contact list structure, don't know why the NextHopRegion isn't printing, suspect premature excision of a printf(), next hop destination is ipn2.sol.int, yadda, yadda, yadda.  This is an INTERMITTENT contact that is currently inactive (CLOSED) and it will become available in 9 seconds (FUTURE -9) 
  Other CLISTINFOS (0x080E4200): 
    CLISTINFO:  0x080E0E80          NextHopRegion:   
    NextHopDestination:  ipn2.sol.int 
    BytesOnList: 0      BytesRemaining: 0       HighPriorityBytesRemaining: 0 
ContactType: INTERMITTENT       State: CLOSED   Retries: 6 
    Start (1049911399, 0) (Wed Apr  9 14:03:19 2003)  [FUTURE -9] 
    Start_var: 0        Duration: 10 
Duration_var: 0 Volume: 10000000        Volume_var: 0 
    BundleInterface: 0x08079FC8 
      localRegionName:    (MITRE1, ipn1.sol.int) 
      argstr: 15 
      transportNumber:   1 
      direct:            0 
    Bundles (BRG:(nil)): 
If there were bundles queued for this contact, they'd be listed here.

Routing Table Info:
(0x080772a0 . : (, ) : ONDEMAND parent(0x00000000) 
  (0x080b1ea8 MITRE2 : (MITRE2, ipn3_mitre2.sol.int) : ONDEMAND parent(0x080772a0) 
  (0x080b21e0 internet : (internet, playground.intel-research.net) : ONDEMAND parent(0x080772a0) 
  (0x080d78d0 MITRE1 : (MITRE1, ipn2.sol.int) : INTERMITENT parent(0x080772a0)

MIB Info

mib.bundlesReceived =                0 
mib.bundlesSuccessfullyTransmitted = 3 
mib.bundlesSuccessfullyDelivered =   0

mib.bundlesExpired =                 0 
mib.bundlesSourced =                 0
Bundle Database: 
     Bundle database contains 0 bundles.

Registration Database: 
     Database contains no Registrations

Demux Database: 
     Demux database contains 0 entries.

>Ta,
>Stephen.
>
>_______________________________________________
>dtn-interest mailing list
>[email-masked]
>http://mailman.dtnrg.org/mailman/listinfo/dtn-interest

--=====================_9621915==.ALT
Content-Type: text/html; charset="us-ascii"

<html>
<body>
OK, answers to your questions inline below.&nbsp; Please let me know how
this goes and what I forgot so I can build a better 'how-to'
document.<br><br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>--keith<br><br>
At 04:02 PM 4/9/2003 +0100, Stephen Farrell wrote:<br><br>
<blockquote type=cite class=cite cite>I've now built the DTN code for
cygwin (I sent Kevin the diffs, let me<br>
know if you want 'em), and would like a bit more guidance on
checking<br>
its working.</blockquote>Cool!<br><br>
<br>
<blockquote type=cite class=cite cite>So, two things:-<br><br>
1. Could someone who knows how, create a set of configuration files<br>
that matches the &quot;IPN example&quot; draft recently published? (Its
hard to<br>
tell how to interpret the sample configurations in the release, and
they<br>
don't seem to quite match up, e.g. &quot;/etc/bundles/route&quot;
mentions<br>
MITRE1 which isn't in &quot;/etc/bundles/bundleNode.conf&quot;.
Ideally,<br>
those config files would let me run the entire &quot;solar system&quot;
on a single<br>
host.</blockquote>The following config files should handle the example in
the draft.&nbsp; I have included one intermittent contact between Earth
and Mars, just for kicks.&nbsp; You must run the contactManager
application to instantiate the contact in the gw1 node: &quot;#
contactManager -f /etc/bundles/contacts&quot;<br><br>
While the region names are somewhat arbitrary, the administrative parts
(e.g. gw1.ipn.sol) need to be in the right host tables.&nbsp; For this
example that means that everybody needs all of the &quot;X.ipn.sol&quot;
names.<br><br>
<b>On machine &quot;GW1&quot;<br>
</b><font color="#0000FF"><i>/etc/bundles/bundleNode.conf<br>
</i></font>debugCmdLineInterface 1<br>
debug 0<br>
doMutexChecking 0<br>
region&nbsp;&nbsp;
earth.sol<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>gw1.earth.sol<x-tab>&nbsp;&nbsp;&nbsp;</x-tab>tcp&nbsp;&nbsp;&nbsp;&nbsp;
no <br>
region&nbsp;&nbsp;
ipn.sol<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>gw1.ipn.sol<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>tcp&nbsp;&nbsp;&nbsp;&nbsp;
no <br><br>
<font color="#0000FF"><i>/etc/bundles/route<br>
</i></font>venus.sol<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>gw3.ipn.sol<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>ONDEMAND<br>
jupiter.sol<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>gw4.ipn.sol<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>ONDEMAND<br>
# Uncomment this to have full ONDEMAND connectivity<br>
#
mars.sol<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>gw2.ipn.sol<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>ONDEMAND<br><br>
<font color="#0000FF"><i>/etc/bundles/local.conf<br>
</i></font>earth.sol<br><br>
<font color="#0000FF"><i>/etc/bundles/contacts<br>
</i></font># An intermittent contact that handles destination region
mars.sol<br>
# via gw2.mars.sol&nbsp; Each contact lasts 10 seconds and can
handle<br>
# 1 megabyte.&nbsp; Contact recurs every 30 seconds and the whole
cycle<br>
# (starting with a 10 second contact) begins 5 seconds from now<br>
COMMENT mars.sol gw2.mars.sol INTERMITTENT 6 10 1000000 +5 30<br><br>
<br>
<b>On machine &quot;GW2&quot;<br>
</b><font color="#0000FF"><i>/etc/bundles/bundleNode.conf<br>
</i></font>debugCmdLineInterface 1<br>
debug 0<br>
doMutexChecking 0<br>
region
ipn.sol<x-tab>&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>gw2.ipn.sol<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>tcp<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>no<br>
region
mars.sol<x-tab>&nbsp;</x-tab>gw2.mars.sol<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>tcp<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>no<br><br>
<font color="#0000FF"><i>/etc/bundles/route<br>
</i></font>earth.sol<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>gw1.ipn.sol<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>ONDEMAND<br>
jupiter.sol<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>gw4.ipn.sol<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>ONDEMAND<br>
venus.sol<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>gw3.ipn.sol<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>ONDEMAND<br><br>
<font color="#0000FF"><i>/etc/bundles/local.conf<br>
</i></font>mars.sol<br><br>
<b>On machine &quot;GW3&quot;<br>
</b><font color="#0000FF"><i>/etc/bundles/bundleNode.conf<br>
</i></font>debugCmdLineInterface 1<br>
debug 0<br>
doMutexChecking 0<br>
region
ipn.sol<x-tab>&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>gw3.ipn.sol<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>tcp
no<br>
region
venus.sol<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>gw3.venus.sol<x-tab>&nbsp;&nbsp;&nbsp;</x-tab>tcp
no<br><br>
<font color="#0000FF"><i>/etc/bundles/route<br>
</i></font>earth.sol<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>gw1.ipn.sol<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>ONDEMAND<br>
jupiter.sol<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>gw4.ipn.sol<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>ONDEMAND<br>
mars.sol<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>gw2.ipn.sol<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>ONDEMAND<br><br>
<font color="#0000FF"><i>/etc/bundles/local.conf<br>
</i></font>venus.sol<br><br>
<b>On machine &quot;GW4&quot;<br>
</b><font color="#0000FF"><i>/etc/bundles/bundleNode.conf<br>
</i></font>debugCmdLineInterface 1<br>
debug 0<br>
doMutexChecking 0<br>
region
ipn.sol<x-tab>&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>gw4.ipn.sol<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>tcp
no<br>
region
jupiter.sol<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>gw4.jupiter.sol<x-tab>&nbsp;</x-tab>tcp
no<br><br>
<font color="#0000FF"><i>/etc/bundles/route<br>
</i></font>earth.sol<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>gw1.ipn.sol<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>ONDEMAND<br>
venus.sol<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>gw3.ipn.sol<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>ONDEMAND<br>
mars.sol<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>gw2.ipn.sol<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>ONDEMAND<br><br>
<font color="#0000FF"><i>/etc/bundles/local.conf<br>
</i></font>jupiter.sol<br><br>
<br>
If you want to add another machine in the earth.sol region, you could
configure it like this:<br><br>
<b>On machine &quot;EarthBox&quot;<br>
</b><font color="#0000FF"><i>/etc/bundles/bundleNode.conf<br>
</i></font>debugCmdLineInterface 1<br>
debug 0<br>
doMutexChecking 0<br>
region
earth.sol<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>earthBox.earth.sol<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>tcp
no<br><br>
<font color="#0000FF"><i>/etc/bundles/route<br>
</i></font>*<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>gw1.earth.sol<x-tab>&nbsp;&nbsp;&nbsp;</x-tab>ONDEMAND<br><br>
<font color="#0000FF"><i>/etc/bundles/local.conf<br>
</i></font>earth.sol<br><br>
This box communicates with all other regions via GW1.&nbsp; If you do
this, make sure to add earthBox.earth.sol to GW1's host table.<br><br>
<br><br>
<blockquote type=cite class=cite cite>2. Any chance of a blow-by-blow
guide to what to do once you<br>
(may:-) have a working build? I realise that its only the first
release,<br>
and I'm asking for a lot, but even an outline would be
useful.</blockquote><br>
I usually use the GUI rcvBundle app and the command-line sender.&nbsp;
Note that unless you managed to statically link the bundleDaemon
executable, your LD_LIBRARY_PATH needs to be set up right to hit all the
shared objects.&nbsp; I use:<br>
<font color="#FF0000">setenv LD_LIBRARY_PATH
/usr/local/BerkeleyDB.4.0/lib:$SOURCE_ROOT/libdtn/.libs:$SOURCE_ROOT/utils/.libs:$SOURCE_ROOT/tcpCL/.libs:$SOURCE_ROOT/moteCL/.libs:$SOURCE_ROOT/dtncfdp/cfdp/.libs<br>
</font>where $SOURCE_ROOT is the top DTN directory.<br><br>
Start all the gateways, use the contact manage to get the Earth-&gt;Mars
intermittent contact established, then start the rcvBundle app on the
destination host (gateway or earthBox).&nbsp; <br><br>
The 'debugCmdLineInterface 1' lines in the bundleNode.conf files cause
the bundle daemons to provide a primitive DEBUGGING command line
interface.&nbsp; Note that this interface is ONLY for
programmers/developers -- it is not meant to be an interface to normal
users --.&nbsp; OK, that said, hit CR a few times to get a prompt and
then you can type commands.&nbsp; Useful things are 'help'&nbsp;
'status', 'ss' (for status, short), and 'evinfo'.&nbsp; Status should
tell you things about how many bundles are queued for transmission where,
and the current state of intermittent contacts.&nbsp; (I haven't cleaned
out the help command since the very early days of debugging and
hand-generation of bundles.&nbsp; Anything there that pertains to
manually generating bundles and forcing them down the daemon's throat is
probably non-functional and will disappear in the next 
release).<br><br>
Start the rcvBundle application on the destination (same host as the
destination bundleAgent).&nbsp; Tell it that the bundleAgent is
localhost, and give it the region of the receiving interface (i.e. if you
start rcvBundle on the mars gateway and will be receiving bundles from
earth, say 'ipn.sol' here).&nbsp; Give it the hostname of the receiving
interface (e.g. mars.ipn.sol).&nbsp; Finally, the 'Demux key' is the
moral equivalent of a port number, allowing the bundle daemon to
demultiplex bundles to applications.&nbsp; Pick something (you'll need to
supply it at the sender as well).&nbsp; Remember to click
'Register'.&nbsp; Deregistration doesn't entirely work yet, so if you
quit the bundle daemon on the destination host and restart it (or click
Register again to attempt to deregister), you'll have to restart
rcvBundle.<br><br>
If you prefer the console async_rcvr application (in the AsyncRcvr
directory), it can be invoked with<br>
<font color="#0000FF">./async_rcvr -b localhost -s demux</font>&nbsp;
(the console app uses the default region and hostname; that's why it
takes fewer parameters than the gui app -- need to fix this).<br><br>
On the sending host, cd to the SndBundle2 directory and source a
bundle:<br>
<font color="#0000FF">./snd_bundle -R DEST_REGION -A DEST_HOST/DEMUX_KEY
-s 2 -f /etc/motd -e 100 -n 1<br><br>
</font>This sends a bundle to region DEST_REGION, host DEST_HOST and to
the application that registered with the DEMUX_KEY.&nbsp; '-s 2' means
send a file, -f FILENAME is pretty obvious, bundle expires in 100 seconds
and do this once (-n 1).<br><br>
Note that if you picked Mars as your destination and Earth as your
source, the bundle may not show up immediately (it may be waiting for the
intermittent contact to come back).&nbsp; Typing 'status' repeatedly at
the source bundle daemon will tell you when the contact starts (see
output below).&nbsp; Alternately you can use the gdtnperf application to
graphically display the queue size and connectivity to a particular
destination:<br><br>
run the gdtnperf application at the sending side of an INTERMITTENT
contact.&nbsp; In the Preferences dialog, tell it that you want to
communcate with the bundleAgent on localhost, with the next hop
destination the other end of the INTERMITTENT contact (using Earth -&gt;
Mars example, the nextHopDestination would be ipn.sol,
mars.ipn.sol).&nbsp; It only understands UDP connections for now, and
doens't like setting the delay between samples to under ~250ms.&nbsp; The
most useful configuration for the dials is to have 'DTN Contact' and
maybe 'Connect Retries' shown.&nbsp; The 'DTN Contact' dial shows
information about connectivity (and is only really interesting for
intermittent contacts).&nbsp; When the dial is in the red, there's not
contact, when its in the green, the contact is available.&nbsp; The
'Buffer Queue' meter shows how many bundles are queued for the
destination.<br><br>
<br><br>
<br>
Sample 'status' output at source bundle daemon (comments in gray):
<dl>
<dd><font color="#FF0000">bundle_daemon&gt;
</font><font color="#0000FF">status</font>
<dd><font color="#FF0000">***** Bundle Daemon Internal Dump ***** <br>
<br>

<dd>DEBUG level: 0
<dd>Convergence Layers
<dd>&nbsp; [ 1] TCP Convergence Layer
<dd>BRG Lists:
<dd>&nbsp; Unassigned BRGs:<br>

<dd>&nbsp; Retained BRGs:<br><br>

<dd>CLISTINFOs:
<dd>&nbsp;</font><font color="#808080"> We currently have 1 contact list
structure, don't know why the NextHopRegion isn't printing, suspect
premature excision of a printf(), next hop destination is ipn2.sol.int,
yadda, yadda, yadda.&nbsp; This is an INTERMITTENT contact that is
currently inactive (CLOSED) and it will become available in 9 seconds
(FUTURE -9)</font>
<dd><font color="#FF0000">&nbsp; Other CLISTINFOS (0x080E4200):
<dd>&nbsp;&nbsp;&nbsp; CLISTINFO:&nbsp;
0x080E0E80&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
NextHopRegion:&nbsp;&nbsp; 
<dd>&nbsp;&nbsp;&nbsp; NextHopDestination:&nbsp; ipn2.sol.int
<dd>&nbsp;&nbsp;&nbsp; BytesOnList: 0&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
BytesRemaining: 0&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
HighPriorityBytesRemaining: 0
<dd>ContactType: INTERMITTENT&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; State:
CLOSED&nbsp;&nbsp; Retries: 6
<dd>&nbsp;&nbsp;&nbsp; Start (1049911399, 0) (Wed Apr&nbsp; 9 14:03:19
2003)&nbsp; [FUTURE -9]
<dd>&nbsp;&nbsp;&nbsp; Start_var:
0&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Duration: 10
<dd>Duration_var: 0 Volume:
10000000&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Volume_var: 0
<dd>&nbsp;&nbsp;&nbsp; BundleInterface: 0x08079FC8
<dd>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; localRegionName:&nbsp;&nbsp;&nbsp;
(MITRE1, ipn1.sol.int)
<dd>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; argstr: 15
<dd>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; transportNumber:&nbsp;&nbsp; 1
<dd>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
direct:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
0
<dd>&nbsp;&nbsp;&nbsp; Bundles (BRG:(nil)):</font>
<dd><font color="#808080">If there were bundles queued for this contact,
they'd be listed here.<br>
<br><br>
</font>
<dd><font color="#FF0000">Routing Table Info:<br>

<dd>(0x080772a0 . : (, ) : ONDEMAND parent(0x00000000)
<dd>&nbsp; (0x080b1ea8 MITRE2 : (MITRE2, ipn3_mitre2.sol.int) : ONDEMAND
parent(0x080772a0)
<dd>&nbsp; (0x080b21e0 internet : (internet,
playground.intel-research.net) : ONDEMAND parent(0x080772a0)
<dd>&nbsp; (0x080d78d0 MITRE1 : (MITRE1, ipn2.sol.int) : INTERMITENT
parent(0x080772a0)<br><br>

<dd>MIB Info<br><br>

<dd>mib.bundlesReceived
=&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
0
<dd>mib.bundlesSuccessfullyTransmitted = 3
<dd>mib.bundlesSuccessfullyDelivered =&nbsp;&nbsp; 0<br><br>

<dd>mib.bundlesExpired
=&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
0
<dd>mib.bundlesSourced
=&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
0<br>

<dd>Bundle Database:
<dd>&nbsp;&nbsp;&nbsp;&nbsp; Bundle database contains 0 bundles.<br>
<br>

<dd>Registration Database:
<dd>&nbsp;&nbsp;&nbsp;&nbsp; Database contains no Registrations<br>
<br><br>

<dd>Demux Database:
<dd>&nbsp;&nbsp;&nbsp;&nbsp; Demux database contains 0 entries.<br>
<br><br></font><blockquote type=cite class=cite cite>
</dl>Ta,<br>
Stephen.<br><br>
_______________________________________________<br>
dtn-interest mailing list<br>
[email-masked]<br>
<a href="http://mailman.dtnrg.org/mailman/listinfo/dtn-interest" eudora="autourl">http://mailman.dtnrg.org/mailman/listinfo/dtn-interest</a><br>
</blockquote></body>
<br>
</html>

--=====================_9621915==.ALT--

Date: Wed, 09 Apr 2003 16:02:19 +0100
From: Stephen Farrell <[email-masked]>
To: [email-masked], Kevin Fall <[email-masked]>
Subject: [dtn-interest] testing...
Sender: [email-masked]

I've now built the DTN code for cygwin (I sent Kevin the diffs, let me
know if you want 'em), and would like a bit more guidance on checking
its working.

So, two things:-

1. Could someone who knows how, create a set of configuration files
that matches the "IPN example" draft recently published? (Its hard to
tell how to interpret the sample configurations in the release, and they
don't seem to quite match up, e.g. "/etc/bundles/route" mentions
MITRE1 which isn't in "/etc/bundles/bundleNode.conf". Ideally,
those config files would let me run the entire "solar system" on a single
host.

2. Any chance of a blow-by-blow guide to what to do once you
(may:-) have a working build? I realise that its only the first release,
and I'm asking for a lot, but even an outline would be useful.

Ta,
Stephen.

Date: Wed, 02 Apr 2003 16:24:23 +0100
From: Stephen Farrell <[email-masked]>
To: Kevin Fall <[email-masked]>
Cc: [email-masked]
Subject: Re: [dtn-interest] Announcement of DTN Architecture Review
Sender: [email-masked]

This is a multi-part message in MIME format.
--------------020802040209000209050609
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

All,

In a vain attempt to also get a lunch ticket from Kevin, I've gone 
through the protocol document as well and my comments are attached:-)

My overall comments are that its clearly early days for this document,
and that I dislike the style of how some things are done (esp length
field handling), but that's arguably a matter more of style than
substance. In any case, and as usual, don't take this as being too
negative, its not meant that way.

Stephen.

--------------020802040209000209050609
Content-Type: text/html;
 name="prot-issues.html"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
 filename="prot-issues.html"

<?xml version="1.0" encoding="iso-8859-1"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN"
      "http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
  <title>No title</title>
  <meta name="generator" content="amaya 7.0, see http://www.w3.org/Amaya/" />
</head>

<body>
<p>In the comments below I mostly ignore my earlier comments on the
architecture. I've noted comments as they came up so in some cases a fix is
simply to forward reference something or move some tex (I hope that'll be
clear to the authors!). </p>

<p>Issues</p>
<ol>
  <li>The introduction says that the document "does not address" a
    bundle-agent to convergence layer API, but then goes on to define an
    abstract service for just that layer (e.g. 2.4.7 talks about the
    "location in memory" which is an API issue, and not a protocol issue).
    That left me confused. I'd suggest rewording, or deleting this (and
    creating a new document containing basically section 2). A separate
    document with a concrete 'C' or Java API might also be useful (I've yet
    to check the source distribution, so maybe that's there.)</li>
  <li>Section 2.4.5 allows one to request confidentiality which was not
    mentioned as a security service in the architecture. Also given that
    every other security protocols (e.g. IPsec, TLS) has algorithm specific
    parameters, I'm not sure how one bit ("confidcentiality") is sufficient
    (but maybe I'm misreading things).</li>
  <li>I think some text in 2.4.6 is wrong or misleading. The TTL is not the
    time from the "initial transmission" (which may take a while for a 1MB
    bundle over a 20bps link and is therefore not an instant:-), but the time
    from the "creation timestamp". Similarly the text about the "sum of"
    needs the same change.</li>
  <li>Section 2.4.7 seems to assume a synchronous API for application data.
    I'd argue that an API ought to allow for asynchronous operation which
    would mean defining some "continue" mechanism for all service primitives
    that take application data as input. The example calling for this would
    be where data arrives to the application via some smallish buffer and is
    then sent into the bundling layer without ever being fully assembled in
    the application's process space. This is how mail MTAs work and seems
    sensible for this environment too. (Perhaps this is actually intended for
    the implementation, but if so, that's not clear from the text.) Note -
    I'm not talking about bundle fragmentation here.</li>
  <li>Section 2.5.6 doesn't appear to tell the application who secured (e.g.
    signed) the bundle last. Is that deliberate?</li>
  <li>I don't see the reason to send the "0x02" byte indicating the prescence
    of the VLIP, which is stated to be mandatory. Maybe there is one, but
    it'd be better stated.</li>
  <li>The diagrams of the various header types would be much better located
    close to the text describing them. As it is currently presented a lot of
    back/forward scrolling is required to read this part. The diagrams should
    also have figure numbers for ease of reference.</li>
  <li>Similarly the protocol spec would be much improved if say ABNF or some
    other asbtract notation (ASN.1, XML whatever) were used to describe the
    messages. Experience seems to have shown that that leads to better specs
    (though clearly you have to take care not to go overboard with such
    tools).</li>
  <li>The "primary bundle header" diagram indicates that destination, source
    etc are in the primary bundle, but so does the VLIP part. Which is it? If
    the former, doesn't that make the primary bundle variable length? If the
    latter, what's in the primary bundle header?</li>
  <li>What's an 8-byte timestamp got in it?</li>
  <li>If expiration time is half as long then don't you mean its a TTL in
    seconds as previously stated (and then the field name is wrong as
    currently given).</li>
  <li>Section 3.1, 2nd para - Where is it further explained what the cos' 16
    bits represent?</li>
  <li>3.2, 2nd para: "The representation of a tuple contains a 1-byte length
    subfield indicating the total length of the tuple, including the length
    subfield, followed by the routing and administrative parts of the tuple."
    AAAARRRRGH!!! A one byte field length for names is just plain wrong -
    e.g. I may choose to name an instance using a public key (see HIP) or
    other long name (some decorated J2EE object instance or something; a URL
    may inlclude a pathname that's 255 bytes long already). I also totally
    dislike the way this is described and how its structured (lengths inside
    lengths, to-be-parsed and not-to-be-parsed data with a single tag etc.).
    Was this the deliberate mistake to check if we'd really read the
    document? :-)</li>
  <li>Ok so it turns out that the "destination" field in the primary header
    is the offset of the destination tuple further down. Firstly, its bad to
    have two different fields with the same name, so change this one to
    "destoff" or somesuch. Second, and here I have to really try hard to stop
    myself YELLING (oops:-), you cannot have one byte values for all of these
    since that means that all names catenated together have to be &lt;256
    bytes in total which is just silly.</li>
  <li>How can the source and destination tuples be the same? When'd that
    happen? If its just to support debugging then repeating the data would be
    ok and so that'd be a kind of false optimisation.</li>
  <li>The reply-to tuple was earlier marked as mandatory, but now you say
    that it can be at the same offset as the source. That's a long way to say
    that its optional then right? I'd argue to do something else (say use
    0x00 to mean "missing") since the current scheme is IMO more likely to
    result in bugs (since code that assumed a strictly increasing set of
    offsets would get confused).</li>
  <li>The CoS bits. Again I don't like the idea of these being hardcoded like
    this. What might work would be to have a "CoS scheme" byte where a value
    of '0x00' indicates this scheme and further schemes could be added
  later.</li>
  <li>The authentication and type byte is totally broken. 1) RSA is the most
    common asymmetric singing algorithm in the world and is missing 2)
    DES-MAC seems to refer to a 56-bit algorithm which has been broken via
    exhaustive search 3) HMAC and AES based symmetric integrity protection
    are much better options. I think this whole scheme needs a bit more
    thought since the way the headers are defined I can see problems with
    end-to-end signing coming up (e.g. when a custodian changes none of the
    bits input to end-to-end signing/MACing can have changed)</li>
  <li>The creation time description should include some reference to NTP
    (rfc1305).</li>
  <li>The expiration time is not what its called. Its a TTL and better called
    that.</li>
  <li>The text says that bundles "may" be discarded when
    now&gt;creation+expiration. Firstly that would be better as a "MAY" and
    then a SHOULD ought be included after some locally configured window
    following the instant when now=creation+expiration, which'd be like
    "SHOULD delete when now=creation+expiration+locally-configured-window".
    That'd allow clocks to be more loosely coupled which is a good thing for
    overall robustness.</li>
  <li>Similar point - creation time includes fractional seconds, presumably
    those are dropped when adding the TTL (which has no fractional seconds)
    and the bundle can be deleted after the end of the second:
    "floor(creationTime)+TTL" and not at the start of that second. A DTN
    which has fast routers, but infrequent contacts might otherwise see some
    weird effects.</li>
  <li>Section 3.3.2 - ok now we find out how the offsets really work. Better
    not to do this at all., but if you are then include an explaination of
    what 0x00 means in the definition of the field itself.</li>
  <li>"If the sum of the dest, source, and reply-to tuples is too long for
    the total length field of the variable-length Immutable Portion header
    then the tuples are split into multiple VLIPHes." That's IMO way over
    complex for no real benefit. Just use 16 bit length fields!</li>
  <li>Status flags. I prefer the style of error code used by HTTP etc. of
    "200" etc which allows for easy defition of more specialised codes later
    on. Almost a nit though.</li>
  <li>The order of fields in the bundle status report seems strange - given
    that you've just told me what a bundleId is now you have it at the start
    and end of a PDU with optional stuff before and in between.</li>
  <li>An overall payload size of 4GB (2^32 bytes) seems to me to be already
    at the limit of what I think I might want to send. That's about 1 DVD's
    worth of data and I can nearly imagine wanting to send that much
    information in one go. I'm not sure what size of jumbogram is possible
    with say IPv6, but maybe matching that max is a good idea?</li>
  <li>Section 3.7. You need to be clear as to whether or not implementing
    this multiplexing is a MUST, SHOULD or MAY both for the forwarding and
    receiving routers, origin and destination. Personallly I'd go for MUST
    both ways for routers and MAY multiplex for sources and NOT REQUIRED to
    de-multiplex for destinations.</li>
  <li>The "immutable" part of the header and payload is referred to in 3.8
    but not defined. There is no way to know what hash algorithm to use (or
    has been used).</li>
  <li>A question: Given that AH is largely useless why not simply define a
    way to use ESP for bundles? I think it ought to work and it'd answer all
    security mechanisms issues other than key management.</li>
  <li>Section 3.9 (sensibly) does not allow for source=destination which was
    allowed earlier. Why the change? Also the description related to reply-to
    seems inconsistent with what went earlier "...then the reply-to offset
    may be the same as the source offset.  In this case the length of the
    reply-to tuple in the variable-length Immutable Portion header (described
    3.3.2.1) will be 1 (i.e. the length will include only the 1-byte length
    and no tuple)."</li>
  <li>Section 3.9 involves "backwards" calculation of offsets. Again this is
    just plain clunky - why not just let all tuple length related values be
    16 bit from the start? Also, you need to qualify the term "from the
    beginning of the primary bundle header" for cases with multiplexing -
    which primary bundle header is involved then?</li>
  <li>3.10 refers to an "authorization header" which I assume is a typo?</li>
  <li>3.10 seems to require positioning the authentication header before the
    payload. That's a bad idea since it prevents certain buffer-bound
    applications from working (all the payload has to be in memory prior to
    calculation of the authentication values). Better is to include payload
    security options (e.g. the missing digest alg) at the start and values
    (e.g. the sig) at the end, after the payload. That's what ESP and TLS and
    CMS all do.</li>
  <li>Section 4.2 step 1 is what's usually done with networking. However,
    there is a case (certainly for an IPN) to be made for allowing an option
    to continue forwarding a bundle even if its authentication data is
    missing or wrong. I'd argue that that ought to be allowed as an option
    but perhaps strongly RECOMMENDED against unless you have detailed
    knowledge of the application.</li>
  <li>Section 4.2 - is step 2 not a bit premature? Can you always generate
    the status report (whose usefulness I'd question anyway) at this point?
    (E.g. time of forwarding won't be known yet.)</li>
  <li>Step 3a needs yet another timeout specified for when a fragment doesn't
    turn up. Or do you mean to discard everything if any fragments expiration
    time is reached? (Seems a bit strict for some DTNs.)</li>
  <li>Step 4a repeats the definition of bundle expiry and hence needs the
    same fixes (if any) as described above (floor etc.)</li>
  <li>And while I'm on that: if a bundle is due to expire at time t, and I (a
    router) have a next scheduled contact eith the next hop for that
    destination at time t-delta, and transmitting the bundle will require
    more than delta seconds then should I transmit or delete? Should I only
    transmit if the next hop is the destination? Seems like there're a few
    unknowns there.</li>
  <li>How are bundle status report storms prevented? Maybe I just missed the
    text but presumably status reports don't usually cause generation of
    further status reports. Are there any cases where they do (say if the
    authentication header for a startus report is bad).</li>
  <li>Fragments can result in multiple status reports. A source (and
    custodians) should be warned about that.</li>
  <li>Can only a custodian decide to fragment a bundle? If not, then how does
    a custodian know that all fragments (created elsewhere) have safely
    reached custody (again elsewhere) and safely release the storage?</li>
  <li>Security considerations text says that agents always sign. That should
    be included in the algorithm in section 4 somewhere.</li>
</ol>

<p>Nits</p>
<ol>
  <li>Some garbage characters at the start of 2.1 and at the end of p22</li>
  <li>Surprising few nits really :-)</li>
</ol>
</body>
</html>

--------------020802040209000209050609--

Date: Wed, 02 Apr 2003 13:11:48 +0100
From: Stephen Farrell <[email-masked]>
To: Kevin Fall <[email-masked]>
Cc: [email-masked]
Subject: Re: [dtn-interest] Announcement of DTN Architecture Review
Sender: [email-masked]

This is a multi-part message in MIME format.
--------------070100050101040705010601
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Hi Kevin,

The attached is my claim for an entry ticket:-) I've only
reviewed the architecture paper so far, but will try to get
to the others prior to the meeting. (And btw - no doubt the
comments will read as being negative, but that's just the
nature of commenting someone's document - I think this
version is a quite bit better than the last, and heading
in the right direction.)

I'd also be interested in presenting our SeNDT project [1]
if time permits on the day.

Stephen.

[1] http://down.dsg.cs.tcd.ie/sendt/ (but there's not that
much there for now - check back in a week or two and more
should be visible)

--------------070100050101040705010601
Content-Type: text/html;
 name="arch-issues.html"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
 filename="arch-issues.html"

<?xml version="1.0" encoding="iso-8859-1"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN"
      "http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
  <title>No title</title>
  <meta name="generator" content="amaya 7.0, see http://www.w3.org/Amaya/" />
</head>

<body>
<ol>
  <li>If DTN's generally require schedules then the DTN architecture should
    leave space for a protocol which can be used to distribute or update
    schedules (in a delay tolerant manner of course!). One could generalise
    further and argue that the architecture should also include (at the same
    level of detail) provision for bundle stack software/firmware upgrades.
    From (at least) the security point of view, omission of such protocols
    has often resulted in creation of vulnerabilities when the system is
    deployed (because people need to define their own mechanisms and often
    don't do that with security in mind).</li>
  <li>Specific priority and class of service values might not be best defined
    in the architecture document (they're fine as examples) since at this
    level how can we know that those are the right values?</li>
  <li>Section 3.2 lists three "pre-conditions" for DTN. I think that this
    architecture may have more and I really like the idea of trying to make
    them explicit. Possible candidates to consider adding might include: 
    <ul>
      <li>The network must support some form of synchronised scheduling,
        possibly based on loosely coupled real time clocks</li>
      <li>The network (when operating normally) must allow for the eventual
        return of ACKs to indicate acceptance of custody, (and thus free up
        storage), though possibly with significant delay (perhaps an order of
        magnitude more than is required for a bundle to get from source to
        sink) and such that ACKs may be higly likely to travel via completely
        different routes from the original bundles.</li>
    </ul>
  </li>
  <li>What application requires return receipts that cannot implement that
    functionality by using the bundle layer? If none, then why're they here?
    (I'm against receipts for the probably quite bad reason that I
    experienced the difficulties caused by mixing X.400 receipts and X.400
    security!)</li>
  <li>Security. I remain concerned that security requirements are not
    explicitly listed. We really ought to try do that to ensure that the
    right security mechanisms &amp; services are available where they're
    needed. For example, assuming we do require bundle integrity, do we also
    require fragment integrity when an integrity protected bundle is
    fragmented? If we do, then is it ok for that integrity to be provided
    hop-by-hop or must the bundle originator have precalculated values to
    cater for possibly fragmentation? (Note: this could be done e.g. if a
    single signature is calculated over a set of digests and sent with along
    each fragment - that'd allow the recipient of any fragment to check
    integrity back to the signer.)</li>
  <li>Region names are like DNS names and are used for routing. Real region
    names are therefore strictly hierarchical and (more or less) centrally
    controlled. Would there be value in including an optional MAC or
    signature in (or with) the region name itself so that inventing a fake
    region name is hard and therefore making some DTN DoS problems go away?
    I'm not sure myself, but I can imagine that there are some DTNs which'd
    like to be able to enforce strict ingress/transit controls.</li>
  <li>How would you represent a multicast group or mailing list name as the
    entity part of a DTN node name? Is that allowed? If not, why not? If so,
    what happens to node name uniqueness?</li>
  <li>I really like the idea of classifying contacts. I'd like to think about
    whether a probability of success should be an inherent part of a contact
    or whether scheduled contacts only need that kind of information. I
    believe though that supporting this as a non-error case is worthwhile -
    in our case we have a sensor network which is occasionally passed by a
    DTN gateway (probably on a boat). We know that the boat's schedule is
    such that it'll always pass around midday, but we don't know which
  days.</li>
  <li>Fragmentation - I like the idea of the reactive fragmentation, however,
    there are two possible issues 1) if data is enciphered and you loose the
    wrong bits then the left over bits are useless, so we'd either have to
    pick ciphersuites which don't allow this to happen or else include some
    "crypto re-synch" data occasionally, and 2) due to the nature of the
    application, a reactively fragmented set of bits may be useless, but may
    consume resources on the way to the destination so that bundles should be
    (maybe they are?) marked as "can be fragmented" or else (for a finer
    grained control) might include some internal markers at places where
    fragmentation is allowed.</li>
  <li>Section 3.10 introduces (v. breifly!) "end-to-end acknowledgements". Is
    that the same as receipts? If not, you'd better spell out the differences
    since that's exactly what caused some crapology in X.400
    (delivery/non-delivery reports vs. receipts). One part of the crapology
    was that the recipient of those couldn't know which was the correct
    keying material for the receipt/report originator (since e.g. a
    non-delivery report came from an MTA and although it could be digitally
    signed, the recipient had no way to know that that particular MTA was the
    right one to generate such a report; the result: forging non delivery
    reports was trivial;-). We need to (and can) avoid such problems.</li>
  <li>"Routing based on schedules and dependent upon coordination of shared
    assets (such as directional antennas) creates a requirement for time
    synchronization to achieve contact rendezvous." That is not true and, for
    some DTNs, imposes an impossible requirement! First, one can synchronize
    without real-time clocks - say if an initial contact is opportunistic and
    allows for a regular beacon to be established (as in 802.11, but at lower
    than 100ms frequency), then a future schedule has been established.
    Secondly, there will be DTN nodes which simply do not have any source of
    real time. For example, its a bit silly, but true, that GSM handsets in
    general cannot be assumed to know the time. I can imagine many DTNs that
    might wish to make use of SMS so this is a real use case. (Even more
    concretely, we're planning some equipment in which we hope to be able to
    include a GPS chipset, but we might have to drop that due to power/cost,
    in which case, our real time clock source is gone!). I think building in
    a dependency on synchronized real time clocks is nothing less than a
    major bug. (Ok, a final example, when I was working on SESAME, we adopted
    Kerberos for authentication, and while that was fine within an
    enterprise, out-of-window errors on Kerberos tickets was by far the most
    common problem we saw when we tried to deploy SESAME for any "extranet"
    or consumer style application.)</li>
  <li>Congestion. Arriving at concensus here will require evidence from
    simulations I guess. I'm planning to do that, probably over the summer.
    Be interesting in hearing from anyone else with similar ideas.</li>
  <li>Congestion again. As well as long signal propogation times, it may be
    worthwhile noting that flow-controls when the reverse path is never the
    forward path might also be a new thing. (I'm not sure, but with TCP and
    most other cases I've seen the forward and reverse paths are
    overwhelmingly likely to be the same, and if the flow control messages
    take a different delayed path, then they might arrive just in time to
    bugger up what'd otherwise be working fine:-)</li>
  <li>3.13 - There's one paragraph about how hard security is, and then the
    next starts with "To implement the security model...". Hrmpf! Where's the
    security model?</li>
  <li>Security again. You should note that no end-to-end confidentiality
    service is currently defined. (At least all the text here is about origin
    authentication.)</li>
  <li>Security state (4.4) Perhaps this is the place to note that a
    DTN-friendly solution to the revocation problem would involve some state
    and that we don't currently have such a solution (other than CRLs within
    a "globally known" PKI topology, which are both undesirables!). There
    will also be "session" keying material if/when a confidentiality service
    (or symmetric data integrity service) is defined.</li>
  <li>Bundle headers. For debugging and general logging purposes it might be
    worthwhile considering inclusion of a "Via" header with information about
    where the bundle's been. (Also - how do you spot reouting loops without
    that? Or do we just depend on the TTL? If the latter, then we'd better
    tell routers to include ingress controls on a maximum TTL, since
    otherwise we've created a nice DoS attack if there's a loop in the set of
    possible routes.)</li>
  <li>Bundle headers again. Where do I put information about e.g. schedule
    updates? Must that go in its own bundle? Just curious, but I'd have
    thought that some such information would go end-to-end on a per-bundle
    basis.</li>
</ol>

<p>Nits</p>
<ol>
  <li>In section 3.2 (near the end) it says "...*may*...". I'm not sure if
    MAY is meant, but if it is, then correct capitalisation is
  REQUIRED:-)</li>
  <li>At the end of 3.3 it implies that security is a SHOULD, again proper
    capitalisation would be better.</li>
  <li>Is it ok for the entity name part of two DTN node names to collide? I
    guess it is and so maybe saying that'd be good in case someone assumes
    global uniqueness for that.</li>
  <li>There's a weird character in the description of OnDemand contacts at
    the end of p10. Same at start of section 3.9</li>
  <li>Section 3.10 - there's that "*may*" again!</li>
  <li>Section 4.4 - there's a sentence ending in "and."</li>
  <li>Section 5 says its defining meta-data and to go elsewhere for details.
    That's a good idea, but means that you don't then tell me how many bits
    are in a field (so as not to cause problems when the protocol spec
    changes after the arch spec is an RFC!).</li>
  <li>Section 7 has a sentence ending in "...may be require."</li>
</ol>
</body>
</html>

--------------070100050101040705010601--