Subject: [Stackevo] SPUD Requirements, meetings in Prague

From: Brian Trammell <[email-masked]>
Date: Fri, 3 Jul 2015 12:48:58 +0200

Greetings, all,

As discussed (at the IAB retreat in May in London, and on this list), the SPUD Requirements group (nee "design team") is working on completing a -00 revision of the SPUD requirements document (see https://github.com/stackevo/spudreq) for the deadline. This document will then be taken to the [email-masked] list for discussion.

We've scheduled a meeting in Prague, at 13:00 on the Saturday before the IETF, for the requirements group to meet to continue discussion, following the discussion on the list as well as drilling down on remaining open questions in the requirements. All program members are welcome to attend, with the caveats that (1) it's a small room and (2) the focus will be on text-editors-open, pens-on-the-whiteboard progress on the document.

I know this is a bit late, but if we need to schedule meetings in the breakout room on other topics during the week (points 3, 4, 5, and 7 on our current-work list), I suppose it's effectively impossible to schedule something during the day. Thursday lunchtime is still open in the breakout room (though it conflicts with the speaker series). The breakout room is also available on Tuesday before the tech plenary, though people who have to be in the IESG breakfast (assuming there is one -- the agenda is presently empty) won't be able to attend.

Cheers,

Brian

---

From: "Eggert, Lars" <[email-masked]>
Date: Fri, 3 Jul 2015 10:54:15 +0000

Hi,

I remain uncomfortable that this IAB program is acting like an IETF WG without actually being chartered as one. I understand wanting to make progress, but the kind of work here is not IMO something that should be done under the guise of an IAB program.

Lars

On 2015-7-3, at 12:48, Brian Trammell <[email-masked]> wrote:
> _______________________________________________
> Stackevo mailing list
> [email-masked]
> https://www.iab.org/mailman/listinfo/stackevo

---

From: Mirja Kühlewind <[email-masked]>
Date: Fri, 3 Jul 2015 13:17:19 +0200

Hi Lars,

similar as with all other wg efforts we prepare SPUD documents to actually ask for a working group as some point. We don’t think this effort is ready yet. But the intention definitely is to do the work in a working group.

Mirja

> Am 03.07.2015 um 12:54 schrieb Eggert, Lars <[email-masked]>:
> 
> Hi,
>

---

From: Brian Trammell <[email-masked]>
Date: Fri, 3 Jul 2015 13:26:38 +0200

hi Lars,

I appreciate this concern, and have been trying to structure what we're doing here to address precisely this. I'm not sure what else to do, so I'd appreciate you elaborating here on what we could do better.

IMO what we're working on now is *not* engineering ready -- though we are thinking in terms of a protocol (because that's what can be prototyped), it is not clear whether the requirements we're looking at actually apply to a single protocol, a set of protocols, or a set of principles for future protocol design. Indeed, if "one signaling method to rule them all" turns out not to work for the range of applications we know we want to support -- and indeed, prior experience in this space is not encouraging on this point -- then we're left with a set of principles and an agreement on a common communication pattern for allowing middleboxes at least to maintain better state with protocols over UDP, and a statement of good luck to those trying to make cooperation work better.

Definitely there will be some engineering. But if we don't know yet what the scope of a future WG will be in this aspect, then it's hard to put together a charter for it. What I really, really don't want to do is have a WG forming BoF with a proposed charter covering the entire the present problem space we're considering.

At the same time there the Dallas BoF showed clear community interest in discussing these issues (if not clear community consensus on what the boundaries of the issues are), so we want to keep the list open, and are working to put something coherent together on our thoughts on requirements before Prague to facilitate hallway discussion.

Cheers,

Brian

> On 03 Jul 2015, at 12:54, Eggert, Lars <[email-masked]> wrote:
> 
> Hi,
>

---

From: "Eggert, Lars" <[email-masked]>
Date: Fri, 3 Jul 2015 11:27:24 +0000

> similar as with all other wg efforts we prepare SPUD documents to actually ask for a working group as some point. We don’t think this effort is ready yet. But the intention definitely is to do the…

Why not do/coordinate this preliminary work using the [email-masked] list then? Using [email-masked] gives the impression this is an IAB effort and somehow special.

Lars

---

From: "Eggert, Lars" <[email-masked]>
Date: Fri, 3 Jul 2015 11:36:53 +0000

Hi,

> I appreciate this concern, and have been trying to structure what we're doing here to address precisely this. I'm not sure what else to do, so I'd appreciate you elaborating here on what we could d…

well, for starters, realize that the IAB Stackevo program is not identical with the group of people interested in engineering the SPUD solution proposal.

I'm fully with you that you SPUD guys should meet and discuss in Prague, and do whatever you want in order to get the SPUD proposal moving along. There's the [email-masked] list for that, where you can coordinate like any other group hoping to get IETF traction.

The IAB Stackevo program may even want to hear about what's new with SPUD, since it's one effort related to the scope of the IAB program.

But the two groups are not the same, even if there is some personell overlap, and continuously trying to make it look like SPUD is an IAB thing is pushing my buttons. Maybe my old AD sensitivities haven't fully become numb yet :-)

Lars

---

From: Brian Trammell <[email-masked]>
Date: Fri, 3 Jul 2015 13:54:47 +0200

> On 03 Jul 2015, at 13:36, Eggert, Lars <[email-masked]> wrote:
> 
> Hi,
> 

Understood.

I do want to push back here and say there's also a separation between SPUD-as-prototype (leading to SPUD-as-engineering solution) and exploring the constraints on what we can realistically do to make it possible to deploy new (probably encapsulated) transport protocols in the Internet. It's this second thing that's IMO clearly a work item for the program.

Possibly, labeling both of these things SPUD is an error, though it does make it clear which list we want to target the discussion to.

> I'm fully with you that you SPUD guys should meet and discuss in Prague, and do whatever you want in order to get the SPUD proposal moving along. There's the [email-masked] list for that, where you…

And the plan is to take something internally self-consistent -- but with as few arbitrary choices pre-made as possible -- to that list, after which discussion continues there.

> But the two groups are not the same, even if there is some personell overlap, and continuously trying to make it look like SPUD is an IAB thing is pushing my buttons.

So I'm not trying to make SPUD look like an IAB thing, though I may (personally) not be trying hard enough to make the separation clear. But this effort *did* arise out of the first thing we put on the list of things to address in the program after the Cancun retreat, though. So while SPUD-as-BoF-and-potential-WG is completely separate, I don't really agree that the exploration of the problem space is out of scope for the program.

(As an aside, yes, that list has expanded nicely, especially after this year's retreat, and I apologize with my program lead hat on for my falling asleep at the wheel and failing to schedule time in advance in Prague for these other topics.)

> Maybe my old AD sensitivities haven't fully become numb yet :-)

From the outside perspective it doesn't look like those ever go away. :)

Thanks, cheers,

Brian

---

From: Mirja Kühlewind <[email-masked]>
Date: Fri, 3 Jul 2015 14:01:08 +0200

As Brian said we will discuss the document(s) we are preparing right now on the spud list as soon as the first version is released (which will be Monday). But as a discussion basis we need a first version first and writing a document requires a limited group of authors to be successful. Effectively these authors currently do not all belong to the StackEvo Program (yet), however, those authors that are part of the program see this as a program activity.

Mirja

> Am 03.07.2015 um 13:27 schrieb Eggert, Lars <[email-masked]>:
>

---

From: Eliot Lear <[email-masked]>
Date: Fri, 03 Jul 2015 14:21:53 +0200

As I suggested at the time, this seems ripe for an RG.

Eliot

---

From: Mary Barnes <[email-masked]>
Date: Fri, 3 Jul 2015 10:41:44 -0500

Lars et al,

I also have been uncomfortable with the IETF work having the appearance of
being "done" within the program but haven't figured out a way to articulate
well why that is (and I've had that discomfort for quite some time).     I
think the basic discomfort comes from the fact that while the output of IAB
programs can be new work in IETF,  the IAB's role is to *identify* the new
work and then that new work ought to be done within the context of IETF
processes and procedures.   Certainly, IAB members and even the IAB program
lead can contribute to the new work, but that ought to be in their roles as
members of the IETF community (and without IAB program lead or IAB program
member hats).

So, I'm in full agreement with Lars' concerns which is obviously in no way
related to my having what I call ex-AD syndrome (those hats do seem to be
really hard to take off).  My concern is around keeping a clean line clean
of separation and transparency between the IAB's role and the IETF
community's role when it comes to proposals for new work.

Regards,
Mary.

On Fri, Jul 3, 2015 at 6:36 AM, Eggert, Lars <[email-masked]> wrote:

> > I appreciate this concern, and have been trying to structure what we're
> doing here to address precisely this. I'm not sure what else to do, so I'd
> appreciate you elaborating here on what we could do better.
>
> well, for starters, realize that the IAB Stackevo program is not identical
> with the group of people interested in engineering the SPUD solution
> proposal.
>
> I'm fully with you that you SPUD guys should meet and discuss in Prague,
> and do whatever you want in order to get the SPUD proposal moving along.
> There's the [email-masked] list for that, where you can coordinate like
> any other group hoping to get IETF traction.
>
> The IAB Stackevo program may even want to hear about what's new with SPUD,
> since it's one effort related to the scope of the IAB program.
>
> But the two groups are not the same, even if there is some personell
> overlap, and continuously trying to make it look like SPUD is an IAB thing
> is pushing my buttons. Maybe my old AD sensitivities haven't fully become
> numb yet :-)
>
> Lars
>
> > IMO what we're working on now is *not* engineering ready -- though we
> are thinking in terms of a protocol (because that's what can be
> prototyped), it is not clear whether the requirements we're looking at
> actually apply to a single protocol, a set of protocols, or a set of
> principles for future protocol design. Indeed, if "one signaling method to
> rule them all" turns out not to work for the range of applications we know
> we want to support -- and indeed, prior experience in this space is not
> encouraging on this point -- then we're left with a set of principles and
> an agreement on a common communication pattern for allowing middleboxes at
> least to maintain better state with protocols over UDP, and a statement of
> good luck to those trying to make cooperation work better.
> >
> > Definitely there will be some engineering. But if we don't know yet what
> the scope of a future WG will be in this aspect, then it's hard to put
> together a charter for it. What I really, really don't want to do is have a
> WG forming BoF with a proposed charter covering the entire the present
> problem space we're considering.
> >
> > At the same time there the Dallas BoF showed clear community interest in
> discussing these issues (if not clear community consensus on what the
> boundaries of the issues are), so we want to keep the list open, and are
> working to put something coherent together on our thoughts on requirements
> before Prague to facilitate hallway discussion.
> >
> > Cheers,
> >
> > Brian
> >
> >
> >
> >
> >> I remain uncomfortable that this IAB program is acting like an IETF WG
> without actually being chartered as one. I understand wanting to make
> progress, but the kind of work here is not IMO something that should be
> done under the guise of an IAB program.
> >>
> >> Lars
> >>
> >>> As discussed (at the IAB retreat in May in London, and on this list),
> the SPUD Requirements group (nee "design team") is working on completing a
> -00 revision of the SPUD requirements document (see
> https://github.com/stackevo/spudreq) for the deadline. This document will
> then be taken to the [email-masked] list for discussion.
> >>>
> >>> We've scheduled a meeting in Prague, at 13:00 on the Saturday before
> the IETF, for the requirements group to meet to continue discussion,
> following the discussion on the list as well as drilling down on remaining
> open questions in the requirements. All program members are welcome to
> attend, with the caveats that (1) it's a small room and (2) the focus will
> be on text-editors-open, pens-on-the-whiteboard progress on the document.
> >>>
> >>> I know this is a bit late, but if we need to schedule meetings in the
> breakout room on other topics during the week (points 3, 4, 5, and 7 on our
> current-work list), I suppose it's effectively impossible to schedule
> something during the day. Thursday lunchtime is still open in the breakout
> room (though it conflicts with the speaker series). The breakout room is
> also available on Tuesday before the tech plenary, though people who have
> to be in the IESG breakfast (assuming there is one -- the agenda is
> presently empty) won't be able to attend.
> >>>
> >>> Cheers,
> >>>
> >>> Brian

---

From: Mary Barnes <[email-masked]>
Date: Fri, 3 Jul 2015 10:43:54 -0500

One comment below [MB].

Mary.

On Fri, Jul 3, 2015 at 6:54 AM, Brian Trammell <[email-masked]> wrote:

> > well, for starters, realize that the IAB Stackevo program is not
> identical with the group of people interested in engineering the SPUD
> solution proposal.
>
> Understood.
>
> I do want to push back here and say there's also a separation between
> SPUD-as-prototype (leading to SPUD-as-engineering solution) and exploring
> the constraints on what we can realistically do to make it possible to
> deploy new (probably encapsulated) transport protocols in the Internet.
> It's this second thing that's IMO clearly a work item for the program.
>
[MB] I have to wonder if this second thing doesn't fit within the category
of an RG as Eliot suggested? [/MB]

>
> Possibly, labeling both of these things SPUD is an error, though it does
> make it clear which list we want to target the discussion to.
>
> And the plan is to take something internally self-consistent -- but with
> as few arbitrary choices pre-made as possible -- to that list, after which
> discussion continues there.
>
> > The IAB Stackevo program may even want to hear about what's new with
> SPUD, since it's one effort related to the scope of the IAB program.
> >
> is pushing my buttons.
> So I'm not trying to make SPUD look like an IAB thing, though I may
> (personally) not be trying hard enough to make the separation clear. But
> this effort *did* arise out of the first thing we put on the list of things
> to address in the program after the Cancun retreat, though. So while
> SPUD-as-BoF-and-potential-WG is completely separate, I don't really agree
> that the exploration of the problem space is out of scope for the program.
>
> (As an aside, yes, that list has expanded nicely, especially after this
> year's retreat, and I apologize with my program lead hat on for my falling
> asleep at the wheel and failing to schedule time in advance in Prague for
> these other topics.)
>
> >> Definitely there will be some engineering. But if we don't know yet
> what the scope of a future WG will be in this aspect, then it's hard to put
> >> At the same time there the Dallas BoF showed clear community interest
> in discussing these issues (if not clear community consensus on what the

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 3 Jul 2015 08:52:01 -0700

On Fri, Jul 3, 2015 at 8:41 AM, Mary Barnes <[email-masked]>
wrote:

> processes and procedures.
>

I don't have an opinion on where this work should be done, but I don't
agree that the IAB's role
is solely to identify new work and do it within the ordinary IETF
processes. S 2.1 of the IAB
charter seems to contemplate a broader scope:

"  A major role of the IAB is long range planning and coordination
   between different areas of IETF activity.  The IAB, both collectively
   and on an individual basis, is expected to pay attention to important
   long-term issues in the Internet, and to make sure that these issues
   are brought to the attention of the group(s) that are in a position
   to address them.  It is also expected to play a role in assuring that
   the people responsible for evolving the Internet and its technology
   are aware of the essential elements of the Internet architecture."

Moreover, the IAB has a long history of publishing documents on its own,
such as:

RFC 1481
RFC 1881
RFC 1984
RFC 2804
RFC 2825
RFC 2826
RFC 3238
RFC 3552
etc.

-Ekr

>   Certainly, IAB members and even the IAB program lead can contribute to
> the new work, but that ought to be in their roles as members of the IETF
> community (and without IAB program lead or IAB program member hats).
>
>> https://github.com/stackevo/spudreq) for the deadline. This document
>> will then be taken to the [email-masked] list for discussion.
>> >>>

---

From: Mary Barnes <[email-masked]>
Date: Fri, 3 Jul 2015 11:15:54 -0500

On Fri, Jul 3, 2015 at 10:52 AM, Eric Rescorla <[email-masked]> wrote:

>> I also have been uncomfortable with the IETF work having the appearance
>> of being "done" within the program but haven't figured out a way to
>> articulate well why that is (and I've had that discomfort for quite some
>> time).     I think the basic discomfort comes from the fact that while the
>> output of IAB programs can be new work in IETF,  the IAB's role is to
>> *identify* the new work and then that new work ought to be done within the
>> context of IETF processes and procedures.
>>
>
[MB] I'm fully aware that IAB publishes documents on it's own.  But, AFAIK,
the IAB has never published a document that was direct input to a Bof nor
has IAB ever had a "focus group" (as part of a program or otherwise) whose
intention is to be the primary driver of input for an IETF Bof.   The IAB's
role in Bof's is quite clear:
https://www.iab.org/documents/correspondence-reports-documents/2012-2/iab-member-roles-in-evaluating-new-work-proposals/

You might to take particular note of the following statement:

"Individual IAB members do not have a privileged role in determining
whether a BOF will result in a chartered working group. IAB members
providing architectural oversight must ensure that their role is not
misunderstood by BOF proponents or by the larger community of interest.

The IESG is requested to give comments from IAB members the same weight the
comments would be given if those persons were not serving on the IAB — no
more, and no less."
So, IMHO, we create a lot of confusion by suggesting that this Bof and/or
any documents are output of the IAB program.  The motivation for the
individuals in the program instigating the BoF certainly came from
discussions by members of the IAB program.  But, I don't think it's the
role of IAB members to instigate Bofs - that's the role of members of the
community.   Certainly, the program could have produced a document
explaining why they believed there was need for work by the IETF in this
area and highlight some of the considerations.  That document could be
considered as input to the charter for a Bof.    And, I think the IAB
statement referenced above is quite clear about all of this:

"A Note about IAB Members acting as advocates

Like any other members of the IETF community, IAB members are encouraged to
help form communities interested in proposed new work efforts within the
IETF, and to act as advocates for these proposals, based on their own
expertise, experience, and interests. In some cases IAB member advocacy for
a proposal has resulted in important work within the IETF.

IAB members performing these roles act as individual contributors, and the
process they follow is defined by the IETF Standards Process (BCP 09), as
is true for all IETF participants acting as individual contributors. The
practices described in this document may apply for other IAB members
providing architectural oversight for a proposal that numbers IAB members
among its advocates, but IAB members acting as advocates for a proposal do
not simultaneously provide evaluation of the same proposal as part of the
IAB’s architectural oversight function."
In short, I think  the note in the Contributor section of the document is
inappropriate
"This document is the work of the SPUD focus area within the IAB IP Stack
Evolution program."
I would be okay with something like:
"The impetus for this document was a result of discussions within the IAB
IP Stack Evolution program."

[/MB]

>> So, I'm in full agreement with Lars' concerns which is obviously in no
>> way related to my having what I call ex-AD syndrome (those hats do seem to
>> be really hard to take off).  My concern is around keeping a clean line
>> clean of separation and transparency between the IAB's role and the IETF
>>> > I appreciate this concern, and have been trying to structure what
>>> we're doing here to address precisely this. I'm not sure what else to do,
>>> so I'd appreciate you elaborating here on what we could do better.
>>>
>>> >> I remain uncomfortable that this IAB program is acting like an IETF
>>> WG without actually being chartered as one. I understand wanting to make
>>> >>> As discussed (at the IAB retreat in May in London, and on this
>>> list), the SPUD Requirements group (nee "design team") is working on
>>> completing a -00 revision of the SPUD requirements document (see
>>> >>> I know this is a bit late, but if we need to schedule meetings in
>>> the breakout room on other topics during the week (points 3, 4, 5, and 7 on
>>> our current-work list), I suppose it's effectively impossible to schedule

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 3 Jul 2015 09:20:29 -0700

On Fri, Jul 3, 2015 at 9:15 AM, Mary Barnes <[email-masked]>
wrote:

> [MB] I'm fully aware that IAB publishes documents on it's own.  But,
> AFAIK, the IAB has never published a document that was direct input to a
> Bof nor has IAB ever had a "focus group" (as part of a program or
> otherwise) whose intention is to be the primary driver of input for an IETF
> Bof.   The IAB's role in Bof's is quite clear:
>
> The IESG is requested to give comments from IAB members the same weight
> the comments would be given if those persons were not serving on the IAB —
> no more, and no less."
>
You'll note that this refers to "individual IAB members" not to the IAB as
a whole.

> IP Stack Evolution program."

I don't see any material difference between these two. I'm happy to see it
changed,
but I also think this is largely a non-issue.

-Ekr

>>>> I'm fully with you that you SPUD guys should meet and discuss in
>>>> Prague, and do whatever you want in order to get the SPUD proposal moving
>>>> along. There's the [email-masked] list for that, where you can
>>>> coordinate like any other group hoping to get IETF traction.
>>>>
>>>> >>> We've scheduled a meeting in Prague, at 13:00 on the Saturday
>>>> before the IETF, for the requirements group to meet to continue discussion,

---

From: Mirja Kühlewind <[email-masked]>
Date: Fri, 3 Jul 2015 18:21:10 +0200

Hi Mary,

I have to say I currently really don’t see any concerns here. Form my point of view all current activity is aligned with what you’ve said below. All work we are doing right now is indented to lead to IETF work and all drafts will be discussed on the spud list as soon as the are published (otherwise it’s really start to discuss them). There is NO intention of hiding anything from the IETF community by doing it in the IAB instead of the IETF and I really don’t know where this impression is coming from…

We are currently still in the process of identifying if our current effort can actually lead to new work in the IETF (as you described as below). People contributing to the IETF makes these kind of efforts often on an individual basis. In this case I see my current contribution to anything that is related to SPUD as an effort that I make as a member of the Stack Evo Program. If that is not the intention of the Stack Evo Program that I’m not sure what I actually should be doing as a member of the program.

The reason why Brian announced the SPUD-related meeting on the IAB list is that he made the room request as lead of the Stack Evo program. However, I would hope that we can use this meeting as a meeting between the current group of authors of the spud requirement document that we started writing right now to actually make further progress on the text. Actually writing text is only possible in a smallish group (where our current group of 8 people is already large). And all addition discussion will simply take place on the spud mailing list!

Mirja

> Am 03.07.2015 um 17:41 schrieb Mary Barnes <[email-masked]>:
> 
> Lars et al,
> 
> I also have been uncomfortable with the IETF work having the appearance of being "done" within the program but haven't figured out a way to articulate well why that is (and I've had that discomfort for quite some time).     I think the basic discomfort comes from the fact that while the output of IAB programs can be new work in IETF,  the IAB's role is to *identify* the new work and then that new work ought to be done within the context of IETF processes and procedures.   Certainly, IAB members and even the IAB program lead can contribute to the new work, but that ought to be in their roles as members of the IETF community (and without IAB program lead or IAB program member hats).   
> 
> So, I'm in full agreement with Lars' concerns which is obviously in no way related to my having what I call ex-AD syndrome (those hats do seem to be really hard to take off).  My concern is around keeping a clean line clean of separation and transparency between the IAB's role and the IETF community's role when it comes to proposals for new work.
> 
> Regards,
> Mary. 
>

---

From: Mirja Kühlewind <[email-masked]>
Date: Fri, 3 Jul 2015 18:40:24 +0200

Hi again,

see belwo
> Am 03.07.2015 um 18:15 schrieb Mary Barnes <[email-masked]>:
> 
> On Fri, Jul 3, 2015 at 8:41 AM, Mary Barnes <[email-masked]> wrote:
> Lars et al,
> 
> I also have been uncomfortable with the IETF work having the appearance of being "done" within the program but haven't figured out a way to articulate well why that is (and I've had that discomfort for quite some time).     I think the basic discomfort comes from the fact that while the output of IAB programs can be new work in IETF,  the IAB's role is to *identify* the new work and then that new work ought to be done within the context of IETF processes and procedures.
> 
> I don't have an opinion on where this work should be done, but I don't agree that the IAB's role
> is solely to identify new work and do it within the ordinary IETF processes. S 2.1 of the IAB
> [MB] I'm fully aware that IAB publishes documents on it's own.  But, AFAIK, the IAB has never published a document that was direct input to a Bof nor has IAB ever had a "focus group" (as part of a program or otherwise) whose intention is to be the primary driver of input for an IETF Bof.   The IAB's role in Bof's is quite clear:
> "Individual IAB members do not have a privileged role in determining whether a BOF will result in a chartered working group. IAB members providing architectural oversight must ensure that their role is not misunderstood by BOF proponents or by the larger community of interest.
> 
> The IESG is requested to give comments from IAB members the same weight the comments would be given if those persons were not serving on the IAB — no more, and no less.“

There is a difference between being an IAB member and being a member of an IAB program.

> 
> So, IMHO, we create a lot of confusion by suggesting that this Bof and/or any documents are output of the IAB program.  The motivation for the individuals in the program instigating the BoF certainly came from discussions by members of the IAB program.  But, I don't think it's the role of IAB members to instigate Bofs - that's the role of members of the community.   Certainly, the program could have produced a document explaining why they believed there was need for work by the IETF in this area and highlight some of the considerations.  That document could be considered as input to the charter for a Bof.  

None of the documents that we produce currently are IAB documents. Currently these are individual documents that could become wg documents if there every will be a wg.

>  And, I think the IAB statement referenced above is quite clear about all of this: 
> 
> Like any other members of the IETF community, IAB members are encouraged to help form communities interested in proposed new work efforts within the IETF, and to act as advocates for these proposals, based on their own expertise, experience, and interests. In some cases IAB member advocacy for a proposal has resulted in important work within the IETF.
> 
> IAB members performing these roles act as individual contributors, and the process they follow is defined by the IETF Standards Process (BCP 09), as is true for all IETF participants acting as individual contributors. The practices described in this document may apply for other IAB members providing architectural oversight for a proposal that numbers IAB members among its advocates, but IAB members acting as advocates for a proposal do not simultaneously provide evaluation of the same proposal as part of the IAB’s architectural oversight function."
> 
> In short, I think  the note in the Contributor section of the document is inappropriate 
> "This document is the work of the SPUD focus area within the IAB IP Stack Evolution program."
> "The impetus for this document was a result of discussions within the IAB IP Stack Evolution
> program.“

I agree that this statement is confusing. However, for me the two sentences are not that much different. The document is an individual document. However, the work that was spent on the document was done by some of the authors as part of their role as a program member.

I appreciate to mention the program in the document for now because often the outcome of a IAB program is only very limited visible to the IETF community. 

Further, I find it very useful to do this work as part of my program membership because this allows me get a good overview on related activities.

But maybe we need to better specify what a IAB program should do (and not do).

However, I can only say this again and again… there is no intention of hiding anything for the IETF community or doing work that should be done in the IETF elsewhere. The intention to figure where which work should be done and initiate the needed steps. I think this is inline which the role of the IAB.

Mirja

> 
> [/MB] 
> 
> RFC 1481
> RFC 1881
> RFC 1984
> RFC 2804
> RFC 2825
> RFC 2826
> RFC 3238
> RFC 3552
> etc.
> 
> -Ekr
>  
>   Certainly, IAB members and even the IAB program lead can contribute to the new work, but that ought to be in their roles as members of the IETF community (and without IAB program lead or IAB program member hats).   
>

---

From: Dave Thaler <[email-masked]>
Date: Fri, 3 Jul 2015 16:46:19 +0000

This thread happened after an email I sent to Brian asking what the meeting was
in Prague was that showed up on the IAB wiki that I hadn’t heard about.

Especially in light of that exchange, I feel even stronger that it is inappropriate in
this particular case (other cases that EKR cited notwithstanding) to associate
SPUD-as-a-design with the IAB program.    That is, Brian stated in this thread
“Possibly, labeling both of these things SPUD is an error” and in thinking about it
I now strongly agree that is an error.

In a separate exchange, Brian explained that there are two separate design
approaches being proposed for the same problem by different folks, one based
on D-TLS and one not based on D-TLS.  Brian can correct me if I misunderstood,
but I got the impression that “SPUD” as a design was intended to be and stay
associated with the non-DTLS approach.  That means to me that it’s inappropriate
for problem-space-requirements to be associated with the term SPUD or the
IAB program.   As such, if that’s correct, then I’d like to request that all “SPUD”
specific discussion (as opposed to problem-requirements-space discussion)
be disassociated with the IAB program in any form.  That is, I’m now at least
as uncomfortable as Lars and Mary, and perhaps more so.

I am currently not planning to attend the Prague discussion on SPUD
(already have flights), but I do think it is critical that any problem-requirements-
space discussion have representation from current or past IAB folks who might
advocate using D-TLS as a substrate so that the IAB would not unfairly bias discussion
that ought to occur in the IETF.   I would recommend EKR and Christian Huitema
(I haven’t asked EKR about his views on design approach, but given his D-TLS
expertise I do think EKR is required :).

Dave

From: Stackevo [mailto:[email-masked]] On Behalf Of Mary Barnes
Sent: Friday, July 3, 2015 8:42 AM
To: Eggert, Lars
Cc: Stackevo; Brian Trammell
Subject: Re: [Stackevo] SPUD Requirements, meetings in Prague

Lars et al,

Regards,
Mary.

On Fri, Jul 3, 2015 at 6:36 AM, Eggert, Lars <[email-masked]<mailto:[email-masked]>> wrote:
Hi,

I'm fully with you that you SPUD guys should meet and discuss in Prague, and do whatever you want in order to get the SPUD proposal moving along. There's the [email-masked]<mailto:[email-masked]> list for that, where you can coordinate like any other group hoping to get IETF traction.

Lars

>> On 03 Jul 2015, at 12:54, Eggert, Lars <[email-masked]<mailto:[email-masked]>> wrote:
>>
>> Hi,
>>
>> On 2015-7-3, at 12:48, Brian Trammell <[email-masked]<mailto:[email-masked]>> wrote:
>>>
>>> Greetings, all,
>>>
>>> As discussed (at the IAB retreat in May in London, and on this list), the SPUD Requirements group (nee "design team") is working on completing a -00 revision of the SPUD requirements document (see https://github.com/stackevo/spudreq) for the deadline. This document will then be taken to the [email-masked]<mailto:[email-masked]> list for discussion.
>>>
>>> [email-masked]<mailto:[email-masked]>
> [email-masked]<mailto:[email-masked]>

_______________________________________________
Stackevo mailing list
[email-masked]<mailto:[email-masked]>
https://www.iab.org/mailman/listinfo/stackevo

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 3 Jul 2015 10:17:41 -0700

> I now strongly agree that is an error.

I tend to agree about this. If we are to have a SPUD BOF and perhaps a SPUD
WG, then
whatever this group is doing should not be labelled SPUD. YAM, perhaps :)

> IAB program.

I must say that I am now confused. I had very much thought that this
exercise and
the draft requirement was associated with requirements and not with any
particular
approach.

Perhaps Brian and Joe would be so good as to weigh in on how they think the
work should be divided up.

> expertise I do think EKR is required :)
>

I also do not expect to be there on Saturday, but would be more than happy
to engage
in a discussion at some other time. FWIW, I am of course glad to see that
people are
interested in using DTLS for stuff (it's a floor wax and a dessert topping)
and I would
definitely like to consider using it where appropriate, but I do think it's
important to have
some sense of what we are trying to accomplish before we decide on
technology. Perhaps
there is already a concise statement elsewhere of that objective that we
could reflect
on. Joe?

-Ekr

Dave
>
>
>
> *From:* Stackevo [mailto:[email-masked]] *On Behalf Of *Mary
> Barnes
> *Sent:* Friday, July 3, 2015 8:42 AM
> *To:* Eggert, Lars
> *Cc:* Stackevo; Brian Trammell
> *Subject:* Re: [Stackevo] SPUD Requirements, meetings in Prague
>
>
>
> Lars et al,
>
>
>

---

From: Eliot Lear <[email-masked]>
Date: Fri, 03 Jul 2015 19:22:07 +0200

Hi Dave,

Please see below.

> expertise I do think EKR is required :).

I guess it depends on what the goals of the program really should be. 
If they're to be to flesh out the problem space, that's one thing.  If
they're to develop approaches, that is something else.  The board should
pick what it likes, but  the reason I like the idea of an RG in this
space is that all possibilities can be explored and published, and
people can even define their own problem space, at least to a point.  I
like the idea of prototyping.  Others can correct me, but my
understanding is that the current prototyping is just that, and not
intended to escape the lab.  Recognizing those are famous last words,
let's also recognize that prototyping – and publishing results – is a
good thing that can lead to better decisions down the line by a working
group, should the IETF take up the charge.  The IRTF also has all the
necessary publication review mechanisms in place.

To Mary's point, the way one would build out an RG is not to call it the
"SPUDRG" but to broaden it out.  I'm short on names these days, but
maybe "help unsticking the hourglass (huth)".  Hopefully others could be
drawn into providing their own views.

The model I keep in mind is that of the routing research group when
three or four proposed methods for overlaying were developed and
presented, and then at least for a time, the work evolved in the RRG. 
That was, in my opinion, that group's zenith of relevance to the
research world, and we saw many papers crop up, both from practitioners
and researchers.  (Yes, there were problems later but at that moment it
was a great place to be, and a full room).

And that is, as I understand it, Lars' ideal for an RG.

Eliot

>  
>
> Dave
>
>  
>
> *From:*Stackevo [mailto:[email-masked]] *On Behalf Of *Mary
> Barnes
> I also have been uncomfortable with the IETF work having the
> appearance of being "done" within the program but haven't figured out
> a way to articulate well why that is (and I've had that discomfort for
> quite some time).     I think the basic discomfort comes from the fact
> that while the output of IAB programs can be new work in IETF,  the
> IAB's role is to *identify* the new work and then that new work ought
> to be done within the context of IETF processes and procedures.  
> the new work, but that ought to be in their roles as members of the
> IETF community (and without IAB program lead or IAB program member
> hats).   
>
>  
>
> way related to my having what I call ex-AD syndrome (those hats do
> seem to be really hard to take off).  My concern is around keeping a
> clean line clean of separation and transparency between the IAB's role
> and the IETF community's role when it comes to proposals for new work.
>
>  
>
> Regards,
>
> Mary. 
>
>  
>
>     > I appreciate this concern, and have been trying to structure
>     what we're doing here to address precisely this. I'm not sure what
>     else to do, so I'd appreciate you elaborating here on what we
>     could do better.
>
>     identical with the group of people interested in engineering the
>     SPUD solution proposal.
>
>     Prague, and do whatever you want in order to get the SPUD proposal
>     moving along. There's the [email-masked] <mailto:[email-masked]>
>     list for that, where you can coordinate like any other group
>     hoping to get IETF traction.
>
>     The IAB Stackevo program may even want to hear about what's new
>     with SPUD, since it's one effort related to the scope of the IAB
>     program.
>
>     But the two groups are not the same, even if there is some
>     personell overlap, and continuously trying to make it look like
>     SPUD is an IAB thing is pushing my buttons. Maybe my old AD
>     sensitivities haven't fully become numb yet :-)
>
>     Lars
>
>
>     > IMO what we're working on now is *not* engineering ready --
>     though we are thinking in terms of a protocol (because that's what
>     can be prototyped), it is not clear whether the requirements we're
>     looking at actually apply to a single protocol, a set of
>     protocols, or a set of principles for future protocol design.
>     Indeed, if "one signaling method to rule them all" turns out not
>     to work for the range of applications we know we want to support
>     -- and indeed, prior experience in this space is not encouraging
>     on this point -- then we're left with a set of principles and an
>     agreement on a common communication pattern for allowing
>     middleboxes at least to maintain better state with protocols over
>     UDP, and a statement of good luck to those trying to make
>     cooperation work better.
>     >
>     > Definitely there will be some engineering. But if we don't know
>     yet what the scope of a future WG will be in this aspect, then
>     it's hard to put together a charter for it. What I really, really
>     don't want to do is have a WG forming BoF with a proposed charter
>     covering the entire the present problem space we're considering.
>     >
>     > At the same time there the Dallas BoF showed clear community
>     interest in discussing these issues (if not clear community
>     consensus on what the boundaries of the issues are), so we want to
>     keep the list open, and are working to put something coherent
>     together on our thoughts on requirements before Prague to
>     facilitate hallway discussion.
>     >
>     > Cheers,
>     >
>     > Brian
>     >
>     >
>     >
>     >
>     >> I remain uncomfortable that this IAB program is acting like an
>     IETF WG without actually being chartered as one. I understand
>     wanting to make progress, but the kind of work here is not IMO
>     something that should be done under the guise of an IAB program.
>     >>
>     >> Lars
>     >>
>     list), the SPUD Requirements group (nee "design team") is working
>     on completing a -00 revision of the SPUD requirements document
>     (see https://github.com/stackevo/spudreq) for the deadline. This
>     document will then be taken to the [email-masked]
>     <mailto:[email-masked]> list for discussion.
>     >>>
>     before the IETF, for the requirements group to meet to continue
>     discussion, following the discussion on the list as well as
>     drilling down on remaining open questions in the requirements. All
>     program members are welcome to attend, with the caveats that (1)
>     it's a small room and (2) the focus will be on text-editors-open,
>     pens-on-the-whiteboard progress on the document.
>     >>>
>     >>> I know this is a bit late, but if we need to schedule meetings
>     in the breakout room on other topics during the week (points 3, 4,
>     5, and 7 on our current-work list), I suppose it's effectively
>     impossible to schedule something during the day. Thursday
>     lunchtime is still open in the breakout room (though it conflicts
>     with the speaker series). The breakout room is also available on
>     Tuesday before the tech plenary, though people who have to be in
>     the IESG breakfast (assuming there is one -- the agenda is
>     >>> [email-masked] <mailto:[email-masked]>
>     > [email-masked] <mailto:[email-masked]>
>     [email-masked] <mailto:[email-masked]>

---

From: Mirja Kühlewind <[email-masked]>
Date: Fri, 3 Jul 2015 19:46:08 +0200

Hi Ekr,

quick comment: For me requirements and use case are always protocol independent. They are needed to find/develop an appropriate protocol which then should be done in a working group. Therefore these document are/might be leading to a working group.

From my personal point of view I think requirement docs and at least one use case doc should also be produced before a working should be formed because the process of writing these docs help to set the scope of the working group correctly. If the documents are finally published as wg documents for documentation purposes, somewhere else, or not at all, I actually don’t care. Important is the work can lead to a well-scope working group (or not in case one discovers that the requirements and use cases are not clear enough to make it possible to design a protocol).

As there is no working group now; but only some activity to figure out if it would be with having a working, I don’t care how we call this and under which umbrella this is done… important is to actually to it!

Mirja

> Am 03.07.2015 um 19:17 schrieb Eric Rescorla <[email-masked]>:
> 
> 
> 
> I tend to agree about this. If we are to have a SPUD BOF and perhaps a SPUD WG, then
> I must say that I am now confused. I had very much thought that this exercise and
> the draft requirement was associated with requirements and not with any particular
> approach.
> 
> I also do not expect to be there on Saturday, but would be more than happy to engage
> in a discussion at some other time. FWIW, I am of course glad to see that people are
> interested in using DTLS for stuff (it's a floor wax and a dessert topping) and I would
> definitely like to consider using it where appropriate, but I do think it's important to have
> some sense of what we are trying to accomplish before we decide on technology. Perhaps
> there is already a concise statement elsewhere of that objective that we could reflect
> on. Joe?
> 
> -Ekr
>  
>  
>  
> 
> 
> Dave
> 
>  
>

---

From: Brian Trammell <[email-masked]>
Date: Fri, 3 Jul 2015 19:46:31 +0200

Hi, Dave, all,

It seems to me that there are a couple of giant points of miscommunication here... Let me try and clear these up.

> On 03 Jul 2015, at 18:46, Dave Thaler <[email-masked]> wrote:
> 

The work happening within the program is on the requirements -- the set of constraints on any possible attempt at fixing the present undeployability-of-new-protocols situation while enforcing explicit contracts for middlebox-endpoint communication.

This appears to me to fit squarely within the scope of the first area of current work in the current program description:

  (1) Definition of requirements and principles for encapsulation-based approaches to work around path transparency issues and to allow explicit cooperation between endpoints and devices on path, while cryptographically protecting information which should remain end-to-end (including transport headers). This work follows discussions at the IAB SEMI (Stack Evolution in a Middlebox Internet) workshop and the SPUD (Substrate Protocol for User Datagrams) BoF at IETF 92 in Dallas. Discussion of this work occurs on the SPUD mailing list: [email-masked].

This description was approved by the IAB on its 24 June call (https://www.iab.org/documents/minutes/minutes-2015/iab-minutes-2015-06-24/). I would be happy to ask the full IAB for its judgement as to whether draft-trammell-spud-req-00 (to be submitted after a few more edits following discussion among the contributors, but currently at github.com/stackevo/spudreq) fits that area of work. I'm trying to do the right thing here -- in my interpretation, this description covers this document being done by a group of contributors within the program. I *do* agree with Mary, though, that since this document is explicitly not an output of the whole program or the IAB, it should not be listed as an output of the group of the program in the Contributors section of the document. I have fixed this; contributors are now listed solely as individuals in the working copy.

The intention is for this document to exist as a basis of discussion on the [email-masked] non-WG list, to define a set of requirements (and look at the architectural tradeoffs in requirements) which may lead to eventual work either in the IETF (protocol design) or on the IAB stream (if it turns out we only come up with input to guidelines for roll-your-own approaches). In its current form, I don't think we'll seek publication as an RFC, though much of the text might end up in one or more documents on some stream.

> associated with the non-DTLS approach.

So this is not what I meant, and not the intention at all.

There are broadly *three* efforts here, corresponding to presentations at the SPUD BoF.

One is the effort to identify requirements for stack evolution with contracts for explicit cooperation -- this is the upcoming draft-trammell-spud-req, the product of discussions of this group within the program, which follows loosely from draft-hardie-spud-use-cases presented at the BoF, as well as my own presentation.

Two is the effort to experiment with a prototype to see how well these requirements can be met with running code. draft-hildebrand-spud-prototype is a description of this prototype, though the codebase in github (github.com/iptube/SPUDlib) is currently more up to date. This, I suppose, could be "SPUD as a design" but as Eliot says we mean it when we way prototype -- this one is not meant to escape the lab (and this, indeed, is one of the reasons we are *very* wary of taking this work straight into a WG). This is not *really* a "non-DTLS" approach, but rather a DTLS-agnostic approach -- what sits under the encapsulation layer could well be DTLS, but we don't focus at all on making the changes to DTLS that would be necessary for DTLS to sit nicely in such a stack.

Three is the effort outlined in draft-huitema-tls-dtls-as-subtransport, which comes at this question from the opposite side. This work already has a natural home -- the TLS working group -- and is focused on making the specific changes to DTLS that would make it work as a subtransport *generically* -- whether in a SPUD-DTLS-*shiny-new-protocol* or a UDP-DTLS-SCTP stack. *This* is why I see that work as separate, not because it is a competing effort.

>  That means to me that it’s inappropriate

This requirements document is a "SPUD requirements document" because it follows from the scope of the SPUD BoF and we intend the wider discussion to happen on the [email-masked] list (where the interested parties are), not because it is states the requirements for the SPUD prototype (though it does state the requirements we hope to evaluate the feasibility of therewith).

I think the mistake here was naming the BoF (and therefore the mailing list) and the prototype the same thing. I'm not sure what the best resolution strategy is at this time.

> expertise I do think EKR is required :).

I see the concern here -- I would like very much *not* to bias the requirements discussion either way -- I do think we've settled on any encapsulation based approach to support UDP either exclusively or as an MTI, simply through a process of elimination, because (1) only UDP and TCP are commonly supported by NATs and (2) encapsulating things in what are essentially fake TCP headers is fraught with peril. But all other protocol-level choices remain open.

Cheers,

Brian

---

From: Brian Trammell <[email-masked]>
Date: Fri, 3 Jul 2015 19:47:56 +0200

hi Eliot,

> On 03 Jul 2015, at 19:22, Eliot Lear <[email-masked]> wrote:
> 
> Hi Dave,
> 
> Please see below.
> 
> I guess it depends on what the goals of the program really should be.  If they're to be to flesh out the problem space, that's one thing.

This is what we intend with the requirements document, and I believe what the IAB meant when it approved the program description.

> If they're to develop approaches, that is something else.  The board should pick what it likes, but  the reason I like the idea of an RG in this space is that all possibilities can be explored and published, and people can even define their own problem space, at least to a point.  I like the idea of prototyping.  Others can correct me, but my understanding is that the current prototyping is just that, and not intended to escape the lab.

This is my understanding as well.

>  Recognizing those are famous last words, let's also recognize that prototyping – and publishing results – is a good thing that can lead to better decisions down the line by a working group, should the IETF take up the charge.  The IRTF also has all the necessary publication review mechanisms in place.
> 
> To Mary's point, the way one would build out an RG is not to call it the "SPUDRG" but to broaden it out.  I'm short on names these days, but maybe "help unsticking the hourglass (huth)".  Hopefully others could be drawn into providing their own views.

If we're going to pick another name (and sadly noting that YAM was taken), I'd like Middlebox-Aware Layering for Transport, to go with TAPS and HOPS (and the sadly almost completely unrelated BIER).

We discussed doing an RG after the SPUD BoF, but the attempts we made to define a research group with a focused question in this space turned into the proposed HOPSRG. But seeing how much time we're spending discussing how the work should be labeled instead of doing the work, if people are happier with exploring this in an RG I'm happy to try and make this happen for Yokohama -- though I would ask Eliot, if you could help with framing the research questions since I, at least, stumbled over this part.

Cheers,

Brian

> The model I keep in mind is that of the routing research group when three or four proposed methods for overlaying were developed and presented, and then at least for a time, the work evolved in the RRG.  That was, in my opinion, that group's zenith of relevance to the research world, and we saw many papers crop up, both from practitioners and researchers.  (Yes, there were problems later but at that moment it was a great place to be, and a full room).
>

---

From: Mirja Kühlewind <[email-masked]>
Date: Fri, 3 Jul 2015 19:52:33 +0200

Hi Eliot,

sorry, I don’t agree here. The RRG was developing mechanisms and algorithms. While we currently focus on the development of a signaling protocol. Protocol engineering usually is no research for me but is what the IETF is doing.

However, the mechanisms that what to use information that are provided by SPUD are more researchy. Both things the protocol as well as mechanisms that use information provided by the protocol are not independent of each other and need to be developed in parallel. Still I’m not sure how helpful a research group would be here because the mechanisms we are talking about might be very different. Therefore it’s not clear to me if we need a forum where one mechanism developer can talk to another guy who is doing something completely different just because they use the same signaling protocol to get very different information.

Mirja

> Am 03.07.2015 um 19:22 schrieb Eliot Lear <[email-masked]>:
> 
> Hi Dave,
> 
> Please see below.
> 
> I guess it depends on what the goals of the program really should be.  If they're to be to flesh out the problem space, that's one thing.  If they're to develop approaches, that is something else.  The board should pick what it likes, but  the reason I like the idea of an RG in this space is that all possibilities can be explored and published, and people can even define their own problem space, at least to a point.  I like the idea of prototyping.  Others can correct me, but my understanding is that the current prototyping is just that, and not intended to escape the lab.  Recognizing those are famous last words, let's also recognize that prototyping – and publishing results – is a good thing that can lead to better decisions down the line by a working group, should the IETF take up the charge.  The IRTF also has all the necessary publication review mechanisms in place.
> 
>> I'm fully with you that you SPUD guys should meet and discuss in Prague, and do whatever you want in order to get the SPUD proposal moving along. There's [email-masked] list for that, where you can coordinate like any other group hoping to get IETF traction.
>>

---

From: Mary Barnes <[email-masked]>
Date: Fri, 3 Jul 2015 12:56:56 -0500

On Fri, Jul 3, 2015 at 12:46 PM, Mirja Kühlewind <
[email-masked]> wrote:

> Hi Ekr,
>
> quick comment: For me requirements and use case are always protocol
> independent. They are needed to find/develop an appropriate protocol which
> then should be done in a working group. Therefore these document are/might
> be leading to a working group.
>
> From my personal point of view I think requirement docs and at least one
> use case doc should also be produced before a working should be formed
> because the process of writing these docs help to set the scope of the
> working group correctly. If the documents are finally published as wg
> documents for documentation purposes, somewhere else, or not at all, I
> actually don’t care. Important is the work can lead to a well-scope working
> group (or not in case one discovers that the requirements and use cases are
> not clear enough to make it possible to design a protocol).
>
> As there is no working group now; but only some activity to figure out if
> it would be with having a working, I don’t care how we call this and under
> which umbrella this is done… important is to actually to it!
>
[MB] I think we (myself included) are all in agreement that it's important
to do the work.   [/MB]

> context of IETF processes and procedures.   Certainly, IAB members and even
> the IAB program lead can contribute to the new work, but that ought to be
> in their roles as members of the IETF community (and without IAB program
> lead or IAB program member hats).
> >
> >
> >

---

From: Dave Thaler <[email-masked]>
Date: Fri, 3 Jul 2015 18:15:53 +0000

Below

> -----Original Message-----
> From: Brian Trammell [mailto:[email-masked]] 
> Sent: Friday, July 3, 2015 10:47 AM
> To: Dave Thaler
> Cc: Mary Barnes; Eggert, Lars; Stackevo
> > This thread happened after an email I sent to Brian asking what the 
> > meeting was in Prague was that showed up on the IAB wiki that I hadnt heard about.
> > 
> > Especially in light of that exchange, I feel even stronger that it is 
> > inappropriate in this particular case (other cases that EKR cited notwithstanding) to associate
> > Possibly, labeling both of these things SPUD is an error and in 
> > thinking about it I now strongly agree that is an error.
> 
> The work happening within the program is on the requirements -- the set of 
> constraints on any possible attempt at fixing the present undeployability-
> of-new-protocols situation while enforcing explicit contracts for middlebox-
> endpoint communication.
> 
> This appears to me to fit squarely within the scope of the first area of 
> current work in the current program description:
> 
>   (1) Definition of requirements and principles for encapsulation-based 
> approaches to work around path transparency issues and to allow explicit 
> cooperation between endpoints and devices on path, while cryptographically 
> protecting information which should remain end-to-end (including transport 
> headers). This work follows discussions at the IAB SEMI (Stack Evolution in
> a Middlebox Internet) workshop and the SPUD (Substrate Protocol for User 
> Datagrams) BoF at IETF 92 in Dallas. Discussion of this work occurs on the 
> SPUD mailing list: [email-masked].
> 
> This description was approved by the IAB on its 24 June call 
> (https://www.iab.org/documents/minutes/minutes-2015/iab-minutes-2015-06-24/).
> I would be happy to ask the full IAB for its judgement as to whether 
> draft-trammell-spud-req-00 (to be submitted after a few more edits
> following discussion among the contributors, but currently at 
> github.com/stackevo/spudreq) fits that area of work. I'm trying to do the
> right thing here -- in my interpretation, this description covers this 
> document being done by a group of contributors within the program. I *do* 
> agree with Mary, though, that since this document is explicitly not an 
> output of the whole program or the IAB, it should not be listed as an
> output of the group of the program in the Contributors section of the
> document. I have fixed this; contributors are now listed solely as
> individuals in the working copy.

When I agreed with that it was my understanding that the term "SPUD" and
the SPUD mailing list did NOT explicitly mean non-DTLS.  If the term
SPUD is now changed to mean non-DTLS then the program description needs
to be updated.  If the term SPUD is still agnostic, then the non-DTLS
prototype name needs to change.

> The intention is for this document to exist as a basis of discussion on
> the [email-masked] non-WG list, to define a set of requirements (and look
> at the architectural tradeoffs in requirements) which may lead to eventual
> work either in the IETF (protocol design) or on the IAB stream (if it turns
> out we only come up with input to guidelines for roll-your-own approaches).
> In its current form, I don't think we'll seek publication as an RFC, though
> much of the text might end up in one or more documents on some stream.
> 
> > In a separate exchange, Brian explained that there are two separate 
> > design approaches being proposed for the same problem by different 
> > folks, one based on D-TLS and one not based on D-TLS.  Brian can 
> > correct me if I misunderstood, but I got the impression that SPUD as 
> > a design was intended to be and stay associated with the non-DTLS approach.
> 
> One is the effort to identify requirements for stack evolution with
> contracts for explicit cooperation -- this is the upcoming
> draft-trammell-spud-req, the product of discussions of this group within
> the program, which follows loosely from draft-hardie-spud-use-cases
> presented at the BoF, as well as my own presentation.
> 
> Two is the effort to experiment with a prototype to see how well these
> requirements can be met with running code. draft-hildebrand-spud-prototype
> is a description of this prototype, though the codebase in github
> (github.com/iptube/SPUDlib) is currently more up to date. This, I suppose,
> could be "SPUD as a design" but as Eliot says we mean it when we way
> prototype -- this one is not meant to escape the lab (and this, indeed,
> is one of the reasons we are *very* wary of taking this work straight into
> a WG). This is not *really* a "non-DTLS" approach, but rather a
> DTLS-agnostic approach -- what sits under the encapsulation layer could
> well be DTLS, but we don't focus at all on making the changes to DTLS
> that would be necessary for DTLS to sit nicely in such a stack.

It still sounds non-DTLS to me.  And is what I'm commenting on that we
should not use the same name for the requirements as for the non-DTLS
prototype.

> Three is the effort outlined in draft-huitema-tls-dtls-as-subtransport,
> which comes at this question from the opposite side. This work already
> has a natural home -- the TLS working group -- and is focused on making
> the specific changes to DTLS that would make it work as a subtransport
> *generically* -- whether in a SPUD-DTLS-*shiny-new-protocol* or a
> UDP-DTLS-SCTP stack. *This* is why I see that work as separate, not
> because it is a competing effort.

I would think a non-DTLS prototype would be an alternative to a DTLS-based
prototype.
 
> >  That means to me that its inappropriate for 
> > problem-space-requirements to be associated with the term SPUD or the 
> > IAB program.  As such, if thats correct, then Id like to request that
> > all SPUD
> > specific discussion (as opposed to problem-requirements-space 
> > discussion) be disassociated with the IAB program in any form.  That 
> > is, Im now at least as uncomfortable as Lars and Mary, and perhaps more so.
> 
> This requirements document is a "SPUD requirements document" because it
> follows from the scope of the SPUD BoF and we intend the wider discussion
> to happen on the [email-masked] list (where the interested parties are),
> not because it is states the requirements for the SPUD prototype (though
> it does state the requirements we hope to evaluate the feasibility of
> therewith).
> 
> I think the mistake here was naming the BoF (and therefore the mailing
> list) and the prototype the same thing. I'm not sure what the best
> resolution strategy is at this time.

Change one of them.

> > (already have flights), but I do think it is critical that any 
> > problem-requirements- space discussion have representation from 
> > current or past IAB folks who might advocate using D-TLS as a substrate
> > so that the IAB would not unfairly bias discussion
> > (I havent asked EKR about his views on design approach, but given his 
> > D-TLS expertise I do think EKR is required :).
> 
> I see the concern here -- I would like very much *not* to bias the
> requirements discussion either way -- I do think we've settled on any
> encapsulation based approach to support UDP either exclusively or as an
> MTI, simply through a process of elimination, because (1) only UDP and
> TCP are commonly supported by NATs and (2) encapsulating things in what
> are essentially fake TCP headers is fraught with peril. But all other
> protocol-level choices remain open.
> 
> Cheers,
> 
> Brian

Thanks for clarifying.  Is the Saturday meeting intended to be scoped
to discussion of requirements (and intended to encompass either style of
design)?  Or is it for a non-DTLS design team?   I'm hoping the former
and that DTLS experts such as EKR and/or Christian would be invited and
able to be there as well.   I ask because I see you and Joe in one
particular camp, and I think we agree that we don't want bias yet.
Of course, if we discover an architectural issue between the two,
then it may become the IAB's job to become biased at that point.

Dave

---

From: Aaron Falk <[email-masked]>
Date: Fri, 3 Jul 2015 15:27:55 -0400

I have a bit of a high-level gripe.  I was added to the 'stackevo program'
after the last IETF and since then the group proper has done no work nor
had any substantive discussion beyond what should go on the web page.  So,
I'm not sure of its purpose.  It sounds like the folks on the IAB have
discussed a bunch of stuff regarding the effort but no one has summarized
it.  I was told when I joined that there would be teleconferences but none
have been scheduled.  There was a statement in May that "Discussion of the
requirements document will happen on [email-masked] until -00 is
published, after which discussion will move to [email-masked]." but only
today's meta-discussion has taken place.  I tried to get folks together at
the last IETF but no one could find the time.  Now, two weeks before the
meeting we are told that there will be a session on Saturday that starts
before my (and several others') flight lands and so many cannot attend.
Additionally, the invitation was very ambivalent about whether non-authors'
presence was welcome anyways.  I'm kind of feeling like a small group of
folks are doing things and making it look like the effort is more inclusive
than it really is.  So, I would like some clarification about what we are
doing.

--aaron

---

From: Brian Trammell <[email-masked]>
Date: Fri, 3 Jul 2015 23:05:53 +0200

hi Aaron,

Several balls have been dropped here. I take responsibility for all of these, for which I make no excuses and I apologize. I had not realized until today how much I thought had been communicated but had not. To wit:

> On 03 Jul 2015, at 21:27, Aaron Falk <[email-masked]> wrote:
> 
> I have a bit of a high-level gripe.  I was added to the 'stackevo program' after the last IETF and since then the group proper has done no work nor had any substantive discussion beyond what should go on the web page.  So, I'm not sure of its purpose. It sounds like the folks on the IAB have discussed a bunch of stuff regarding the effort but no one has summarized it.

We did have discussions about the scope of the program at the IAB retreat in London, the result of which is more or less what came out as the discussion of "what should go on the webpage", which is the same as what we believe the scope of the program is.

>  I was told when I joined that there would be teleconferences but none have been scheduled.

I'd intended to organize some discussion of the not-SPUD things on the current work list but have not had the time to do so since then.

>  There was a statement in May that "Discussion of the requirements document will happen on [email-masked] until -00 is published, after which discussion will move to [email-masked]." but only today's meta-discussion has taken place.

This oversight is *completely* my fault. We have had no mail discussion and one call since then; I intended to include [email-masked] on the organization of this call but did not.

> I tried to get folks together at the last IETF but no one could find the time. Now, two weeks before the meeting we are told that there will be a session on Saturday that starts before my (and several others') flight lands and so many cannot attend. Additionally, the invitation was very ambivalent about whether non-authors' presence was welcome anyways.

I apologize for the ambivalence here -- I mainly wanted to reiterate that the Saturday meeting was just to work on this one work item, not a general meeting of the program. Scheduling it on Saturday was not intended to be exclusive, rather a reflection that there were no slots the rest of the week. Announcing it late (as well as late scheduling of a general meeting of the program) is simply me not doing my job very well.

> I'm kind of feeling like a small group of folks are doing things and making it look like the effort is more inclusive than it really is.

This is *by no means* the intention; if you feel *in any way* that your name has been abused here then I sincerely apologize, and please let me know what I can do to fix it.

>  So, I would like some clarification about what we are doing.

Ostensibly, we're organizing work around the list of things at https://www.iab.org/activities/programs/ip-stack-evolution-program, but somewhat slowly and not very well managed since Dallas. :/

Of the things on that list, (1) we've meta-discussed discussed at length here today, (2) was work we talked about in 2014 that ended up being the TAPS WG, (6) turned into the proposed HOPS RG, and (7) is an effort to get a document on filtering considerations out the door by addressing feedback received, led by Dave.

(3), (4), and (5) are discussions we really should kick off on the stackevo list, or try to make some headway on over Thursday lunch in Prague.

With that, it's getting quite late here, so happy Fourth (to Americans in passport and heart) and cheers,

Brian

---

From: Eliot Lear <[email-masked]>
Date: Fri, 03 Jul 2015 23:06:21 +0200

Hi Mirja and Brian and others,

I'm not going to give a lengthy reply tonight but rather wish our
American friends many burgers and hot dogs and a good cold beer for the
4th of July.

Look for something on Monday.

Eliot

---

From: Dave Thaler <[email-masked]>
Date: Fri, 3 Jul 2015 21:24:22 +0000

> Of the things on that list, (1) we've meta-discussed discussed at length here today,
> (2) was work we talked about in 2014 that ended up being the TAPS WG, (6) turned
>  into the proposed HOPS RG, and (7) is an effort to get a document on filtering
> considerations out the door by addressing feedback received, led by Dave.
>
> (3), (4), and (5) are discussions we really should kick off on the stackevo list, or try
> to make some headway on over Thursday lunch in Prague.

FYI, status on (7) is that the draft with updates in progress is that Erik, Eliot, and I
previously discussed all the feedback and what needed to happen next.  The draft
is now checked into a git repository where multiple people can edit it, and some but
not all changes have been made, and more needs to be done.   Anyone else with interest
and cycles is welcome to contribute... I previously sent out a call for volunteers to the
program list and Erik/Eliot/me is who I got.   It would be good if we could get the rest of
the changes into the doc by Prague.   It won't happen by the I-D cutoff date next week,
but I plan to submit the draft with whatever changes are in by Monday night, since
the last posted copy is expired.

Dave

---

From: Brian Trammell <[email-masked]>
Date: Sat, 4 Jul 2015 13:04:45 +0200

hi Eliot,

Nor will I, until Tuesday (I'm on childcare duty Mondays, and I'm going offline after sending this message).

In the meantime, there's a deadline. We (Mirja and I, as editors) will submit the draft (at https://github.com/stackevo/spudreq/blob/master/draft-trammell-spud-req.md) as individual, and announce on the SPUD list with no mention or implication of a connection to the IAB or the Program, aside from the reference to SEMI in the History section of the document. After the submission of the document, in the interests of transparency and community involvement I'd suggest that all discussion thereof move to the [email-masked] list.

Is this an acceptable course of action *with respect to this specific document* for everyone?

Many thanks, best regards,

Brian

> On 03 Jul 2015, at 23:06, Eliot Lear <[email-masked]> wrote:
>

---

From: Eliot Lear <[email-masked]>
Date: Sat, 04 Jul 2015 13:10:42 +0200

> Is this an acceptable course of action *with respect to this specific document* for everyone?
Yes.

---

From: Erik Nordmark <[email-masked]>
Date: Mon, 6 Jul 2015 17:10:28 +0200

>    (1) Definition of requirements and principles for encapsulation-based approaches to work around path transparency issues and to allow explicit cooperation between endpoints and devices on path,…

Two things:
I find it confusing that this is work for the IAB stackevo program, yet 
the work is supposed to be done on what looks like the mailing list of a 
BoF. That might be part of the same confusion/question that Dave has 
about the name "SPUD" - whether it is a name for a particular prototype 
effort or a name for the more general questions around UDP encaps.

Instead of having the program develop formal requirements, which in the 
IETF often become (sometimes contentious) proxy discussions for folks 
favorite approaches and solutions, it might be easier to make progress 
if the program captures different aspects about the design space; 
considerations, tradeoffs, etc. Such learnings can then feed into a 
future WG that will standardize something.

Regards,
    Erik

---

From: Erik Nordmark <[email-masked]>
Date: Mon, 6 Jul 2015 17:11:47 +0200

On 7/4/15 1:04 PM, Brian Trammell wrote:
> Is this an acceptable course of action*with respect to this specific document*  for everyone?
Works for me.

    Erik

---

From: "Joe Hildebrand (jhildebr)" <[email-masked]>
Date: Mon, 6 Jul 2015 17:36:12 +0000

>should not use the same name for the requirements as for the non-DTLS

Just jumping in at a random point in the thread here about what *my* intentions have been.

I really mean draft-hildebrand-spud-prototype and the accompanying code as a prototype to be thrown away in its entirety before we start doing engineering work.  It is a way to explore the assumptions we're making, test the requirements, and to extract new requirements from the resulting intuition.  That approach is bearing fruit for me personally, at least.

I fully intend there to not be two ways of proceeding.  There is no dichotomy between DTLS and non-DTLS.  There is a dichotomy between prototype and engineering.  I fully expect that the protocol we end up engineering with have such similar goals to DTLS that it will make sense to either engineer a new version of DTLS that fits the spud-req requirements, or find a different layering mechanism that meets those requirements.

As to starting a working group, I've had BoFs before where we got beat up for not having adequate use cases or requirements, and for not having a proposed starting point for the work.  I'm not going to participate in one of those BoFs again for something I care about.  If that's not the way the community wanted work done, they should have been more accepting of early-stage work in the past.

As to a RG, I'm open to it, but don't think it would help much.  If we do form one, we'll have to change its charter or disband it briskly when it's time to start doing engineering.

-- 
Joe Hildebrand

---

From: Eliot Lear <[email-masked]>
Date: Mon, 06 Jul 2015 19:51:25 +0200

Hi Joe,

I'm sorry to be a bit of a thorn.  Please see below.

On 7/6/15 7:36 PM, Joe Hildebrand (jhildebr) wrote:
> As to a RG, I'm open to it, but don't think it would help much. If we
> do form one, we'll have to change its charter or disband it briskly
> when it's time to start doing engineering. 

If you open up a set of possibilities through these new mechanisms then
the next question is how they will be used, and what effects they have. 
Those are research topics.  In other words, the RG should not just be
about prototyping, and even if it throws something over the wall, let's
say, there is more to be done.  Of course there has to be organic
support for such an RG.

> sorry, I don’t agree here. The RRG was developing mechanisms and algorithms. While we currently focus on the development of a signaling protocol. Protocol engineering usually is no research for me…

Actually, the RRG developed LOADS of protocols.  So did NMRG, so has
HIPRG, and of course DTNRG.  I am not suggesting that anyone defocus
their work, but rather that there be a way to open the komono so that
more researchers can get engaged.

Eliot

---

From: Brian Trammell <[email-masked]>
Date: Wed, 8 Jul 2015 14:44:41 +0200

Greetings, all,

The SPUD requirements meeting will take place, as noted, at 13:00 on Saturday 18 July; I forgot to mention that this will take place in the Budapest room at the Prague Hilton.

I've also gone ahead and reserved the IAB/IESG/ISOC room for a meeting to discuss other stack evolution topics: principles for deployability (3), principles for encapsulation (4), guidance on protocol the creation of new protocol stacks for constrained devices (5), and anything that may need to discussed on progressing the filtering considerations doc (7). (I've dropped Tuesday before the plenary from consideration, due to IESG breakfast and need for some IAB people to make sure the morning tech plenary goes off smoothly.)

Cheers,

Brian

---

From: Brian Trammell <[email-masked]>
Date: Wed, 8 Jul 2015 16:40:36 +0200

> On 08 Jul 2015, at 14:44, Brian Trammell <[email-masked]> wrote:
> 
> Greetings, all,
> 
> I've also gone ahead and reserved the IAB/IESG/ISOC room for a meeting

...and thank you Ted for pointing out that I inadvertently deleted "...on Thursday over lunchtime..." from the message here...

> to discuss other stack evolution topics: principles for deployability (3), principles for encapsulation (4), guidance on protocol the creation of new protocol stacks for constrained devices (5), and anything that may need to discussed on progressing the filtering considerations doc (7). (I've dropped Tuesday before the plenary from consideration, due to IESG breakfast and need for some IAB people to make sure the morning tech plenary goes off smoothly.)
> 
> Cheers,
> 
> Brian
>