Subject: Re: [dtn] rfc5050(bis) proposed revisions

From: "Ivancic, William D. (GRC-RHN0)" <[email-masked]>
Date: Wed, 18 Jun 2014 13:18:26 +0000

While I appreciate Scott's work and taking time to write bpv7, I think
this list is not the place to discussion implementations and I think it is
premature to consider these implementations until a working group is or is
not formed (at which point we will know where those discussions should
occur).  For now, IMHO, implementations issues are probably best addressed
on dtn-interest.  Check the lists, there are far more subscribers on
dtn-interest the the dtn BOF list.

Will

******************************

On 6/17/14 4:20 PM, "Templin, Fred L" <[email-masked]> wrote:

>Hello,
>
>Below is a list of (proposed) revisions for rfc5050(bis) as found in
>Appendix A of 'draft-burleigh-bpv7'. Please post any comments or
>suggestions to the list.
>
>Thanks - Fred
>[email-masked]
>
>---
>
>Appendix A.                  Summary of Revisions
>
>   This specification differs from RFC-5050 in a number of ways.  The
>   revisions that seem to the author to be most significant are listed
>   below:
>
>     . Amplify the discussion of custody transfer.  Move current
>        custodian to an extension block, of which there can be multiple
>        occurrences (providing possible support for the MITRE idea of
>        multiple concurrent custodians, from several years ago); define
>        that block in this spec.
>     . Add the notion of "embargoes", i.e., what do you do when a
>        route unexpectedly goes bad for a while?  This entails adding
>        another extension block (Forwarding Anomaly) and another
>        administrative record (Reopen Signal).
>     . Incorporate the Compressed Bundle Header Encoding [RFC6260]
>        concepts into the base specification: nodes are explicitly
>        identified by node numbers, and operations that pertain to
>        nodes are described in terms of node numbers rather than
>        endpoint IDs.
>     . Add basic ("imc") multicast to the BP spec.  This entails
>        adding another administrative record, Multicast Petition.
>     . Add Destination EID extension block for destinations that can't
>        be expressed in "ipn"-scheme and "imc"-scheme URIs.  Define it
>        in this spec.
>     . Incorporate the "Extended Class of Service" features into the
>        base specification.
>     . Restructure the primary block, making it immutable.  Add CRC.
>        Remove the dictionary.
>     . Add optional Payload CRC extension block, defined in this spec.
>     . Add block ID number to canonical block format (to support
>        streamlined Bundle Security Protocol).
>     . Add bundle age extension block, defined in this spec.
>     . Define two other extension blocks in this spec: previous node
>        number, hop count.
>     . Clean up a conflict between fragmentation and custody transfer
>        that Ed Birrane pointed out.
>     . Remove "DTN time" values from administrative records.
>        Nanosecond precision will not be meaningful among nodes whose
>        clocks are not closely synchronized, and absent that feature
>        the administrative record's bundle creation time suffices to
>        indicate the time of occurrence of the reported event.
>     . Note that CL protocols are supposed to discard data that they
>        find to have been corrupted.
>
>
>_______________________________________________
>dtn mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/dtn

---

From: "Templin, Fred L" <[email-masked]>
Date: Fri, 20 Jun 2014 19:16:05 +0000

Hi Will,

> -----Original Message-----
> From: Ivancic, William D. (GRC-RHN0) [mailto:[email-masked]]
> Sent: Wednesday, June 18, 2014 6:18 AM
> To: Templin, Fred L; [email-masked]
> Subject: Re: [dtn] rfc5050(bis) proposed revisions
> 
> on dtn-interest.

I'm not sure why you say "implementations"; we are talking about
specifications - not implementations. A discussion on the list of
planned changes for RFC 5050(bis) I think is perfectly reasonable
for this distribution.

> Check the lists, there are far more subscribers on

List administrators have access to the list of subscribers and,
while I can't say more, I can tell you that the membership of
this list is not insubstantial.

Thanks - Fred

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 20 Jun 2014 20:23:05 +0100

> planned changes for RFC 5050(bis) I think is perfectly reasonable

Have to agree with Fred on the above. Better to keep
relevant discussion focussed here in the run up to the
BoF and if a proposal for a 5050bis isn't relevant then
I don't know what could be.

After the BoF we can figure if something ought be here
or there, assuming there is a "here".

> this list is not insubstantial.

I doubt that that number needs to be kept secret but in
any case... who cares? :-) The argument above wins and
size doesn't matter in this case.

S.

---

From: "Templin, Fred L" <[email-masked]>
Date: Fri, 20 Jun 2014 19:33:38 +0000

Hi Stephen,

> From: dtn [mailto:[email-masked]] On Behalf Of Stephen Farrell
> Sent: Friday, June 20, 2014 12:23 PM
> To: Templin, Fred L; Ivancic, William D. (GRC-RHN0); [email-masked]

OK; I will reboot the discussion.

Thanks - Fred

---

From: "Ivancic, William D. (GRC-RHN0)" <[email-masked]>
Date: Fri, 20 Jun 2014 20:00:12 +0000

Fred,

Implementations may not have been the best  word choice, but there is a
lot of "How"  in  bpv7.  What I meant was that Scott's propose revisions
probably do not belong on the BOF this list. It could quickly lead to
discussions of specification changes and where pieces should go which is
currently should occur on dtn-interest.  Those should IMHO occur after the
BOF, not before and not on the BOF list.   Removing dictionary.  Sort of
specifying an addressing scheme (URL usage), Hop count as extension block,
how to do bundle security, etc... are better served on dtn-interest at
this point in time.  Just my opinion.   By the way, I'm not saying these
are wrong, just that they do not belong on the BOF list.

I think the BOF list is suppose to be about
"What exactly and specifically should this group be working on if an IETF
dtn working group is formed?"
"Should IETF form a working group?",
"Are the protocols at a state where they are ready for IETF standard or is
there more work that should be done in IRTF?"
"Is there sufficient energy to get meaningful work done?"

So we should be addressing "What", not "How".

FYI:  Anyone list participant can get  information on who subscribed to an
IETF mail list if they remember their password (and you can ask for your
password to be resent). These lists are setup to be open, so the
participation list is not just available to the administrators. At least
that is my recollection and it has always worked for me.  Also, since
anyone can sign up, basically, with minimal effort, anyone can see who
subscribed to an IETF list.

If you go to dtn-interest and compare to dtn, the dtn-interest as far more
participants.

Will

>> >....

---

From: "Templin, Fred L" <[email-masked]>
Date: Fri, 20 Jun 2014 20:08:03 +0000

Hi Will,

> Sent: Friday, June 20, 2014 1:00 PM

I understand that this may be your opinion, but others have expressed
a different opinion.

> subscribed to an IETF list.

That is fine; others who are curious about list membership can follow
your instructions if they are interested.

> If you go to dtn-interest and compare to dtn, the dtn-interest as far more

And, if they look, they will see that the [email-masked] list membership
is not insubstantial.

Thanks - Fred

---

From: "Burleigh, Scott C (312G)" <[email-masked]>
Date: Fri, 20 Jun 2014 20:18:46 +0000

Will, I certainly agree that it's unlikely that any decisions on any of these proposed revisions would emerge from conversations on this list, but it seems reasonable to me at least to be open to explaining and discussing them.  Wouldn't you agree that they fall under the heading of "What exactly and specifically should this group be working on if an IETF dtn working group is formed?"  This discussion might be especially helpful for people who may be signed up to this list out of possible commercial interest, who may not be real familiar with all of the technical concepts we've been working with over the past few years.

Scott

-----Original Message-----
From: dtn [mailto:[email-masked]] On Behalf Of Ivancic, William D. (GRC-RHN0)
Sent: Friday, June 20, 2014 1:00 PM
To: Templin, Fred L; [email-masked]
Subject: Re: [dtn] rfc5050(bis) proposed revisions

Fred,

Implementations may not have been the best  word choice, but there is a lot of "How"  in  bpv7.  What I meant was that Scott's propose revisions probably do not belong on the BOF this list. It could quickly lead to discussions of specification changes and where pieces should go which is currently should occur on dtn-interest.  Those should IMHO occur after the
BOF, not before and not on the BOF list.   Removing dictionary.  Sort of
specifying an addressing scheme (URL usage), Hop count as extension block, how to do bundle security, etc... are better served on dtn-interest at
this point in time.  Just my opinion.   By the way, I'm not saying these
are wrong, just that they do not belong on the BOF list.

I think the BOF list is suppose to be about "What exactly and specifically should this group be working on if an IETF dtn working group is formed?"
"Should IETF form a working group?",
"Are the protocols at a state where they are ready for IETF standard or is there more work that should be done in IRTF?"
"Is there sufficient energy to get meaningful work done?"

FYI:  Anyone list participant can get  information on who subscribed to an IETF mail list if they remember their password (and you can ask for your password to be resent). These lists are setup to be open, so the participation list is not just available to the administrators. At least that is my recollection and it has always worked for me.  Also, since anyone can sign up, basically, with minimal effort, anyone can see who subscribed to an IETF list.

If you go to dtn-interest and compare to dtn, the dtn-interest as far more participants.

Will

>> While I appreciate Scott's work and taking time to write bpv7, I 
>>think  this list is not the place to discussion implementations and I 
>>think it is  premature to consider these implementations until a 
>>working group is or is  not formed (at which point we will know where 
>>those discussions should  occur).  For now, IMHO, implementations 
>>issues are probably best addressed  on dtn-interest.
>
>planned changes for RFC 5050(bis) I think is perfectly reasonable for 
>this distribution.
>
>> Check the lists, there are far more subscribers on dtn-interest the 
>> the dtn BOF list.
>
>List administrators have access to the list of subscribers and, while I 
>can't say more, I can tell you that the membership of this list is not 
>insubstantial.
>
>Thanks - Fred

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 20 Jun 2014 21:58:33 +0100

Hi Will,

On 20/06/14 21:00, Ivancic, William D. (GRC-RHN0) wrote:
> What I meant was that Scott's propose revisions
> probably do not belong on the BOF this list.

Gotta disagree with you again there. If discussion of
the specific technology proposal were not allowed that'd
be fairly mad.

Discussion of whether to do it etc. is of course also
needed and has been happening.

S.

---

From: Elwyn Davies <[email-masked]>
Date: Fri, 20 Jun 2014 22:25:55 +0100

> [email-masked]

FYI

There are currently 81 subscribers on dtn vs about 1100 on dtn-interest.

All list subscribers can check the rosters.
https://www.ietf.org/mailman/listinfo/dtn(-interest)

using the password in your monthly reminder email if you can't remember.

/Elwyn

---

From: "Templin, Fred L" <[email-masked]>
Date: Fri, 20 Jun 2014 21:57:40 +0000

> From: Elwyn Davies [mailto:[email-masked]]
> Sent: Friday, June 20, 2014 2:26 PM
> To: Templin, Fred L
> Cc: Ivancic, William D. (GRC-RHN0); [email-masked]
> Subject: List roster counts [was: Re: [dtn] rfc5050(bis) proposed revisions]
> 
> 
> >

Before anyone thinks I was trying to hide something, let me just
clarify that I did not know this information was available to
general users. I was being clueless - not devious. So, thanks
to Elwyn for explaining this option that is available to all
subscribers.

So, Will is right that there are many more members on dtn-interest
than dtn. And, I am also right that 81 is not an insubstantial
number. And, Stephen is also right that numbers don't matter.

Thanks - Fred