RE: [Speermint] Location Function in SPEERMINT

["Michael Hammer \(mhammer\)" <[e-mail]>]

I think I have lost track of what "it" is.

I don't think "it" is the ability to identify a proxy that a peer should
use based on location.

"It" may be the ability to identify a proxy that a peer should use based
on the peer identity or affiliation (federation).

"Location" has geographic baggage when perhaps selective "discovery" is
really what is meant.

Please correct me as I may have gotten disoriented with the different
mail threads.

Mike


> -----Original Message-----
> From: James McEachern [mailto:[e-mail]] 
> Sent: Friday, May 26, 2006 11:16 AM
> To: Michael Hammer (mhammer); [e-mail]
> Subject: RE: [Speermint] Location Function in SPEERMINT
> 
> So are you saying that it should be a requirement?
> 
> -----Original Message-----
> From: Michael Hammer (mhammer) [mailto:[e-mail]]
> Sent: Friday, May 26, 2006 10:52 AM
> To: McEachern, James [CAR:5N00:EXCH]; Reinaldo Penno; Stastny 
> Richard; [e-mail]; 
> [e-mail]; Brian Rosen; Francois D. Menard; 
> Khan, Sohel Q [CTO]; David Meyer; [e-mail]
> Subject: RE: [Speermint] Location Function in SPEERMINT
> 
> Distance is dead IF the proxy does not have strong ties to a 
> media anchor point.  If there is such a media anchor point, 
> then choosing ones that are close to calling and called 
> parties will aid in finding shortest routes between parties.
> 
> However, I am not advocating for or against such media 
> anchors, just simply recognizing that they may exist 
> depending on a domain's architecture.
> 
> There may be other reasons that peers are directed to one 
> proxy over another.  It is useful for the domain to designate 
> which proxies peers should use.
> 
> Mike
> 
> 
> > -----Original Message-----
> > From: James McEachern [mailto:[e-mail]]
> > Sent: Friday, May 26, 2006 10:44 AM
> > To: Reinaldo Penno; Stastny Richard;
> > [e-mail]; Michael Hammer (mhammer); 
> > [e-mail]; Brian Rosen; Francois D. Menard; Khan, 
> > Sohel Q [CTO]; David Meyer; [e-mail]
> > Subject: RE: [Speermint] Location Function in SPEERMINT
> > 
> > >This tells you the SIP proxy to be contacted. It does not
> > tell you if
> > >this the closest Sip Proxy handling @example.com users. It 
> also does 
> > >not tell you if it is the closest proxy to the callee.
> > 
> > Is the ability to "identify the closest proxy" a requirement for 
> > Speermint?  Many people have pointed out that distance is 
> dead, or at 
> > least should be, so it isn't clear to me that we really care. The 
> > Requirements and Terminology draft doesn't explicitly say, but my 
> > reading of section 5.2 implies this is not a requirement.
> > 
> > That having been said, I don't necessarily have strong views either 
> > way.  I'd just like to be clear on whether or not it is a 
> requirement.
> > 
> > Jim
> > 
> > 
> > -----Original Message-----
> > From: Reinaldo Penno [mailto:[e-mail]]
> > Sent: Thursday, May 25, 2006 5:00 PM
> > To: Stastny Richard; [e-mail]; Michael Hammer 
> > (mhammer); [e-mail]; Brian Rosen; Francois D. 
> > Menard; Khan, Sohel Q [CTO]; David Meyer; [e-mail]
> > Subject: RE: [Speermint] Location Function in SPEERMINT
> > 
> > I believe it is enough. You could refine it but I might sure of the 
> > benefits. Maybe this problem was already solved somewhere 
> and I'm not 
> > aware.
> > 
> > For example, The UAs would care.
> > 
> > >From RFC3263
> > 
> > ;;          Priority Weight Port   Target
> >        IN SRV  0        1      5060   server1.example.com
> >        IN SRV  0        2      5060   server2.example.com
> > 
> > This tells you the SIP proxy to be contacted. It does not 
> tell you if 
> > this the closest Sip Proxy handling @example.com users. It 
> also does 
> > not tell you if it is the closest proxy to the callee.
> > 
> > In the case of a carriers providing VoIP service to a user, if this 
> > provider A peers with provider B in two different 
> locations, which one 
> > to choose to send to forward the call?
> > 
> > Regards,
> > 
> > Reinaldo
> > 
> > > -----Original Message-----
> > > From: Stastny Richard [mailto:[e-mail]]
> > > Sent: Thursday, May 25, 2006 1:52 PM
> > > To: Reinaldo Penno; [e-mail]; Michael Hammer
> > (mhammer);
> > > [e-mail]; Brian Rosen; Francois D. Menard; Khan,
> > Sohel Q
> > > [CTO]; David Meyer; [e-mail]
> > > Subject: Re: [Speermint] Location Function in SPEERMINT
> > > 
> > > Reinaldo said:
> > > >That's maybe one of the most important issues. This could be
> > complicated
> > > >by the geographically dispersed networks with several 
> entry points.
> > > >Although this might be an interesting problem it might be
> > a rathole.
> > > 
> > > So you say RFC 3263 is not enough, something is missing?
> > > e.g. the geographic location of originating and terminating
> >  --- what?
> > > 
> > > -SIP proxy? who cares
> > > -SBC?
> > > -UA?
> > > 
> > > So we are again dealing with SBCs, in this case the 
> geo-location of
> > these
> > > -- rats, holes ;-)
> > > 
> > > Richard
> > > 
> > > 
> > > ________________________________
> > > 
> > > Von: Reinaldo Penno [mailto:[e-mail]]
> > > Gesendet: Do 25.05.2006 22:37
> > > An: Stastny Richard; [e-mail]; Michael Hammer
> > (mhammer);
> > > [e-mail]; Brian Rosen; Francois D. Menard; Khan,
> > Sohel Q
> > > [CTO]; David Meyer; [e-mail]
> > > Betreff: RE: [Speermint] Location Function in SPEERMINT
> > > 
> > > 
> > > 
> > > 
> > > 
> > > > -----Original Message-----
> > > > From: Stastny Richard [mailto:[e-mail]]
> > > > Sent: Thursday, May 25, 2006 1:26 PM
> > > > To: [e-mail]; Michael Hammer (mhammer); 
> > > > [e-mail]; Brian Rosen; Francois D. 
> Menard; Khan,
> > > Sohel Q
> > > > [CTO]; David Meyer; [e-mail]
> > > > Subject: [Speermint] Location Function in SPEERMINT
> > > >
> > > > Hi all,
> > > >
> > > > sorry, but I am only able to reply with a short
> > statement, because I
> > > am
> > > > on vacation and have only limited time and bandwitdh (GPRS)
> > > >
> > > > First, I consider this discussion regarding Infrastructure ENUM,
> > LERG
> > > and
> > > > LNP
> > > > important, but in the wrong WG. It should be discussed 
> in ENUM. WG
> > and
> > > > not in SPEERMINT
> > > >
> > > > SPEERMINT is only dealing with Call Routing Data (CRD), which is
> > > defined
> > > > as the OUTPUT of ENUM or some other means.
> > > >
> > > > This implies, that the location function (LF) defined in the 
> > > > achitecture draft happens AFTER an ENUM query and
> > therefore cannot
> > > > be the part of the LF.
> > > >
> > > > The LF can only involve the location of the destination 
> "network"
> > > > as defined in SPEERMINT by the use of CRD (which is
> > basically a SIP
> > > > URI because we are currently talking only SIP in SPEERMINT)
> > > >
> > > > Of course SPEERMINT needs to define what it considers
> > CRD, and AoR
> > > > or the ingress point of a network.
> > > >
> > > > BUT then SPEERMINT needs also to define how the ingress
> > point of a
> > > > "network" is LOCATED given a SIP AoR.
> > > [[Reinaldo]]
> > > 
> > > That's maybe one of the most important issues. This could be
> > complicated
> > > by the geographically dispersed networks with several 
> entry points.
> > > Although this might be an interesting problem it might be 
> a rathole.
> > > 
> > > 
> > > >
> > > > Richard
> > > >
> > > >
> > > > ________________________________
> > > >
> > > > Von: Tim Dwight [mailto:[e-mail]]
> > > > Gesendet: Do 25.05.2006 20:17
> > > > An: 'Michael Hammer (mhammer)';
> > [e-mail]; Stastny
> > > > Richard; 'Brian Rosen'; 'Francois D. Menard'; 'Khan,
> > Sohel Q [CTO]';
> > > > 'David Meyer'; [e-mail]
> > > > Betreff: RE: [Speermint] RE: SPEERMINT Peering 
> Architecture - LF -
> > OF
> > > - SF
> > > >
> > > >
> > > >
> > > > Michael Hammer said:
> > > >
> > > > > Tim,
> > > > >
> > > > > The LERG and LNP databases are intrinsically tied to
> > the operation
> > > of
> > > > the
> > > > TDM
> > > > > infrastructure.  Any design that perpatuates these 
> systems when
> > > their
> > > > reason
> > > > > for being (TDM) goes away is a faulty design.
> > > >
> > > > OK with me.  I only meant to point out that right now I
> > have these
> > > > capabilities, so recreating them isn't a high priority.
> > > >
> > > >
> > > > >
> > > > > DNS and ENUM provides the equivalent information and
> > mechanisms to
> > > do
> > > > what
> > > > is
> > > > > needed in the IP domain.  As such, a design that makes
> > dependencies
> > > on
> > > > legacy
> > > > > systems is deficient.  I wouldn't support such a kludge.
> > > >
> > > > Fine.
> > > >
> > > > I'm a big fan of IP-domain solutions.  Specifically 
> Infrastructure
> > > ENUM
> > > > looks really handy; my point before was that it's 
> moreso when used
> > in
> > > what
> > > > Richard called "option 1".  The alternative ("option 2") only
> > > replicates
> > > > the
> > > > "kludge" to which I already have access.
> > > >
> > > > And to be fair to Richard, he did point out (subtly) that
> > the latter
> > > claim
> > > > is a bit myopic.  There are existing means by which 
> VSPs can gain
> > > access
> > > > to
> > > > number portability information relative to national 
> destinations.
> > > They
> > > > don't have such access, at least not easily and not
> > universally, to
> > > number
> > > > portability information relative to international
> > destinations.  If
> > > that
> > > > could be provided by Infrastructure ENUM (either "option 1" or
> > "option
> > > 2")
> > > > it would be useful and would not simply replicate existing
> > > capabilities.
> > > >
> > > > Bottom line, both options defined by Richard, would add value.
> > Option
> > > 1
> > > > adds more value but is specific to destinations
> > identified by E.164
> > > > numbers or URIs with imbedded E.164 numbers.  Which is
> > the problem
> > > > closest
> > to
> > > > hand.
> > > >
> > > >
> > > > >
> > > > > That said, if there are backward compatibilities during the
> > > transition,
> > > > where
> > > > > some information just happens to be known by external systems,
> > such
> > > as
> > > > you
> > > > suggest
> > > > > below, I don't see that as a problem.  I am just wary
> > of ending up
> > > with
> > > > two
> > > > > systems in the end when one would do.
> > > >
> > > > Isn't it inevitable that for some time, both will 
> exist?  Just as
> > the
> > > GSTN
> > > > and VoIP will coexist for some time, so will their supporting 
> > > > infrastructure.
> > > >
> > > > Don't get me wrong.  I'm not saying "because I have an 
> SS7 -based
> > > solution
> > > > to LNP I don't need an IP -based solution".  All I'm
> > saying is that
> > > when
> > > > given the option of using Infrastructure ENUM to 
> recreate (and in
> > the
> > > case
> > > > of international destinations, extend) the capability I already
> > have,
> > > and
> > > > using it to do that and more, I'm inclined to prefer the latter.
> > > >
> > > >
> > > > >
> > > > > Mike
> > > >
> > > >
> > > > > -----Original Message-----
> > > > > From: Tim Dwight [mailto:[e-mail]]
> > > > > Sent: Wednesday, May 24, 2006 6:19 PM
> > > > > To: 'Stastny Richard'; [e-mail]; 
> > > > > [e-mail]; Michael Hammer (mhammer); 'Brian
> > Rosen';
> > > > > 'Francois D. Menard'; 'Khan, Sohel Q [CTO]'; 'David Meyer'; 
> > > > > [e-mail]
> > > > > Subject: RE: [Speermint] RE: SPEERMINT Peering
> > Architecture - LF -
> > > OF
> > > > > - SF
> > > > >
> > > > > Richard,
> > > > >
> > > > > Yes I know I was mixing data and mechanism-to-access-data.
> > > > > Still I believe the major point to be correct.  In 
> many parts of
> > the
> > > > > world there are already mechanisms (associated with 
> Local Number
> > > > > Portability) to determine ownership of an E.164 number,
> > hence use
> > of
> > > > > ENUM for this purpose alone, will be unnecessary.
> > > > >
> > > > > To be clear, I believe that providing access via 
> Infrastructure
> > ENUM
> > > > > to LNP information may be very helpful; but only if
> > Infrastructure
> > > > > ENUM provides more than just this.
> > > > >  If an Infrastructure ENUM query can combine (a)
> > determination of
> > > the
> > > > > entity providing service to the destination, (b)
> > determination of
> > > the
> > > > > corresponding LRN, if one exists, and (c) mapping of
> > the routable
> > > > > number (either the number originally indicated, or 
> the LRN) to a
> > > Layer
> > > > > 5 "point of ingress" specified by the entity providing
> > service to
> > > the
> > > > > destination;  then Infrastructure ENUM is quite a handy
> > mechanism.
> > > If
> > > > > all it does is (a) then I don't need it.
> > > > >
> > > > > But in the end this is neither here nor there.  I am
> > not wedded to
> > > any
> > > > > specific technology, I just need workable solutions to real
> > business
> > > > > problems.
> > > > >
> > > > > Tim
> > > > >
> > > > >
> > > > > -----Original Message-----
> > > > > From: Stastny Richard [mailto:[e-mail]]
> > > > > Sent: Wednesday, May 24, 2006 4:38 PM
> > > > > To: [e-mail]; [e-mail];
> > Michael
> > > > > Hammer (mhammer); Brian Rosen; Francois D. Menard;
> > Khan, Sohel Q
> > > > > [CTO]; David Meyer; [e-mail]
> > > > > Subject: Re: [Speermint] RE: SPEERMINT Peering
> > Architecture - LF -
> > > OF
> > > > > - SF
> > > > >
> > > > > Tim,
> > > > >
> > > > > thanx for your reply, you are raising some important issues.
> > > > > Since it is already midnight here, I will reply to it 
> in detail 
> > > > > tomorrow
> > > > >
> > > > > I am also working on a more detailed analysis and a 
> draft which
> > will
> > > > > require even some more time.
> > > > >
> > > > > Just a quick one:
> > > > >
> > > > > >In some parts of the world the function provided by "option
> > > > > 2" usage of
> > > > > >Infrastructure ENUM could be achieved in other ways (e.g.,
> > > > > the LERG and
> > > > > >NPDB in North America) so in those cases Infrastructure ENUM
> > > > > might be a
> > > > > >superfluous concept;  but if that's the right technical
> > > > > answer so be it.
> > > > >
> > > > > Yes and no ;-)
> > > > > You are mixing up here the Registry and the ENUM DNS.
> > > > > The Registry is the LERG and NPDB (or is derived 
> from), the ENUM
> > DNS
> > > > > is the equivalent on IP of the SCP in the PSTN where
> > the date is
> > > > > downloaded to.
> > > > >
> > > > > Richard
> > > > >
> > > > >
> > > > > ________________________________
> > > > >
> > > > > Von: Tim Dwight [mailto:[e-mail]]
> > > > > Gesendet: Mi 24.05.2006 23:00
> > > > > An: Stastny Richard; [e-mail];
> > 'Michael Hammer
> > > > > (mhammer)'; 'Brian Rosen'; 'Francois D. Menard'; 
> 'Khan, Sohel Q 
> > > > > [CTO]'; 'David Meyer'; [e-mail]
> > > > > Betreff: RE: [Speermint] RE: SPEERMINT Peering
> > Architecture - LF -
> > > OF
> > > > > - SF
> > > > >
> > > > >
> > > > >
> > > > > Richard,
> > > > >
> > > > > Thank you for the clarification.  I understand the
> > distinction you
> > > are
> > > > > making.
> > > > >
> > > > > My objective is to be able to translate a destination 
> identifier
> > > > > (E.164 number of alphanumeric AoR) into the address of
> > a Layer 5
> > > > > entity designated by the organization providing service to the
> > > called
> > > > > party.  With infrastructure/carrier ENUM I could do this (as
> > > described
> > > > > in your Option 1), but because ENUM is specific to 
> E.164 numbers
> > it
> > > > > would only work for E.164 -formatted destination identifiers.
> > > > >
> > > > > In pictures, your Option 2 seems to me to imply the following:
> > > > >
> > > > >                +----------------+                 +----------+
> > > > > E.164          | infrastructure |     serving     | identify
> > > > > |     network
> > > > > ingress
> > > > > destination -->| ENUM           |---> carrier --->| ingress
> > > > > |---> point
> > > > > specified
> > > > > identifier     | (option 2)     |     identity    | point    |
> > > by
> > > > > serving carrier
> > > > >                +----------------+        ^        +----------+
> > > > >                                          |
> > > > >                +----------------+        |
> > > > > non-E.164      | map domain in  |        |
> > > > > Destination -->| URI to carrier |--------+
> > > > > Identifier     | identity       |
> > > > >                +----------------+
> > > > >
> > > > > In some parts of the world the function provided by "option 2"
> > usage
> > > > > of Infrastructure ENUM could be achieved in other ways
> > (e.g., the
> > > LERG
> > > > > and NPDB in North America) so in those cases 
> Infrastructure ENUM
> > > might
> > > > > be a superfluous concept; but if that's the right
> > technical answer
> > > so
> > > > > be it.
> > > > >
> > > > > The "identify ingress point" function would need to be
> > defined.  I
> > > > > would like it to consider the specified destination 
> (in addition
> > to
> > > > > the carrier providing service to that destination); 
> and I would
> > like
> > > > > the procedures to be such that the serving carrier
> > controls (in a
> > > > > reasonably dynamic
> > > > > way) the point at which traffic destined to a particular
> > > destination,
> > > > > enters his network.  If those requirements can be met, I think
> > this
> > > > > approach is workable.
> > > > >
> > > > > Its biggest drawback is that it precludes a solution 
> ("option 1"
> > > usage
> > > > > of Infrastructure ENUM) that is sufficient for the majority of
> > > today's
> > > > > needs.
> > > > > It optimizes for a problem that will exist in the 
> future at the 
> > > > > expense of solving problems that exist today.  I realize that
> > > solving
> > > > > today's problems may not be SPEERMINT's focus, or
> > (arguably) even
> > > > > within its charter, but I would hate to see
> > recommendations from
> > > > > SPEERMINT preclude or significantly delay solving them.
> > > > >
> > > > > Suppose we did something like this:
> > > > >
> > > > >                +----------+     [pseudo     +----------------+
> > > > > non-E.164      | identify |     or real]    | infrastructure
> > > > > |     network
> > > > > ingress
> > > > > destination -->| "pseudo" |---> E.164   --->| ENUM
> > > > > |---> point
> > > > > specified
> > > > > identifier     | E.164    |     number      | (option 1)     |
> > > by
> > > > > serving carrier
> > > > >                +----------+                 +----------------+
> > > > >
> > > > > We could let the ENUM working group define
> > Infrastructure ENUM as
> > > > > described in your Option 1 (which is as you know already
> > > commercially
> > > > > available from a few sources) and SPEERMINT could define the
> > > "identify
> > > > > pseudo E.164" function that in my diagram feeds into 
> it.  This 
> > > > > function might be as simple as mapping the domain part
> > of the URI
> > to
> > > > > an E.164 number uniquely associated with the network providing
> > > service
> > > > > to the specified destination.  Unless this is a lot
> > harder than it
> > > > > seems, this shouldn't keep us busy too long :-)
> > > > >
> > > > >
> > > > > Tim
> > > > >
> > > > >
> > > > > -----Original Message-----
> > > > > From: Stastny Richard [mailto:[e-mail]]
> > > > > Sent: Wednesday, May 24, 2006 11:16 AM
> > > > > To: [e-mail]; Michael Hammer 
> (mhammer); Brian 
> > > > > Rosen; Francois D. Menard; Khan, Sohel Q [CTO]; David Meyer; 
> > > > > [e-mail]
> > > > > Subject: Re: [Speermint] RE: SPEERMINT Peering
> > Architecture - LF -
> > > > > OF - SF
> > > > >
> > > > > Tim,
> > > > >
> > > > > >> ... the basic idea of Infrastructure ENUM (which 
> will be used
> > for
> > > > > >> service providers is to provide a domain name in a
> > SIP URI = a
> > > > > >> service provider ID
> > > > > >(SPID)
> > > > >
> > > > > >At the risk of asking an off-topic question (realizing that
> > > > > ENUM is not
> > > > > >within scope for SPEERMINT), can I ask where the idea that 
> > > > > >Infrastructure ENUM queries return SPIDs, comes from?  It is
> > > > > my intent
> > > > > >to provide a point of interconnection to be used by the
> > requesting
> > > > > >entity to hand to me a call to the specified number.  I do
> > > > > not intend
> > > > > >that the only meaningful part of the URI returned from the
> > > > > ENUM query,
> > > > > >be
> > > > > the domain name.
> > > > >
> > > > > thank you for raising this important point. I tried to
> > raise this
> > > > > some time ago, but got no clear answer
> > > > >
> > > > > Currently there exist two lines of thought about the usage of 
> > > > > Infrastructure (and also Carrier ENUM in private trees)
> > > > >
> > > > > 1. Put in ENUM the ingress point(s) e.g.
> > > > > sip:[e-mail] 2.
> > > > > Put in ENUM the AoR only: e.g. sip:[e-mail] 
> > > > > (provider.net is what I meant with SPID)
> > > > >
> > > > > Most currently prefer option 1, especially in private
> > ENUM trees.
> > > > >
> > > > > IMHO this is the wrong approach:
> > > > >
> > > > > There should be a clear separation (and it is in the charter) 
> > > > > between ENUM and SPEERMINT SPEERMINT peering MUST be
> > able to work
> > > > > standalone and without ENUM.
> > > > >
> > > > > Option 1 assumes also that the user is entering ALWAYS an
> > > > > E.164 number as identifier.
> > > > >
> > > > > But what if he is entering an AoR?
> > > > >
> > > > > SPEEMINT peering MUST be able to resolve this too so
> > you need to
> > > > > find the ingress point independant of ENUM e.g. via RFC3263.
> > > > >
> > > > > If this MUST be possible, why not enter in (any) ENUM 
> just the 
> > > > > AoR, if you must be able to resolve the AoR anyway?
> > > > >
> > > > > Otherwise you need to manage two mappings separate 1. the
> > > > > E.164 to ingress point 2. the AoR mapping to ingress point
> > > > >
> > > > > this is not a good idea
> > > > >
> > > > > This is the reason why I would prefer to enter in ENUM
> > AoRs only
> > > > > the user part in ENUM is always the E.164 number (for privacy
> > > > > reasons) the domain part is the SPID, which is mapped 
> later to 
> > > > > find the ingress point
> > > > >
> > > > > the calling user may then also use an alis AoR such as 
> > > > > sip:[e-mail]
> > > > >
> > > > > regards
> > > > >
> > > > > Richard
> > > > >
> > > > >
> > > > >
> > > > > ________________________________
> > > > >
> > > > > Von: Tim Dwight [mailto:[e-mail]]
> > > > > Gesendet: Mi 24.05.2006 16:46
> > > > > An: Stastny Richard; 'Michael Hammer (mhammer)'; 
> 'Brian Rosen'; 
> > > > > 'Francois D.
> > > > > Menard'; 'Khan, Sohel Q [CTO]'; 'David Meyer';
> > [e-mail]
> > > > > Betreff: RE: [Speermint] RE: SPEERMINT Peering
> > Architecture - LF -
> > > > > OF - SF
> > > > >
> > > > >
> > > > >
> > > > > Stastny, Richard said:
> > > > >
> > > > > > ... the basic idea of Infrastructure ENUM (which 
> will be used
> > for
> > > > > > service providers is to provide a domain name in a SIP URI
> > > > > = a service
> > > > > > provider ID
> > > > > (SPID)
> > > > >
> > > > > At the risk of asking an off-topic question (realizing
> > that ENUM
> > > > > is not within scope for SPEERMINT), can I ask where the
> > idea that
> > > > > Infrastructure ENUM queries return SPIDs, comes from? 
>  It is my 
> > > > > intent to provide a point of interconnection to be 
> used by the 
> > > > > requesting entity to hand to me a call to the specified
> > number.  I
> > > > > do not intend that the only meaningful part of the 
> URI returned 
> > > > > from the ENUM query, be the domain name.
> > > > >
> > > > > tim
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > _______________________________________________
> > > > > Speermint mailing list
> > > > > [e-mail]
> > > > > https://www1.ietf.org/mailman/listinfo/speermint
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > _______________________________________________
> > > > > Speermint mailing list
> > > > > [e-mail]
> > > > > https://www1.ietf.org/mailman/listinfo/speermint
> > > > >
> > > >
> > > > _______________________________________________
> > > > Speermint mailing list
> > > > [e-mail]
> > > > https://www1.ietf.org/mailman/listinfo/speermint
> > > >
> > > >
> > > >
> > > >
> > > > _______________________________________________
> > > > Speermint mailing list
> > > > [e-mail]
> > > > https://www1.ietf.org/mailman/listinfo/speermint
> > 
> > _______________________________________________
> > Speermint mailing list
> > [e-mail]
> > https://www1.ietf.org/mailman/listinfo/speermint
> > 
> 

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