Subject: [Softwires] charter: scenarios/PS before/after WG creation

From: Pekka Savola <[email-masked]>
Date: Thu, 8 Sep 2005 09:29:13 +0300 (EEST)

Hi,

I'd like to raise this issue separately, because it's probably the 
most important one.  It was also mentioned by Thomas.

The charter does not provide any (scenarios) context for the protocol. 
So, we don't yet know which cases the protocol would be used and 
designed for.

Frankly, we can't nail down the details of the protocol in the charter 
(as has been done, to some extent, now) until we have at least some 
grasp of the scenarios we need to address.

There is a problem statement work item in the charter though.  So the 
question becomes:

Should we figure out the scenarios we target the protocol:

  a) before we nail down the (generic charter), and try to get it
     approved in the IETF (and personally, I don't think this will
     succeed, because folks WILL raise a question on the
     applicability)?

  b) after we have (tried to) create a blanket-statement protocol WG?

Usually, as far as BOFs go, the work on the problem statement is well 
under way (a 00, 01, or 02 individual draft) and we can ask folks 
whether there is consensus on the problems and scenarios.  But at this 
point, we have only vague presentations (which some folks disagree 
with) and a generic charter.

This is not good.  We cannot possibly create a good, focused charter 
without a grasp on the scenarios.   Yes, figuring (read: fighting 
over) the scenarios might take a while, but wouldn't it be better to 
do that before the WG is chartered so we can move on smoothly from 
there.

Maybe someone should take a quick first step at the problem 
statement/scenarios doc.

The main difference with softwires and v6tc seems to be that v6tc went 
further and already worked on the applicable scenarios as well as 
evaluated the protocols -- but couldn't come to consensus on the 
scenarios in particular sufficiently quickly before the effort waned 
at the BOF.  My point is that it seems better to have this discussion 
before WG is created because we don't yet know if we'll converge and 
if we don't, there's little use in creating a WG..

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

_______________________________________________
Softwires mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/softwires

---

From: Mark Townsley <[email-masked]>
Date: Thu, 08 Sep 2005 09:26:51 +0200

> So, we don't yet know which cases the protocol would be used and 

The plan presented in Paris was to narrow the scope of scenerios for the 
first deliverable at an interim meeting where providers as well as 
vendors are present to actively weigh in on the discussion. I don't 
think this is something that can be done in a short BoF session at an 
IETF, nor as effectively on a list, so I support the idea of such a 
meeting if we can manage it administratively.

> do that before the WG is chartered so we can move on smoothly from there.
>

So, we fight in a BoF over a charter which contains a problem statement, 
or fight in a WG over a problem statement document. In either case, the 
WG is beholden to and bound by the problem statement. Given the 
situtation we are in today, I don't think the problem statement can be 
decided within the structure of BoFs and unchartered efforts. That 
bridge has been walked over a couple of times already, any more and it 
will be burned.

> if we don't, there's little use in creating a WG..

All WGs are different. Obtaining consensus on the focus of the problem 
is probably the most difficult task for this particular case, which 
contributed to why the v6tc BoF didn't converge in time. In an ideal 
world, the problem-statement process goes smoothly and then the WG can 
get to the task of designing a protocol after. This situation is a bit 
reversed since so much protocol designing has already taken place.

- Mark

---

From: Pekka Savola <[email-masked]>
Date: Thu, 8 Sep 2005 12:03:43 +0300 (EEST)

On Thu, 8 Sep 2005, Mark Townsley wrote:
> So, we fight in a BoF over a charter which contains a problem statement, or 
> fight in a WG over a problem statement document. In either case, the WG is 
> beholden to and bound by the problem statement. Given the situtation we are 
> in today, I don't think the problem statement can be decided within the 
> structure of BoFs and unchartered efforts. That bridge has been walked over a 
> couple of times already, any more and it will be burned.

In this case, maybe the best approach would be to charter the WG to 
define first the problem statement/scenarios, and require re-charter 
to move forward from there to define the protocol or closing the WG?

That way, the number of questions at the IETF/IESG review of the 
proposed WG would be much lower as well -- as this has the benefit for 
allowing IETF-wide review and approval about the problem statement and 
the scenarios.  (Though I still think people like Dave Crocker will 
speak up and ask why this hasn't been prepared in advance :)

It would also make it clearer to the WG participants on the decision 
point and the technical direction, avoiding revisiting the choices 
made later on.

That way we could also omit some additional technical details from the 
charter (which depend on which scenarios are being addressed).

This is what has been done in the past with some efforts, for example 
CAPWAP and it seems the ISMS rechartering has similar resemblance as 
well though I haven't followed either group closely.

---

From: Mark Townsley <[email-masked]>
Date: Thu, 08 Sep 2005 12:54:46 +0200

Pekka Savola wrote:

>> So, we fight in a BoF over a charter which contains a problem 
>> statement, or fight in a WG over a problem statement document. In 
>> either case, the WG is beholden to and bound by the problem 
>> statement. Given the situtation we are in today, I don't think the 
>> problem statement can be decided within the structure of BoFs and 
>> unchartered efforts. That bridge has been walked over a couple of 
>> times already, any more and it will be burned.
>
>

So, in short, insert a recharter step between the problem statement and 
protocol definition. If we cannot come to consensus on the protocol 
definition pieces of the charter, I do see how this could be a good 
solution to expedite getting to work on the problem statement (which 
IMHO is a good thing). As for decision point clarity, I see your point, 
though I am expecting the Chairs to make that *very* clear to the WG, 
regardless of whether we recharter or not.

- Mark