Subject: RE: [Speermint] Updated Draft: SPEERMINT Peering Architecture

From: "Stastny Richard" <[email-masked]>
Date: Wed, 24 May 2006 13:33:55 +0200

>Yes, and presentation restriction,
>So 3261, 3263, 3325 and 3326.
>Sold!

Bought! ;-)
If anybody has any additions to this
(for minimum requirements), he may holler

IMHO in addition a BCP on the population of the
header fields, particularly in context with phone numbers
(e.164 and non-E.164) is required.

A BCP on how to establish two-way TLS may also
be useful

Richard

________________________________

Von: Francois D. Menard [mailto:[email-masked]]
Gesendet: Mi 24.05.2006 13:03
An: Stastny Richard
Betreff: RE: [Speermint] Updated Draft: SPEERMINT Peering Architecture

Yes, and presentation restriction,
So 3261, 3263, 3325 and 3326.
Sold!
F.

--
François D. Ménard
Chargé de projet
Xit télécom inc.
1350 rue Royale #800
Trois-Rivières, QC, G9A 4J4
Canada
[email-masked]
Tel: (819) 374-2556 ext. 268
Fax: (819) 374-0395
Cell: (819) 692-1383

-----Original Message-----
From: Stastny Richard [mailto:[email-masked]]
Sent: 24 mai 2006 04:19
To: Michael Hammer (mhammer); Brian Rosen; Francois D. Menard; Khan, Sohel Q
[CTO]; David Meyer; [email-masked]
Subject: RE: [Speermint] Updated Draft: SPEERMINT Peering Architecture

> A least common denominator set will likely be small, but perhaps not
> sufficiently rich for any two wishing to peering.
>
e.g. RFC3261 and 3263 ;-)

plus TLS and one kind of asserted identity

additional richness could be provided by policy records

Richard

> Mike
>
>
> > -----Original Message-----
> > From: Stastny Richard [mailto:[email-masked]]
> > Sent: Tuesday, May 23, 2006 4:54 PM
> > To: Michael Hammer (mhammer); Brian Rosen; Francois D.
> > Menard; Khan, Sohel Q [CTO]; David Meyer; [email-masked]
> > Subject: Re: [Speermint] Updated Draft: SPEERMINT Peering
Architecture
> >
> > >I think the the interworking of SIP to PSTN is out of scope here.
> >
> > Yes
> > I did not find anything about this in the charter.
> > It is not even mentioned in the out-of-scope section (which mentions
> > at least H.323 ;-)
> >
> > >While coloring within those lines, the next question is
> > whether there
> > >is a single subset that can be defined or whether there will
> > be many.
> > >I am betting on many, probably a different set for each
> > federation or
> > >even bilateral pairing that might exist.
> >
> > I always had the idea that we could define minimum requrements
> > (which could be the overlap of the many subsets) but maybe I am
> > asking too much Or is SIP already as baroque at OSI FTAM was?
> > (where we could only find bilateral "peerings" between DEC, IBM and
> > Siemens, but not a subset with worked with all three ;-)
> >
> > Richard
> >
> >
> > ________________________________
> >
> > Von: Michael Hammer (mhammer) [mailto:[email-masked]]
> > Gesendet: Di 23.05.2006 22:32
> > An: Brian Rosen; Francois D. Menard; Khan, Sohel Q [CTO]; David
> > Meyer; [email-masked]
> > Betreff: RE: [Speermint] Updated Draft: SPEERMINT Peering
Architecture
> >
> >
> >
> > Brian,
> >
> > I think the the interworking of SIP to PSTN is out of scope here. 
> > The issue is whether two peers, once they have discovered each
> > other, can know what subset of SIP they need to support.  I don't
> > think there is any need to go down the rabbit hole on what
> > applications are supported and whether they are PSTN emulations or
> > simulations or whatever.  We may know in the back of our mind that
> > some application won't work if RFC X is not supported, but we don't
> > need to discuss that.
> >  We need only to focus on what SIP RFCs are needed on the SIP peer
> > interface.
> >
> > While coloring within those lines, the next question is whether
> > there is a single subset that can be defined or whether there will
> > be many.  I am betting on many, probably a different set for each
> > federation or even bilateral pairing that might exist.  That could
> > be another rabbit hole.
> > I would be happy if two peers could point to the same subset and
> > agree to use it, no matter how many subsets might exist.
> >
> > Mike
> >
> >
> > > -----Original Message-----
> > > From: Brian Rosen [mailto:[email-masked]]
> > > Sent: Tuesday, May 23, 2006 3:05 PM
> > > To: 'Francois D. Menard'; Michael Hammer (mhammer); 'Khan, Sohel Q
> > > [CTO]'; 'David Meyer'; [email-masked]
> > > Subject: RE: [Speermint] Updated Draft: SPEERMINT Peering
> > Architecture
> > >
> > > By far the largest mistake EVER made by the IETF in the
> > development of
> > > SIP was to allow SIP to be extended to imitate the existing
> > PSTN.  If
> > > we ever were to start again, the golden rule would be DON'T
IMITATE
> > > THE PSTN, and the corollary would be "Just because the PSTN does
it
> > > that way DOES NOT MEAN it's a good idea".
> > >
> > > So, the very idea that "replication of functionality in the
> > > SS7 minimum message set" is the definition of what we need
> > to do makes
> > > me want to puke.
> > >
> > > No, and a pox on your houses for even thinking that.
> > >
> > > While we're going to start with "basic call", we need to
> > define those
> > > call features that must cross domain boundaries.
> > >  Most of them have existing SIP messaging (in sip-examples, for
> > > instance).  We need to make sure those features work across the
> > > boundary.  That has nothing whatsoever to do with an SS7
> > message.  The
> > > mms might give us clues on what features might be
> > interesting to put
> > > on our list, but I'll bet we end up with a lot less of them, and a
> > > bunch of stuff not in SS7 (or C7); inter-domain presence,
> > for example.
> > >
> > > Brian
> > >
> > > -----Original Message-----
> > > From: Francois D. Menard [mailto:[email-masked]]
> > > Sent: Tuesday, May 23, 2006 2:50 PM
> > > To: 'Michael Hammer (mhammer)'; 'Khan, Sohel Q [CTO]';
> > 'David Meyer';
> > > [email-masked]
> > > Subject: RE: [Speermint] Updated Draft: SPEERMINT Peering
> > Architecture
> > >
> > > > I don't see anything diametrically opposed between what I
> > suggested
> > > > and
> > > what you are suggesting.
> > >
> > > I would be satisfied with this:
> > >
> > > SPEERMINT compliance requires replication of the functionality
> > > available in the SS7 minumum message set which can be done by SIP,
> > > 3323, 3325.  Better than SS7 mms functionlality made possible with
> > > ATIS, IP Sphere or other sip profiles will also be considered as
> > > SPEERMIT compliant.
> > >
> > > > If there is to be an IETF-approved SIP profile, I think it
should
> > > > first be
> > > decided if that is the turf of the Speermint or the SIP WG.
> > > Those last two statements are at the heart of my concerns.
> > >
> > > SPEERMINT will be completely toothless as an RFC if it just
states,
> > > compliance with SPEERMINT can be achieved by compliance
> > with non-IETF
> > > standards.
> > >
> > > F.
> > >
> > >
> > > _______________________________________________
> > > Speermint mailing list
> > > [email-masked]
> > > https://www1.ietf.org/mailman/listinfo/speermint
> > >
> >
> > _______________________________________________
> > 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: "James McEachern" <[email-masked]>
Date: Thu, 25 May 2006 15:26:50 -0400

The original proposal that Francois made was that the minimum set of RFCs was "SIP + RFC 3323 and RFC 3325".  It appears that RFC 3323 has been dropped from this list, but I don't recall seeing why.  Have I missed something?

Jim

-----Original Message-----
From: Stastny Richard [mailto:[email-masked]] 
Sent: Wednesday, May 24, 2006 7:34 AM
To: Francois D. Menard; [email-masked]
Subject: RE: [Speermint] Updated Draft: SPEERMINT Peering Architecture

Bought! ;-)

Richard

-----Original Message-----
From: Stastny Richard [mailto:[email-masked]]
Sent: 24 mai 2006 04:19
To: Michael Hammer (mhammer); Brian Rosen; Francois D. Menard; Khan, Sohel Q

Richard

Architecture
Architecture
IMITATE
it
should
states,

---

From: "Brian Rosen" <[email-masked]>
Date: Thu, 25 May 2006 17:09:40 -0400

Give me an argument about why all of what is called "core sip" in
hitchhiker's guide is not in this list?

This would be:
   RFC 3261: The Session Initiation Protocol 

   RFC 3263: Locating SIP Servers 

   RFC 3265: SIP-Specific Event Notification 

   RFC 3323: A Privacy Mechanism for the Session Initiation Protocol
   (SIP)

   RFC 3325: Private Extensions to SIP for Asserted Identity within
   Trusted Networks 

   RFC 3327: SIP Extension Header Field for Registering Non-Adjacent
   Contacts

   RFC 3581: An Extension to SIP for Symmetric Response Routing 

   RFC 4320: Actions Addressing Issues Identified with the Non-INVITE
   Transaction in SIP

   RFC XXXX: Enhancements for Authenticated Identity Management in SIP
   aka "SIP Identity"

   RFC XXXX: Obtaining and Using Globally Routable User Agent
   Identifiers (GRUU) in SIP (S) 

   RFC XXXX: Managing Client Initiated Connections through SIP aka "SIP
outbound"

Possibly GRUU doesn't need to be there, although I suspect it does.

I think we also have ENUM, PRACK, UPDATE, Reason, and probably a few others.

-----Original Message-----
From: James McEachern [mailto:[email-masked]] 
Sent: Thursday, May 25, 2006 3:27 PM
To: Stastny Richard; Francois D. Menard; [email-masked]
Subject: RE: [Speermint] Updated Draft: SPEERMINT Peering Architecture

The original proposal that Francois made was that the minimum set of RFCs
was "SIP + RFC 3323 and RFC 3325".  It appears that RFC 3323 has been
dropped from this list, but I don't recall seeing why.  Have I missed
something?

Jim

-----Original Message-----
From: Stastny Richard [mailto:[email-masked]] 
Sent: Wednesday, May 24, 2006 7:34 AM
To: Francois D. Menard; [email-masked]
Subject: RE: [Speermint] Updated Draft: SPEERMINT Peering Architecture

Bought! ;-)

Richard

-----Original Message-----
From: Stastny Richard [mailto:[email-masked]]
Sent: 24 mai 2006 04:19
To: Michael Hammer (mhammer); Brian Rosen; Francois D. Menard; Khan, Sohel Q

Richard

Architecture
Architecture
IMITATE
it
should
states,

---

From: "Francois D. Menard" <[email-masked]>
Date: Thu, 25 May 2006 22:47:19 -0400

James,

Goof, meant to say 3261, 3323 and 3325 and we can throw in 3263 when people
want to do it with public enum.

F. 

-----Original Message-----
From: James McEachern [mailto:[email-masked]] 
Sent: 25 mai 2006 15:27
To: Stastny Richard; Francois D. Menard; [email-masked]
Subject: RE: [Speermint] Updated Draft: SPEERMINT Peering Architecture

Jim

-----Original Message-----
From: Stastny Richard [mailto:[email-masked]]
Sent: Wednesday, May 24, 2006 7:34 AM
To: Francois D. Menard; [email-masked]
Subject: RE: [Speermint] Updated Draft: SPEERMINT Peering Architecture

Bought! ;-)

IMHO in addition a BCP on the population of the header fields, particularly
in context with phone numbers
(e.164 and non-E.164) is required.

A BCP on how to establish two-way TLS may also be useful

Richard

-----Original Message-----
From: Stastny Richard [mailto:[email-masked]]
Sent: 24 mai 2006 04:19
To: Michael Hammer (mhammer); Brian Rosen; Francois D. Menard; Khan, Sohel Q

Richard

Architecture
Architecture
IMITATE
it
should
states,

---

From: "Francois D. Menard" <[email-masked]>
Date: Thu, 25 May 2006 22:55:46 -0400

> RFC 3261: The Session Initiation Protocol 
That is in my list

>RFC 3263: Locating SIP Servers 

That presumes that SIP servers will be discoverable and is thus a feature
beyond the scope of the SS7 MMS which requires manual provisioning of the
interconnection points.

>   RFC 3265: SIP-Specific Event Notification 

That's better than the MMS in ISUP?
>   RFC 3323: A Privacy Mechanism for the Session Initiation Protocol  (SIP)

That is in my list

Trusted Networks 

That is in my list

Contacts

Better than the mms in ISUP thus not needed?

>   RFC 3581: An Extension to SIP for Symmetric Response Routing 

Better than the mms in ISUP thus not needed?

Transaction in SIP

Same..

   aka "SIP Identity"

Same...

Same...

outbound"

Same...

> Possibly GRUU doesn't need to be there, although I suspect it does.

Same...

> I think we also have ENUM, PRACK, UPDATE, Reason, and probably a few
others.

Same...

F.

-----Original Message-----
From: James McEachern [mailto:[email-masked]]
Sent: Thursday, May 25, 2006 3:27 PM
To: Stastny Richard; Francois D. Menard; [email-masked]
Subject: RE: [Speermint] Updated Draft: SPEERMINT Peering Architecture

Jim

-----Original Message-----
From: Stastny Richard [mailto:[email-masked]]
Sent: Wednesday, May 24, 2006 7:34 AM
To: Francois D. Menard; [email-masked]
Subject: RE: [Speermint] Updated Draft: SPEERMINT Peering Architecture

Bought! ;-)

Richard

-----Original Message-----
From: Stastny Richard [mailto:[email-masked]]
Sent: 24 mai 2006 04:19
To: Michael Hammer (mhammer); Brian Rosen; Francois D. Menard; Khan, Sohel Q

Richard

Architecture
Architecture
IMITATE
it
should
states,