[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Sip] (no subject)
> -----Original Message-----
> From: sip-bounces at ietf.org [mailto:sip-bounces at ietf.org] On Behalf Of
> Dean Willis
>
> The problem that I'm trying to solve is making the task space
> manageable.
> The first thing is to distribute the chair load.
Obviously splitting/spawning WG's will do that, but I thought there was an AD resource contention issue - if we had more WG meeting slots then neither of our AD's could be in some meeting or other. Is that not one of the issues? It was the response I got when I and others suggested SIP Security topics (Identity/Privacy/SIPS/Certs/etc.) should be split into a separate WG a while back.
There was also some concern over not having any more RAI time slots anyway, but I think that's a red herring and overlapping some RAI WG meeting times is reasonable for certain topics.
> I think developing a SIP extension should be a Big Thing. If it's
> important enough to develop a SIP extension for, it is probably
> important enough to charter a working group to develop that extension.
> It's a Really Bad Idea to have a standing working group that sits
> around and develops SIP extensions. All that gets us is a whole lot of
> extensions. It doesn't get us any closer to a draft standard.
I agree with you in principle, but I doubt it's possible in practice. There's some fine line there, because if you don't address an issue/need multiple people have, then they just go solve it in a proprietary fashion independently and interop still sucks. One problem is we don't have a single cohesivFrom sip-bounces at ietf.org Mon Jun 23 09:20:55 2008
Return-Path: <sip-bounces at ietf.org>
X-Original-To: sip-archive at optimus.ietf.org
Delivered-To: ietfarch-sip-archive at core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1])
by core3.amsl.com (Postfix) with ESMTP id DBE823A6A36;
Mon, 23 Jun 2008 09:20:55 -0700 (PDT)
X-Original-To: sip at core3.amsl.com
Delivered-To: sip at core3.amsl.com
Received: from localhost (localhost [127.0.0.1])
by core3.amsl.com (Postfix) with ESMTP id 240B03A6A47
for <sip at core3.amsl.com>; Mon, 23 Jun 2008 09:20:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.718
X-Spam-Level:
X-Spam-Status: No, score=-1.718 tagged_above=-999 required=5
tests=[AWL=-0.881, BAYES_00=-2.599, MISSING_SUBJECT=1.762]
Received: from mail.ietf.org ([64.170.98.32])
by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id TSQtPU41sy9f for <sip at core3.amsl.com>;
Mon, 23 Jun 2008 09:20:54 -0700 (PDT)
Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6])
by core3.amsl.com (Postfix) with ESMTP id 473633A6A31
for <sip at ietf.org>; Mon, 23 Jun 2008 09:20:54 -0700 (PDT)
Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com
(216.41.24.6) with Microsoft SMTP Server (TLS) id 8.1.263.0;
Mon, 23 Jun 2008 12:20:06 -0400
Received: from mail.acmepacket.com ([216.41.24.7]) by mail.acmepacket.com
([216.41.24.7]) with mapi; Mon, 23 Jun 2008 12:20:06 -0400
From: Hadriel Kaplan <HKaplan at acmepacket.com>
To: Dean Willis <dean.willis at softarmor.com>
Date: Mon, 23 Jun 2008 12:20:04 -0400
Thread-Index: AcjVTP6kGKI5M6CLTButn/b1hpoBwA==
Message-ID: <E6C2E8958BA59A4FB960963D475F7AC30BE3C778B0 at mail.acmepacket.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
MIME-Version: 1.0
Cc: "sip at ietf.org" <sip at ietf.org>
Subject: [Sip] (no subject)
X-BeenThere: sip at ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/sip>,
<mailto:sip-request at ietf.org?subject=unsubscribe>
List-Archive: <https://www.ietf.org/mailman/private/sip>
List-Post: <mailto:sip at ietf.org>
List-Help: <mailto:sip-request at ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sip>,
<mailto:sip-request at ietf.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: sip-bounces at ietf.org
Errors-To: sip-bounces at ietf.org
> -----Original Message-----
> From: sip-bounces at ietf.org [mailto:sip-bounces at ietf.org] On Behalf Of
> Dean Willis
>
> The problem that I'm trying to solve is making the task space
> manageable.
> The first thing is to distribute the chair load.
Obviously splitting/spawning WG's will do that, but I thought there was an AD resource contention issue - if we had more WG meeting slots then neither of our AD's could be in some meeting or other. Is that not one of the issues? It was the response I got when I and others suggested SIP Security topics (Identity/Privacy/SIPS/Certs/etc.) should be split into a separate WG a while back.
There was also some concern over not having any more RAI time slots anyway, but I think that's a red herring and overlapping some RAI WG meeting times is reasonable for certain topics.
> I think developing a SIP extension should be a Big Thing. If it's
> important enough to develop a SIP extension for, it is probably
> important enough to charter a working group to develop that extension.
> It's a Really Bad Idea to have a standing working group that sits
> around and develops SIP extensions. All that gets us is a whole lot of
> extensions. It doesn't get us any closer to a draft standard.
I agree with you in principle, but I doubt it's possible in practice. There's some fine line there, because if you don't address an issue/need multiple people have, then they just go solve it in a proprietary fashion independently and interop still sucks. One problem is we don't have a single cohesive "groupe "group" view and use of SIP, so we're left with the shotgun extensions approach, seeing which ones will stick. I can't recall another successful protocol this complicated that didn't have one or two dominant vendors, which is a huge disadvantage in some ways. It's both a blessing and a curse.
-hadriel
_______________________________________________
Sip mailing list https://www.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors at cs.columbia.edu for questions on current sip
Use sipping at ietf.org for new developments on the application of sip
" view and use of SIP, so we're left with the shotgun extensions approach, seeing which ones will stick. I can't recall another successful protocol this complicated that didn't have one or two dominant vendors, which is a huge disadvantage in some ways. It's both a blessing and a curse.
-hadriel
_______________________________________________
Sip mailing list https://www.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors at cs.columbia.edu for questions on current sip
Use sipping at ietf.org for new developments on the application of sip