Subject: RE: [Speermint] Speermint Charter

From: "Livingood, Jason" <[email-masked]>
Date: Sun, 2 Apr 2006 21:09:17 -0400

Here-here, Brian!  Excellent and well considered response. I recommend
to everyone that is in the thread that you re-read the charter very
carefully.  It is intended to be as specific as possible, while not
overly restrictive.

Suggest we focus on finishing the Terminology Draft as soon as we can.
So let's have it out on all of the terms there one more time.  Any terms
raised in Dallas that are not in the draft should be suggested by
someone.  Let's get every term in there and defined, as is reasonable
and appropriate to our work.

Regards
Jason

> -----Original Message-----
> From: Brian Rosen [mailto:[email-masked]] 
> Sent: Thursday, March 30, 2006 5:39 PM
> To: 'Stastny Richard'; 'Reinaldo Penno'; 'Malas, Daryl'; 
> 'Khan, Sohel Q [CTO]'
> Cc: [email-masked]
> Subject: RE: [Speermint] Speermint Charter
> 
> Wading in the middle:
> 
> Just for fun, I re-read our charter.  I came away saying 
> "that's pretty clear".  I now turn to this discussion and say 
> "please re-read the charter".
> 
> The charter is clear we are talking about all forms of real 
> time communications.  The charter doesn't explicitly rule out 
> one way (streaming) but I think we can assume it.  So, it's 
> not just voice.
> 
> The charter is clear we are talking about SIP.  We aren't 
> talking about XMPP for example or H.323.  The charter does 
> not discuss p2p SIP.  I believe that until there is a working 
> group on p2p SIP, and until that group produces some 
> interesting results, it's out of scope for us.  We're dealing 
> with proxy to proxy peering.
> 
> The charter is pretty clear that we are talking about BOTH 
> inter-carrier as well as any inter-domain peering.  I suppose 
> it could be clearer about that point.  I think 
> inter-enterprise VoIP, to take an example, without benefit of 
> a carrier, is probably in scope.  We could, within the group, 
> decide to treat carrier peering and other interdomain peering 
> separately.  It's not clear to me that we need to or should, 
> at least at the moment.  I don't think anyone can say "we are 
> NOT working on inter-carrier peering".
> Similarly, I don't believe we are limited to e.164 addresses. 
>  I think we include mapping of e.164s to SIP URIs within our 
> documents as one of the things a proxy may do.  I think we 
> can also be somewhat cavalier with the differences between 
> public ENUM, infrastructure/carrier ENUM and private ENUM.  I 
> don't think we even want to offer guidance on what to do when 
> more than one is available other than observing that such a 
> case will be common.
> 
> The charter is clear we are talking about BOTH the media and 
> the signaling.
> If you combine that with "inter-carrier vs inter-domain" then 
> you have BOTH the case of a direct media connection as well 
> as one that goes through
> (horrors) SBCs, even when two UAs are in the same hotel.  
> Most enterprises seem to like SBCs anyway.  Unless someone 
> gives me a really good explanation of why it actually matters 
> if they do run through SBCs with respect to our work, I think 
> we probably can ignore the difference.
> 
> Finally, in my checkered past, I have had many occasions to 
> observe the difference between a pile of documents that 
> purport to define interoperable implementations, and the 
> reality of actually achieving it.  While in general, in the 
> IETF, "profiles" are not a nice word, Best Current Practices
> are.  Our charter is clear we are to develop BCPs.   One of 
> the biggest
> values we can have on peering is to be VERY explicit about 
> what the (SIP) signaling looks like across the peering 
> points.  Remember, the wonderful thing about standards is 
> that there are so many to choose from.  There is no better 
> example of that than the area in which we find ourselves 
> here, and we CAN do something about making choices.  It's all 
> well and good to say "dip ENUM if you have an e.164, use SRV 
> to find the server for the domain of the URI, send an INVITE 
> there", but, in the real world, it's MUCH more complicated 
> then that, and our job is to describe all the dreck that you 
> really have to do.
> 
> I think our problem is more to define what we do first then 
> what we do.
> 
> Brian
> 
> -----Original Message-----
> From: Stastny Richard [mailto:[email-masked]]
> Sent: Thursday, March 30, 2006 5:07 PM
> To: Reinaldo Penno; Malas, Daryl; Khan, Sohel Q [CTO]
> Cc: [email-masked]
> Subject: Re: [Speermint] Speermint Charter
> 
> Hi Reinaldo,
>  
> inline
>  
> >>
> >> >I responded to soon before.  You have a good point.  So 
> what you are 
> >> >suggesting is peering can encompass multiple SIP based services 
> >> >(P2P, ENUM, SIMPLE, etc.), and should not be limited to basic SIP
> >telephony?
> >> >
> >> >Thanks...
> >>
> >> Thank you for bringing this up again and in focus
> >>
> >> The basic idea of SPEERMINT is to bring an SIP INVITE from 
> Provider 
> >> (or admin domain) A to B without immediately being rejected.
> >[[Reinaldo]]
> >
> >Hello Richard,
> >
> >If all we need is what you said above, then what we need is already 
> >defined in SIP/SIPPING, right? They already standardized 
> procedures for 
> >DNS lookup, etc, etc
> >
> >Let me rephrase the question by asking what is missing 
> instead of what 
> >is already defined. If we have two SIP domains, with the 
> DNSs properly 
> >SIPpenized, where the SIP border proxies are configured to 
> talk to each 
> >other, is there anything else needed besides what is in SIP/SIPPING?
> >
> >Is the policy piece the missing link?
> 
> I think so. And eventually a profile and minimum requirements 
> for interconnect
> 
> >Sorry, I'm trying to peel another layer to look under 
> "enabling to SIP 
> >messages between the two domains", "Layer 5 peering" and other 
> >expressions.
> >
> >I'm trying to understand what exactly is missing if all we 
> want is to 
> >enable Sip messages from domain A to reach B. Are today VoIP peering 
> >points just exchange of media or there is signaling going on as well?
> 
> Either signaling only or also signaling+media (called SBC)
> >
> >I think we should rephrase the charter to be much, much more 
> specific 
> >on what our goals are, the drafts we need and milestones.
> 
> Yes, and I think this discussion helped very much to make this clear
> 
> >Thanks,
> 
> Thank you
> Richard
> 
> 
> 
> _______________________________________________
> Speermint mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/speermint
> 

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

---

From: David Meyer <[email-masked]>
Date: Mon, 3 Apr 2006 11:39:41 -0700

> and appropriate to our work.

	Updates in the queue on the terminology draft. You should
	see the revision this week (I'm going to rename it, since
	we're removing the requirements stuff).

	Dave