Re: [Speermint] shutting down and the arch doc

Daryl Malas <D.Malas@cablelabs.com> Mon, 14 June 2010 18:51 UTC

Return-Path: <D.Malas@cablelabs.com>
X-Original-To: speermint@core3.amsl.com
Delivered-To: speermint@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E51243A68DA for <speermint@core3.amsl.com>; Mon, 14 Jun 2010 11:51:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 2.637
X-Spam-Level: **
X-Spam-Status: No, score=2.637 tagged_above=-999 required=5 tests=[AWL=-0.500, BAYES_60=1, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, HTML_MESSAGE=0.001]
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 f0yhCJWO50uS for <speermint@core3.amsl.com>; Mon, 14 Jun 2010 11:51:34 -0700 (PDT)
Received: from ondar.cablelabs.com (ondar.cablelabs.com [192.160.73.61]) by core3.amsl.com (Postfix) with ESMTP id 77BE63A68A3 for <speermint@ietf.org>; Mon, 14 Jun 2010 11:51:33 -0700 (PDT)
Received: from kyzyl.cablelabs.com (kyzyl [10.253.0.7]) by ondar.cablelabs.com (8.14.4/8.14.4) with ESMTP id o5EIpXuM021577; Mon, 14 Jun 2010 12:51:33 -0600
Received: from srvxchg.cablelabs.com (10.5.0.15) by kyzyl.cablelabs.com (F-Secure/fsigk_smtp/303/kyzyl.cablelabs.com); Mon, 14 Jun 2010 12:51:33 -0700 (MST)
X-Virus-Status: clean(F-Secure/fsigk_smtp/303/kyzyl.cablelabs.com)
Received: from srvxchg.cablelabs.com ([10.5.0.15]) by srvxchg ([10.5.0.15]) with mapi; Mon, 14 Jun 2010 12:51:34 -0600
From: Daryl Malas <D.Malas@cablelabs.com>
To: Daryl Malas <D.Malas@cablelabs.com>, "DOLLY, MARTIN C (ATTLABS)" <md3135@att.com>, "hmmr@cisco.com" <hmmr@cisco.com>, "jon.peterson@neustar.biz" <jon.peterson@neustar.biz>, "speermint@ietf.org" <speermint@ietf.org>, "DALY, BRIAN K (ATTCINW)" <BD2985@att.com>
Date: Mon, 14 Jun 2010 12:51:31 -0600
Thread-Topic: [Speermint] shutting down and the arch doc
Thread-Index: Acr9zWp60wKwPsoCM0iMEyCTYZ/liQFb/f+dAAFRMeAAACQuQgAAUgJ3AAA7IyYAACPuBgIrJ4cR
Message-ID: <C83BD653.CAF0%d.malas@cablelabs.com>
In-Reply-To: <C82D48BF.C78F%d.malas@cablelabs.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-Entourage/13.5.0.100510
acceptlanguage: en-US
Content-Type: multipart/alternative; boundary="_000_C83BD653CAF0dmalascablelabscom_"
MIME-Version: 1.0
X-Approved: ondar
Subject: Re: [Speermint] shutting down and the arch doc
X-BeenThere: speermint@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Mailing list for the speermint working group <speermint.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/speermint>, <mailto:speermint-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/speermint>
List-Post: <mailto:speermint@ietf.org>
List-Help: <mailto:speermint-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/speermint>, <mailto:speermint-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 14 Jun 2010 18:51:40 -0000

Martin,

Can we assume there is nothing specific about the architecture that is a problem?  If there is, please let us know.  I am simply trying to close this issue.

Regards,

Daryl


On 6/3/10 11:55 AM, "Daryl Malas" <d.malas@cablelabs.com> wrote:

Martin,

So, the architecture describes an SF (SIP Proxy) and SBE (SBC) in each SIP Service Providers’ networks.  It describes a route look-up via ENUM or SIP Redirect to determine for the given TN the route for the target peers SBC using SIP.  How is this not done today?

Regards,

Daryl


On 6/3/10 11:51 AM, "DOLLY, MARTIN C (ATTLABS)" <md3135@att.com> wrote:

Daryl

I do not know how 2 providers can interconnect based on this

Sorry

Martin

________________________________
From: Daryl Malas <D.Malas@cablelabs.com>
To: DOLLY, MARTIN C (ATTLABS); hmmr@cisco.com <hmmr@cisco.com>; jon.peterson@neustar.biz <jon.peterson@neustar.biz>; speermint@ietf.org <speermint@ietf.org>
Sent: Thu Jun 03 13:45:05 2010
Subject: Re: [Speermint] shutting down and the arch doc

Martin,

Your implication is the architecture is not well understood.  In an effort to move that draft forward quickly, can you please provide more concrete feedback on it?

Also, while I agree there may still be some definition to be created regarding the architecture, security around specific protocols should be fairly straightforward.  Again, as with the architecture draft, please provide feedback specific to the areas of the security you feel cannot be addressed yet.

Thanks,

Daryl


On 6/3/10 11:35 AM, "DOLLY, MARTIN C (ATTLABS)" <md3135@att.com> wrote:

We agree, but to address security without understanding the architecture is mindless

________________________________
From: speermint-bounces@ietf.org <speermint-bounces@ietf.org>
To: Daryl Malas <D.Malas@cablelabs.com>; Peterson, Jon <jon.peterson@neustar.biz>; speermint@ietf.org <speermint@ietf.org>
Sent: Thu Jun 03 13:32:02 2010
Subject: Re: [Speermint] shutting down and the arch doc

Agree with that approach.

Mike



From: speermint-bounces@ietf.org [mailto:speermint-bounces@ietf.org] On Behalf Of Daryl Malas
Sent: Thursday, June 03, 2010 12:54 PM
To: Peterson, Jon; speermint@ietf.org
Subject: Re: [Speermint] shutting down and the arch doc

Jon et. al,

I agree we should finish the architecture document.  If members of this mailing list and the working group think it requires greater definition around certain functions, then please contribute.  I would like to suggest we focus on two drafts to wrap up in Maastricht:

Architecture
Security

After completing these two drafts, we shut down the working group by Beijing.

Thoughts?

Regards,

Daryl



On 5/27/10 12:50 PM, "Peterson, Jon" <jon.peterson@neustar.biz> wrote:

While all IETF working groups look forward to the day they can close their doors, I’m not sure I’d be happy to see SPEERMINT make its final bow without completing the architecture document.

I believe that in the LUF/LRF distinction, the SPEERMINT group has captured an idea that is valuable, and moreover one which, as the original charter of this group intended, identifies a reality of deployments that the standards community had previously ignored. It explodes the conceit that a one-step resolution process, just transforming a telephone number into a “global” URI, will address the needs of the sort of peering communities this group examines. While the distinction between LUF and LRF is not a precise one, and has never been immensely well understood, I contend that it is valuable nonetheless, and that if confusion about the idea prompts us to discard the work in SPEERMINT, I have no reason to expect anything different to happen in DRINKS or any other group that must operate on these same architectures. I don’t think the sketches in the terminology draft suffice as a foundation for that work.

Finishing the architecture document is not solving world hunger. While everything in the IETF takes much longer than you’d imagine, I don’t think this has to be one or two years out – I think it would be reasonable to make a final push to clear up the snags in the document, and just set a deadline by which this group will emit it as an Informational. It doesn’t have to be perfect, it just has to be able to serve as the framework for the subsequent discussions in DRINKS and other future arenas. I think this is an an achievable, and relatively honorable, way to round up the work that the SPEERMINT charter originally laid out.

If there is enough energy here for one last jaunt, I’d be happy to assist that effort in any capacity.

Jon Peterson
NeuStar, Inc.