Subject: [BLISS] IETF76 agenda

From: Shida Schubert <[email-masked]>
Date: Thu, 5 Nov 2009 17:07:30 +0900

All,

  As we haven't received sufficient agenda request,
we will no longer be meeting in Hiroshima for BLISS.

  Regards
   Shida

---

From: "Hutton, Andrew" <[email-masked]>
Date: Thu, 5 Nov 2009 10:05:49 +0100

Hi Shida,

I think that the BLISS group should meet and we should add to the agenda an item to discuss the future of the working group. It seems clear that BLISS has lost focus and the charter is well out of date.

Maybe the issue is that given the format of the DISPATCH working group that BLISS is now irrelevant because in documenting SIP services it is almost always the case that some extension to SIP is needed or maybe the world has changed and nobody wants the drafts that BLISS is creating anymore.

Even if it is only a small number of people that attend I think there should still a session to discuss the way forward.

Regards
Andy

>-----Original Message-----
>From: [email-masked] [mailto:[email-masked]]
>On Behalf Of Shida Schubert
>Sent: 05 November 2009 08:08
>To: [email-masked]
>Subject: [BLISS] IETF76 agenda
>
>
>All,
>
>_______________________________________________
>BLISS mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/bliss
>

---

From: Shida Schubert <[email-masked]>
Date: Thu, 5 Nov 2009 21:01:58 +0900

Andy;

  Thanks for your feedback, I have been exchanging
re-chartering text with AD for the last while (since before
IETF75), trying to reflect the structure changes in RAI.

  Scott has now picked up the pen and has been working on
revising the charter which I believe addresses some of the
dilemma that BLISS has faced due to its current charter.

  Anyhow, I sympathize with a lot of what you have stated
below, and agree that format of DISPATCH has possibly
made BLISS less attractive to bring things in because
of the limitation and restriction BLISS currently has (Only
able to define limited extensions), but the revised charter
if accepted will make the difference and I think will make
BLISS home for some of the items that are being
discussed in DISPATCH (Session-Recording etc.).

  Regretfully I have already canceled the agenda time
just after I sent out the previous e-mail but I will see if
anything can be done about that.

  Many Thanks
   Shida

On Nov 5, 2009, at 6:05 PM, Hutton, Andrew wrote:

> Hi Shida,
>
> I think that the BLISS group should meet and we should add to the  
> agenda an item to discuss the future of the working group. It seems  
> clear that BLISS has lost focus and the charter is well out of date.
>
> Maybe the issue is that given the format of the DISPATCH working  
> group that BLISS is now irrelevant because in documenting SIP  
> services it is almost always the case that some extension to SIP is  
> needed or maybe the world has changed and nobody wants the drafts  
> that BLISS is creating anymore.
>
> Even if it is only a small number of people that attend I think  
> there should still a session to discuss the way forward.
>
> Regards
> Andy
>
>
>

---

From: "Hutton, Andrew" <[email-masked]>
Date: Thu, 5 Nov 2009 13:07:20 +0100

Hi,

Ok so can we see the proposed new charter text or at least some details of what is proposed and we can arrange an informal meeting of interested parties to discuss the way forward in Hiroshima.

Regards
Andy

>From: Shida Schubert [mailto:[email-masked]]
>Sent: 05 November 2009 12:02
>To: Hutton, Andrew
>Cc: [email-masked]
>Subject: Re: [BLISS] IETF76 agenda
>
>
>Andy;
>

---

From: Shida Schubert <[email-masked]>
Date: Thu, 5 Nov 2009 21:23:04 +0900

Here is the most recent version that Scott has
been working on..

http://svn.resiprocate.org/rep/ietf-drafts/lawrence/bliss-charter/charter.txt

  BTW target date hasn't been changed in this version yet.

  Regards
   Shida

On Nov 5, 2009, at 9:07 PM, Hutton, Andrew wrote:

> Hi,
>
> Ok so can we see the proposed new charter text or at least some  
> details of what is proposed and we can arrange an informal meeting  
> of interested parties to discuss the way forward in Hiroshima.
>
> Regards
> Andy
>
>

---

From: "Scott Lawrence" <[email-masked]>
Date: Thu, 05 Nov 2009 10:16:34 -0500

> http://svn.resiprocate.org/rep/ietf-drafts/lawrence/bliss-charter/charter.txt

As it happens, I was editing it again at about the same time Shida was
sending that mail, so if you looked quickly, you may want to look again.
That latest diff is at [1].

>   BTW target date hasn't been changed in this version yet.

In the section on current work, the only changes I've proposed so far
are some expansions of some undefined acronyms into what I hope are
generic descriptions of the features the acronyms were meant to name.
Dates that are now in the past will obviously need to change, but I have
not hazarded any guesses on those yet.

> > of interested parties to discuss the way forward in Hiroshima.

I will not, alas, be in Hiroshima.  I am of course interested in any
comments on the proposed text.  Note that this has not be reviewed yet
by anyone outside Shida and our ADs, so it is not yet in any way
official... there's a process for changing the charter text - this
announcement is, I guess, part of that - call for community review...

---

From: "Scott Lawrence" <[email-masked]>
Date: Thu, 05 Nov 2009 10:19:20 -0500

> That latest diff is at [1].

Forgot the footnote:

[1] http://tools.ietf.org/rfcdiff?url1=http://bit.ly/31shzt&url2=http://svn.resiprocate.org/rep/ietf-drafts/lawrence/bliss-charter/charter.txt

---

From: "Hutton, Andrew" <[email-masked]>
Date: Sun, 8 Nov 2009 00:31:36 +0100

Hi,

I like the proposed new charter I think it makes it very clear what the rules are for work items in BLISS.

One question I have is should we need evidence of real running code and interoperability before releasing BLISS drafts as RFC's.

I don't think it would be good if the BLISS group was to analyse existing implementations and then define a new but hopefully more interoperable mechanism but then find that nobody implements it.

Could we have something in the charter that requires real evidence of interoperability before a draft can be released as an RFC or would this be going to far ?

Regards
Andy

>On Behalf Of Scott Lawrence
>Sent: 05 November 2009 15:19
>To: Shida Schubert
>Cc: [email-masked]
>[1]
>http://tools.ietf.org/rfcdiff?url1=http://bit.ly/31shzt&url2=ht
>tp://svn.resiprocate.org/rep/ietf-drafts/lawrence/bliss-charter
>/charter.txt
>

---

From: "Scott Lawrence" <[email-masked]>
Date: Sun, 08 Nov 2009 17:33:27 -0500

On Sun, 2009-11-08 at 00:31 +0100, Hutton, Andrew wrote:
> One question I have is should we need evidence of real running code
> and interoperability before releasing BLISS drafts as RFC's.
> 
> I don't think it would be good if the BLISS group was to analyse
> existing implementations and then define a new but hopefully more
> interoperable mechanism but then find that nobody implements it.
> 
> Could we have something in the charter that requires real evidence of
> interoperability before a draft can be released as an RFC or would
> this be going to far ?

Well, BCP 9 (RFC 2026) already has descriptions of the place of running
code in the standards track maturity levels.  In the description of
Proposed Standard:

   Usually, neither implementation nor operational experience is
   required for the designation of a specification as a Proposed
   Standard.  However, such experience is highly desirable, and will
   usually represent a strong argument in favor of a Proposed Standard
   designation.

and the next level leads with it:

   A specification from which at least two independent and interoperable
   implementations from different code bases have been developed, and
   for which sufficient successful operational experience has been
   obtained, may be elevated to the "Draft Standard" level.

There have been a lot of specifications published as RFCs out of the SIP
related working groups without any running code - there are a number
that have been RFCs for years that still don't have any running code
that I know of, and many more that lack significant deployment.  Far be
it from me to argue that that is a good thing, but I don't think that
the place to change the rules is in the charter of just one working
group.

Given that interoperability of features is the mission of BLISS, the
ability to demonstrate it in real code is especially relevant, but I
think it's also worth recognizing that in many (perhaps even most) cases
BLISS features will face a difficult hurdle: the features in question
are often essential, so most commercial implementations will already
have pre-standard (and presumably not interoperable) implementations of
the feature.  Unless the new standard version has compelling advantages
(and being "standard" probably won't be compelling), it may take some
time to convince product managers that it is worth spending precious
development resources to re-implement a feature they already have.

While I argue that requiring running code shouldn't be a criterion in
the charter, I do think that it should be a central part of the working
group process.  I've already had discussions with Robert about setting
up testing/demonstration sessions at SIPit for BLISS-developed
features.