Re: [Speermint] shutting down and the arch doc

["Peterson, Jon" <[e-mail]>]

I think this raises the question of what purpose we hope the architecture document will serve. I agree that it does not prescribe everything that two providers need to do in order to interconnect, but if we make that the scope of the architecture document, surely we'll never complete it. The question, I think, is not whether this completely describes your architecture, but whether it is -consistent-  with your architecture. What we need is a common core vision, something that lets us rely on the same picture when we talk about the architecture and interconnection. Having that is a -necessary- condition to describing what two providers need to do to interconnect, but I definitely agree it is not a -sufficient- condition.

This is a short document: it provides a diagram showing an ontology (the elements involved in peering) and the functions invoked by those elements. It tries to show, at a high level, how those elements interact in the execution of those functions. Honestly, for me that diagram alone justifies the existence of this document, since the terminology RFC lacks one. What we end up with here should be able to inform and constrain the ongoing discussion on how to provision these elements in the architecture. Certainly it could inform decisions about appropriate security design. It's not going to solve world hunger, but we need it to be able to make further progress on peering.

Jon Peterson
NeuStar, Inc.


On 6/3/10 10:51 AM, "DOLLY, MARTIN C (ATTLABS)" <[e-mail]> wrote:

Daryl

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

Sorry

Martin

________________________________
From: Daryl Malas <[e-mail]>
To: DOLLY, MARTIN C (ATTLABS); [e-mail] <[e-mail]>; [e-mail] <[e-mail]>; [e-mail] <[e-mail]>
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)" <[e-mail]> wrote:

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

________________________________
From: [e-mail] <[e-mail]>
To: Daryl Malas <[e-mail]>; Peterson, Jon <[e-mail]>; [e-mail] <[e-mail]>
Sent: Thu Jun 03 13:32:02 2010
Subject: Re: [Speermint] shutting down and the arch doc

Agree with that approach.

Mike



From: [e-mail] [mailto:[e-mail]] On Behalf Of Daryl Malas
Sent: Thursday, June 03, 2010 12:54 PM
To: Peterson, Jon; [e-mail]
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" <[e-mail]> 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.