Subject: [dtn] a version of the charter

From: Marc Blanchet <[email-masked]>
Date: Thu, 4 Sep 2014 21:56:55 -0400

Hello,
 I like short, to the point, text, protocol specs and charters. So, please consider below as an individual contribution for a charter. As you will see, shortened version. ;-)

Marc.

==============================
Working group name: 

     Delay/Disruption Tolerant Networking Working Group (DTNWG)

Chair(s):

     TBD

Area and Area Director(s):

     Transport Area: ADs Spencer Dawkins <spencerdawkins.ietf at gmail.com>,
                         Martin Stiemerling <mls.ietf at gmail.com>

Responsible Area Director:

     Martin Stiemerling <mls.ietf at gmail.com>

Mailing list:

     General Discussion: dtn at ietf.org
     To Subscribe: https://www.ietf.org/mailman/listinfo/dtn
     Archive: http://www.ietf.org/mail-archive/web/dtn/current/maillist.html

Description of Working Group:

     The Delay/Disruption Tolerant Network Working Group (DTNWG) specifies
     mechanisms for data communications in the presence of long delays
     and/or intermittent connectivity. Delay-Tolerant Networking (DTN) 
     protocols have been the subject of
     extensive research and development in the Delay-Tolerant Networking
     Research Group (DTNRG) of the Internet Research Task Force since 2002.
     The key documents are the « DTN Architecture » (RFC 4838), the 
     Bundle Protocol (RFC 5050), Licklider Transmission Protocol (RFC 5326)
     and convergence layers (RFC 7122, 7242). Multiple independent implementations
     exist for these technologies and multiple deployments in space and terrestrial
     environments. There is an increase interest in the commercial world for these 
     technologies, for similar and different use cases, such as unmanned air vehicles.
     In this context, there is a need to update the base specifications based on the 
     deployment and implementation experience as well as the new use cases. Moreover,
     there is also a need to have standards track documents for the market. 

     Therefore, the purpose of the working group is to document the new use cases and 
     requirements and to update the base specifications. The group shall not endeavour to
     change the underlying architecture or the bundle protocol principle.

     Work items are:

     o An informational « DTN Problem Statement, Use Cases and Requirements"
       document

     o Updates to RFC5050, convergence layer RFCs, security(RFC6257), as standard track documents.

     o A registry for DTN Service Identifiers

     Work such as routing, neighbor/contact discovery, security key management, 
     network management, bundle-in-bundle encapsulation and reliable bundle delivery
     are currently out of scope.

     Before the updates of the protocol specifications are endeavoured, the Problem statement should
     be agreed within the working group and with the IESG, specially on what the updates will be. 

Goals and Milestones:

TBD

---

From: "Ivancic, William D. (GRC-LCA0)" <[email-masked]>
Date: Fri, 5 Sep 2014 12:58:09 +0000

I like this much better.

I would like to see lessons learned documented.  I think that could be a
section in the use case or a separate short document.  I think it would be
useful to ensure we don't make the same mistakes twice or ignore a
documented problem.

Suggest:
An informational « DTN Problem Statement, Use Cases and Requirements"
       Document that includes a lessons learned section.

Will

On 9/4/14 9:56 PM, "Marc Blanchet" <[email-masked]> wrote:

>An informational « DTN Problem Statement, Use Cases and Requirements"
>       document

---

From: "Templin, Fred L" <[email-masked]>
Date: Fri, 5 Sep 2014 14:50:30 +0000

Hi Marc,

I'm not sure why you are suggesting to trim the "Goals and
Milestones" section. Can you say more about your reasoning
for that?

Thanks - Fred
[email-masked]

> -----Original Message-----
> From: dtn [mailto:[email-masked]] On Behalf Of Marc Blanchet
> Sent: Thursday, September 04, 2014 6:57 PM
> To: [email-masked]
> Cc: Martin Stiemerling
> Subject: [dtn] a version of the charter
> 
> Hello,
>  I like short, to the point, text, protocol specs and charters. So, please consider below as an
> individual contribution for a charter. As you will see, shortened version. ;-)
> 
> Marc.
> 
>      The key documents are the < DTN Architecture > (RFC 4838), the
>      o An informational < DTN Problem Statement, Use Cases and Requirements"
>        document
> 
> _______________________________________________
> dtn mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dtn

---

From: Marc Blanchet <[email-masked]>
Date: Fri, 5 Sep 2014 12:44:39 -0400

Le 2014-09-05 à 10:50, Templin, Fred L <[email-masked]> a écrit :

> Milestones" section.

no intent. I wrote "TBD" below. i.e. milestones to me are just an outcome of the above. So milestones would be just the work items with dates.

Regards, Marc.

> Can you say more about your reasoning
> for that?
> 
> Thanks - Fred

---

From: "Templin, Fred L" <[email-masked]>
Date: Fri, 5 Sep 2014 16:52:57 +0000

Hi Marc,

> Sent: Friday, September 05, 2014 9:45 AM
> To: Templin, Fred L
> Cc: Martin Stiemerling; [email-masked]
> Subject: Re: [dtn] a version of the charter
> 
> 

OK. Then, would you mind re-issuing your proposal with milestones
and dates included? I would then be able to comment further.

Thanks - Fred

---

From: Brian Haberman <[email-masked]>
Date: Fri, 05 Sep 2014 17:58:56 -0400

Hi Fred,

> and dates included? I would then be able to comment further.

Just as a process note... The charter and the milestones are two
separate items.

The charter is the contract between the WG and the IESG (in proxy for
the IETF).  The contents of the charter are subject to the entire review
process.

The milestones are not part of the review process.  The milestones are
an agreement between the WG and the shepherding AD.  So, Marc removing
the milestones is completely reasonable at this point so that the focus
is on the charter text.

Regards,
Brian

---

From: "Templin, Fred L" <[email-masked]>
Date: Fri, 5 Sep 2014 22:04:32 +0000

Thanks for the clarification, Brian.

Fred

> From: dtn [mailto:[email-masked]] On Behalf Of Brian Haberman
> Sent: Friday, September 05, 2014 2:59 PM
> To: [email-masked]
> >> no intent. I wrote "TBD" below. i.e. milestones to me are just an outcome of the above. So
> milestones
> >> would be just the work items with dates.
> >

---

From: "Templin, Fred L" <[email-masked]>
Date: Fri, 5 Sep 2014 22:14:57 +0000

Hi Marc,

With Brian's clarifications, I have only two brief comments for the

> individual contribution for a charter. As you will see, shortened version. ;-)

Suggest changing to:

       "are currently out of scope, but may be aligned with the working group
        as candidate future recharter items."
>      Before the updates of the protocol specifications are endeavoured, the Problem statement should

"endeavoured" seems a bit odd here since we can't stop people from
doing advanced work if they want to. Did you mean something different?

Thanks - Fred

---

From: Marc Blanchet <[email-masked]>
Date: Fri, 5 Sep 2014 21:14:54 -0400

>        as candidate future recharter items."

There is no need for this. Later on, if the wg wants to do more work as chartered items, then we will need to take it to the AD/IESG and then convince them.
In the mean time, there is nothing preventing (and actually it is generally useful) to work on additional items, even at some point take some time of wg meetings, but as a lower priority, to discuss the other topics. However, these documents won't be wg documents until the corresponding (new) milestone is added to the charter.

> doing advanced work if they want to. Did you mean something different?

sure. my frenchy english. I was trying to say that the scope (especially given the relative high number of topics that has been discussed so far and that there is a concern of the quantity and the need) of the changes in the protocol specifications should be agreed through the problem statement draft.

In other words, I think our (good) discussion on which feature/change/addition/...  to the current key protocol specifications can not be "finished" in some finite time. I think we can debate the list "forever".  So my suggestion is to form the wg to actually discuss this through the problem statement document. Then when there is agreement on the scope of the changes, then we work on making those changes.   Of course, everybody is encouraged to work "in advance" of this "scope agreement".

That is what I was trying to convey that reasoning.

clearer?

Marc.

---

From: Stephen Farrell <[email-masked]>
Date: Sat, 06 Sep 2014 13:16:58 +0100

Hi Marc, all,

Some comments on this. To be constructive, my comments here assume
that this kind of "minimal" dtnwg is a good plan. (Even though as
you know I'd prefer something else myself.)

On 05/09/14 02:56, Marc Blanchet wrote:
> Hello, I like short, to the point, text, protocol specs and charters.
> So, please consider below as an individual contribution for a
> charter. As you will see, shortened version. ;-)
> 
> Marc.
> 
> ============================== Working group name:
> 
> Transport Area: ADs Spencer Dawkins <spencerdawkins.ietf at
> gmail.com>, Martin Stiemerling <mls.ietf at gmail.com>
> 
> General Discussion: dtn at ietf.org To Subscribe:
> https://www.ietf.org/mailman/listinfo/dtn Archive:
> http://www.ietf.org/mail-archive/web/dtn/current/maillist.html
> 
> The Delay/Disruption Tolerant Network Working Group (DTNWG)
> specifies mechanisms for data communications in the presence of long
> delays and/or intermittent connectivity. Delay-Tolerant Networking
> (DTN) protocols have been the subject of extensive research and
> development in the Delay-Tolerant Networking Research Group (DTNRG)
> of the Internet Research Task Force since 2002. The key documents are
> the « DTN Architecture » (RFC 4838), the Bundle Protocol (RFC 5050),
> Licklider Transmission Protocol (RFC 5326) and convergence layers
> (RFC 7122, 7242). Multiple independent implementations exist for
> these technologies and multiple deployments in space and terrestrial 
> environments. There is an increase interest in the commercial world
> for these technologies, for similar and different use cases, such as
> unmanned air vehicles. In this context, there is a need to update the
> base specifications based on the deployment and implementation
> experience as well as the new use cases. Moreover, there is also a
> need to have standards track documents for the market.
> 
> Therefore, the purpose of the working group is to document the new
> use cases and requirements and to update the base specifications. The
> group shall not endeavour to change the underlying architecture or
> the bundle protocol principle.

That last phrase "the bundle protocol principle" is ambiguous.
If you mean the minimal-change approach then I think saying that
is right. If not, I don't know what you mean.

In the former case I'd suggest something like "While significant
changes to RFC5050 are expected, nonetheless the WG will aim to
minimise those changes and will not undertake a wholesale
re-design of a new protocol based on the DTN architecture (RFC
4838)."

(Such a re-design is of course exactly what I'd like myself but
that's for another mail, if/when I get time:-)

> 
> Work items are:
> 
> o An informational « DTN Problem Statement, Use Cases and
> Requirements" document

I'm not clear if this is only supposed to document the "new
requirements" or both new and well known requirements. Put
another way, is this stating the requirements for changes to
5050 etc., or the requirements for all of 5050bis? That
needs to be clear before starting.

> Work such as routing, neighbor/contact discovery, security key
> management, network management,

Hmmm. I'd argue that putting the above out of scope is just
wrong. For example BCP107 calls for automated key management to
be defined for standards, with a few exceptions that I don't
think apply here. Similarly, we don't generally define stuff
that can't be managed. Isn't defining such things absolutely
what is needed if 5050bis is to be on the standards track?
What is the argument for why DTN is so different from what would
be required for any other IETF WG that not adhering to BCPs
is acceptable?

> bundle-in-bundle encapsulation and reliable bundle delivery are
> currently out of scope.
> 
> Before the updates of the protocol specifications are endeavoured,
> the Problem statement should be agreed within the working group and
> with the IESG, specially on what the updates will be.

That sometimes seems like a good plan and it can work.
I assume "agreed with the IESG" means approved by the
IESG. That then means that the WG won't adopt any 5050bis
type documents until after this one has been approved,
right? Which also implies that the WG could be shut down
if the IESG don't believe that its at all likely that
the WG can develop specs to meet the problem statement?
Just checking that that's clear.

Cheers,
S.

> Goals and Milestones:
> 
> TBD _______________________________________________ dtn mailing list 
> [email-masked] https://www.ietf.org/mailman/listinfo/dtn
> 
>

---

From: Marc Blanchet <[email-masked]>
Date: Sat, 6 Sep 2014 08:41:20 -0400

Le 2014-09-06 à 08:16, Stephen Farrell <[email-masked]> a écrit :

> 
> Hi Marc, all,
> 
> Some comments on this. To be constructive,

thank you for this approach! I prefer! ;-)

> my comments here assume
> that this kind of "minimal" dtnwg is a good plan.

yes.

> (Even though as

I know.

> is right.

that is the intent.

> If not, I don't know what you mean.
> 

I was trying to be short, to the point... I'm fine with your wording, except that it is longer...;-)

> that's for another mail, if/when I get time:-)

My take is that a re-design should be taken by the research group.

> needs to be clear before starting.

My opinion is that, on purpose, we shall not restrict here. We shall "take the time" to construct a good problem statement for where we are, and where we want to go. My feeling is that the problem statement would have two kind of tasks to be done: 1) "minimal changes to 5050 and al."  2) re-design.  The set of 1) would go to the IETF wg. The set of 2) would go to the IRTF group.

Refering to my other email, my reading of the discussion here is that we will take quite a long time to converge to the "problem statement" scope and that includes a "lot" of technical discussions. Therefore, it does not make sense to me to have this "long" discussion prior to a wg. We should form the wg, get that discussion going and then identify the remaining tasks to be done.

> be required for any other IETF WG that not adhering to BCPs

I could agree on this one. My first pass of the "shortened" version of the charter was to take the discussed one, and then edit it. So that list of "features" were not in the clear initial set, so I scope them out.  In some ways, I would even probably remove the whole paragraph, and rely on the problem statement to define what can be done "easily" (i.e. no redesign, so in this to-be-formed wg) and what requires a major "research" effort that would go into the research group.

> right?

roughly yes.  In my mind, this is the AD to decide and most likely go to IESG for at least discussion. In other words, IESG and AD to me are identical. whatever wordsmitting is fine by me.

> Which also implies that the WG could be shut down

see what I wrote above. A "larger" problem statement with two sets of outcomes: one with no redesign and one with redesign.  first being taken by IETF wg, latter by the research group.  At least, that is my initial feeling.

Then, as you wrote, if the first set of outcomes to be targetted for IETF wg work is not agreeable by the IESG, then I guess the wg will be stuck and the wg chairs and AD will discuss what is next, including shutting down. 

It would be pretty sad that a so successful IRTF group with specifications and multiple interoperable implementations come to IETF with industry requesting standard track for larger deployment and for real commercial products that the IETF at the end declines...  To me, that would be a big failure of IETF.

So my take here for the charter is to propose a positive way forward, where:
- we have a home to discuss the whole problem statement which to me will take some significant time
- we provide a home for technical work to be done for getting the industry requirements in and standard track documents
- we provide some rubber band for the IESG to have a say if the wg go too wild.

Marc.

---

From: Stephen Farrell <[email-masked]>
Date: Sat, 06 Sep 2014 13:55:46 +0100

Hiya,

More below...

On 06/09/14 13:41, Marc Blanchet wrote:
>> my comments here assume that this kind of "minimal" dtnwg is a good
>> plan.
> 
> yes.
> 
>> (Even though as you know I'd prefer something else myself.)
> 
> I know.
> 
>> 
>>> Hello, I like short, to the point, text, protocol specs and
>>> charters. So, please consider below as an individual contribution
>>> for a charter. As you will see, shortened version. ;-)
>>> 
>>> Marc.
>>> 
>>> specifies mechanisms for data communications in the presence of
>>> long delays and/or intermittent connectivity. Delay-Tolerant
>>> Networking (DTN) protocols have been the subject of extensive
>>> research and development in the Delay-Tolerant Networking
>>> Research Group (DTNRG) of the Internet Research Task Force since
>>> 2002. The key documents are the « DTN Architecture » (RFC 4838),
>>> the Bundle Protocol (RFC 5050), Licklider Transmission Protocol
>>> (RFC 5326) and convergence layers (RFC 7122, 7242). Multiple
>>> independent implementations exist for these technologies and
>>> multiple deployments in space and terrestrial environments. There
>>> is an increase interest in the commercial world for these
>>> technologies, for similar and different use cases, such as 
>>> unmanned air vehicles. In this context, there is a need to update
>>> the base specifications based on the deployment and
>>> implementation experience as well as the new use cases. Moreover,
>>> Therefore, the purpose of the working group is to document the
>>> new use cases and requirements and to update the base
>>> specifications. The group shall not endeavour to change the
>>> underlying architecture or the bundle protocol principle.
>> 
>> That last phrase "the bundle protocol principle" is ambiguous. If
>> you mean the minimal-change approach then I think saying that is
>> right.
> 
> that is the intent.
> 
>> minimise those changes and will not undertake a wholesale re-design
>> of a new protocol based on the DTN architecture (RFC 4838)."
> 

A little longer only:-) Its worth it to lose the
ambiguity though I think.

>> requirements" or both new and well known requirements. Put another
>> way, is this stating the requirements for changes to 5050 etc., or
>> the requirements for all of 5050bis? That needs to be clear before
>> starting.
> 
> My opinion is that, on purpose, we shall not restrict here. We shall
> "take the time" to construct a good problem statement for where we
> are, and where we want to go. My feeling is that the problem
> statement would have two kind of tasks to be done: 1) "minimal
> changes to 5050 and al."  2) re-design.  The set of 1) would go to
> the IETF wg. The set of 2) would go to the IRTF group.
> 
> Refering to my other email, my reading of the discussion here is that
> we will take quite a long time to converge to the "problem statement"
> scope and that includes a "lot" of technical discussions. Therefore,
> it does not make sense to me to have this "long" discussion prior to
> a wg. We should form the wg, get that discussion going and then
> identify the remaining tasks to be done.

I think we're talking at cross purposes there. Let me try
ask my question again a different way.

Would the draft-ietf-dtnwg-problem-statement draft specify
all requirements to be met by 5050bis or would it specify
requirements for the delta between 5050 and 5050bis?

There's noting in that question that requires discussion of
the DTNRG I think.

>> Hmmm. I'd argue that putting the above out of scope is just wrong.
>> For example BCP107 calls for automated key management to be defined
>> for standards, with a few exceptions that I don't think apply here.
>> Similarly, we don't generally define stuff that can't be managed.
>> Isn't defining such things absolutely what is needed if 5050bis is
>> to be on the standards track? What is the argument for why DTN is
>> so different from what would be required for any other IETF WG that
>> not adhering to BCPs is acceptable?
> 
> I could agree on this one. 

Cool. I'm not clear that that's true of everyone who wants a
dtnwg myself though.

> My first pass of the "shortened" version
> of the charter was to take the discussed one, and then edit it. So
> that list of "features" were not in the clear initial set, so I scope
> them out.  In some ways, I would even probably remove the whole
> paragraph, and rely on the problem statement to define what can be
> done "easily" (i.e. no redesign, so in this to-be-formed wg) and what
> requires a major "research" effort that would go into the research
> group.
> 
>> 
>>> Before the updates of the protocol specifications are
>>> endeavoured, the Problem statement should be agreed within the
>>> working group and with the IESG, specially on what the updates
>>> will be.
>> 
>> That sometimes seems like a good plan and it can work. I assume
>> "agreed with the IESG" means approved by the IESG. That then means
>> that the WG won't adopt any 5050bis type documents until after this
>> one has been approved, right?
> 
> roughly yes.  In my mind, this is the AD to decide and most likely go
> to IESG for at least discussion. In other words, IESG and AD to me
> are identical. whatever wordsmitting is fine by me.

IESG approval is not at all the same IMO. I think that is an
important distinction and is one where its important to be
clear starting out. If this were not clear, then we'd risk a
bunch of people investing a lot of time and effort without
them understanding the risk that their effort could end up
wasted.

> 
>> Which also implies that the WG could be shut down if the IESG don't
>> believe that its at all likely that the WG can develop specs to
>> meet the problem statement?
> 
> see what I wrote above. A "larger" problem statement with two sets of
> outcomes: one with no redesign and one with redesign.  first being
> taken by IETF wg, latter by the research group.  At least, that is my
> initial feeling.
> 
> Then, as you wrote, if the first set of outcomes to be targetted for
> IETF wg work is not agreeable by the IESG, then I guess the wg will
> be stuck and the wg chairs and AD will discuss what is next,
> including shutting down.
> 
> It would be pretty sad that a so successful IRTF group with
> specifications and multiple interoperable implementations come to
> IETF with industry requesting standard track for larger deployment
> and for real commercial products that the IETF at the end declines...
> To me, that would be a big failure of IETF.

You've said that before and I get the point and agree to an
extent. However, even WGs that seem like a really good plan do
fail sometimes, and that is not always the fault of the IETF
as a whole.

S

> 
> So my take here for the charter is to propose a positive way forward,
> where: - we have a home to discuss the whole problem statement which
> to me will take some significant time - we provide a home for
> technical work to be done for getting the industry requirements in
> and standard track documents - we provide some rubber band for the
> IESG to have a say if the wg go too wild.
> 
> Marc.
> 
>> Cheers, S.
>>> TBD _______________________________________________ dtn mailing
>>> list [email-masked] https://www.ietf.org/mailman/listinfo/dtn
> 
> 
> 
> 
> _______________________________________________ dtn mailing list

---

From: Marc Blanchet <[email-masked]>
Date: Sun, 7 Sep 2014 15:32:24 -0400

> More below...

...

> requirements for the delta between 5050 and 5050bis?

I'm not quite sure yet. ;-)  I would like us to take a larger view of what needs to be done, overall.  Then, we classify the changes/additions into two sets: 1) "minimal changes to 5050 and al." 2) larger changes.  1) would be "approved" by IESG for work to be done in dtn wg. 2) would go "somewhere else" (dtnrg?) or wait for next iteration of wg.

...

> them understanding the risk that their effort could end up

I'm fine either way.

...
> fail sometimes, and that is not always the fault of the IETF

of course. But we should give it a try (with good scope and al..)

Marc.

---

From: Stephen Farrell <[email-masked]>
Date: Sun, 07 Sep 2014 21:03:24 +0100

On 07/09/14 20:32, Marc Blanchet wrote:
>>> Would the draft-ietf-dtnwg-problem-statement draft specify all
>>> requirements to be met by 5050bis or would it specify 

> I'm not quite sure yet. ;-)  

Seems to me like the scope for that document is something to
get right starting out.

> I would like us to take a larger view of
> what needs to be done, overall.  Then, we classify the
> changes/additions into two sets: 1) "minimal changes to 5050 and al."
> 2) larger changes.  1) would be "approved" by IESG for work to be
> done in dtn wg. 2) would go "somewhere else" (dtnrg?) or wait for
> next iteration of wg.

We're still talking at cross purposes I think.

Let me try again. Which of (a) or (b) applies?

a) If draft-ietf-dtnwg-problem-statement does specify all
requirements to be met by 5050bis then it would need to say
something like "MUST allow communication in the face of
long message transit times."

b) If draft-ietf-dtnwg-problem-statement only specifies the
changes between 5050 and 5050bis, then it would not need
to contain that requirement.

If (a) applies then I think that's a bad idea.

I assume that draft-ietf-dtnwg-problem-statement would not
specify extra-super-advanced things that are not going to
be done in the WG. (Except possibly as being out of scope.)

S.

PS: As I also said before. The notion that a DTNWG and DTNRG
would co-exist both working energetically seems way too
optimistic to me. If a DTNWG starts, then IMO the DTNRG will
effectively hibernate. I know you disagree with that. But I
do think that planning for a DTNWG cannot assume that there
is a parallel active DTNRG. If that happens, great, but the
WG should not depend on it happening.

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Mon, 8 Sep 2014 05:07:34 -0500

On Friday, September 5, 2014, Brian Haberman <[email-masked]>
wrote:

> >> From: dtn [mailto:[email-masked] <javascript:;>] On Behalf Of
> Marc Blanchet
> >> Cc: Martin Stiemerling; [email-masked] <javascript:;>
> >> Le 2014-09-05 à 10:50, Templin, Fred L <[email-masked]
> <javascript:;>> a écrit :
> >>
> >>> Hi Marc,
> >>>
> >> no intent. I wrote "TBD" below. i.e. milestones to me are just an
> outcome of the above. So milestones

Just to add one other process point.

It's possible for a working group to be chartered to do work on a
deliverable that doesn't have a milestone (yet). The idea is that the AD
and working group chairs would add a milestone when the working group is
ready to work on that deliverable, and the working group would not adopt a
draft for this deliverable until the milestone has been added.

Obviously, people can still think about the work and write individual
drafts before
the milestone is added.

Having chartered work without a milestone allows the chairs to focus
effort, prioritize requests for meeting time slots, etc. without having to
go back to the IESG and recharter when it's time to ramp up the effort.

This approach gets used for a variety of reasons. For instance, a working
group might not work on solutions until they request publication on a
requirements draft, or a working group might not work on cool extensions
until they request publication on a boring base protocol draft.

This practice varies between areas, and even   between working groups
within an area, so it's not surprising if people aren't aware of it. And it
came as a shock to some folks during TAPS charter discussions after IETF
90, so I expect some folks might not know about it in DTN.

Spencer, as the irresponsible AD

> Regards,
> Brian
>
> > Thanks - Fred
> > [email-masked] <javascript:;>
> >
> >> Regards, Marc.
> >>
> >>> [email-masked] <javascript:;>
> >>>
> >>>> From: dtn [mailto:[email-masked] <javascript:;>] On Behalf Of
> Marc Blanchet
> >>>> To: [email-masked] <javascript:;>
> >>>> Cc: Martin Stiemerling
> gmail.com>,
> >>>>     Archive:
> specifies
> 2002.
> unmanned air vehicles.
> new use cases and
> management,
> endeavoured, the Problem statement should
> >>>> [email-masked] <javascript:;>
> >> [email-masked] <javascript:;>
> > [email-masked] <javascript:;>

---

From: "Templin, Fred L" <[email-masked]>
Date: Mon, 8 Sep 2014 18:02:59 +0000

Hi Marc,

> sure. my frenchy english. I was trying to say that the scope (especially
> given the relative high number of topics > that has been discussed so far
> and that there is a concern of the quantity and the need) of the changes
> in the protocol specifications should be agreed through the problem
> statement draft.

Here is my suggested re-word:

  "Before the updates of the protocol specifications are endorsed by the
  working group, the Problem statement should..."

Thanks - Fred

---

From: "Templin, Fred L" <[email-masked]>
Date: Mon, 8 Sep 2014 18:07:29 +0000

Hi Stephen,

> WG should not depend on it happening.

That is the way that the IRTF and IETF are intended to work together.
If it happens that way, then great and we can point to the synergy as
a success story. If it doesn't happen that way, then we still have an
IETF working group charter to execute from and look forward to future
co-operation with the research group.

Thanks - Fred