service provider and place emergency calls direct is not a PSAP policy
issue.
I'm satisfied with the current -phonebcp dictum to send calls on the normal
call path. For an "unregistered" device, that will not allow any "calls"
including emergency calls.
I discussed this draft on the NENA LTD meeting this morning. That may
generate some list discussion from some PSAP people who are subscribed. I
would also like to hear from more PSAP folks on this subject.
Brian
On 10/29/09 3:27 PM, "Marc Linsner" <mlinsner@cisco.com> wrote:
> These are all PSAP policy decisions. Just as it's a PSAP policy decision to
> support the suggested mechanism in the draft. Existence of the document
> describing the mechanism doesn't force PSAP policy.
>
> I personally would like to see some PSAPs and/or PS jurisdictions line up
> behind the draft before it proceeds, but I don't see any harm in it going
> forward.
>
> Of course, I'm dreaming about this special place where a PSAP actually wants
> to enable communication with all their customers and not force them to be a
> member of a special club.
>
> [non-chair hat on]
>
> -Marc-
>
>
> On 10/29/09 2:35 PM, "Brian Rosen" <br@brianrosen.net> wrote:
>
>> Thank you. That is what I meant, and you said it better than I was going
>> to.
>>
>> We may also have some transitive relationships: that is, if there is a
>> "local" PSAP that trusts that they have done so, other PSAPs may trust that
>> they have done so.
>>
>> Brian
>>
>> On 10/29/09 11:48 AM, "DRAGE, Keith (Keith)" <drage@alcatel-lucent.com>
>> wrote:
>>
>>> I suspect that what Brian is saying is that anyone can be a service provider
>>> (or whatever else you want to call it) in this case provided that:
>>>
>>> 1) they make that agreement with the PSAP providers they route calls
>>> to;
>>>
>>> 2) they authenticate the calls requests to a level of security that
>>> meets
>>> the PSAPs (and any legal) requirements;
>>>
>>> 3) the PSAP trusts that they have done so.
>>>
>>> While this would normally be what we would understand as public
>>> telecommuncation operators, it doesn't mean they have to be.
>>>
>>> regards
>>>
>>> Keith
>>>
>>>> -----Original Message-----
>>>> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org]
>>>> On Behalf Of Marc Linsner
>>>> Sent: Thursday, October 29, 2009 12:32 PM
>>>> To: Brian Rosen
>>>> Cc: ecrit@ietf.org
>>>> Subject: Re: [Ecrit] FW: [Geopriv] Winterbottom-ecrit-direct
>>>> considered
>>>>
>>>> Brian,
>>>>
>>>> Please define what you consider to be a service provider.
>>>>
>>>> Is Skype a service?
>>>> Is Jabber a service?
>>>> Is Google Voice a service?
>>>> Is mydomain.com hosted on a commercial site a service?
>>>> Is mydomain.com hosted on a home server a service?
>>>> Is myEnterpriseVoIP.com a service?
>>>>
>>>> So, what you are saying that if I can make calls via all of
>>>> the above, it's OK for all of the above to contact an ESRP?
>>>>
>>>> Are you requiring that I have a full-time proxy on-line for
>>>> mydomain.com or can I simply run a transient UA and dynamic DNS?
>>>>
>>>> -Marc-
>>>>
>>>>
>>>>
>>>> On 10/28/09 11:17 PM, "Brian Rosen" <br@brianrosen.net> wrote:
>>>>
>>>>> I'm not worried about security by obscurity. I don't want
>>>> phones (or
>>>>> other
>>>>> devices) built to call directly.
>>>>>
>>>>> -phonebcp says "send the call on your normal outbound call path".
>>>>> That's what I want it to say, and I don't want it to say "send it
>>>>> direct, bypass your service provider.
>>>>>
>>>>> I'm not stopping attack, I am stopping abuse.
>>>>>
>>>>> I don't want devices that are not subscribed to services to
>>>> be able to
>>>>> make emergency calls (that is, if they can't make "normal"
>>>> calls, they
>>>>> should not be able to make emergency calls).
>>>>>
>>>>> Brian
>>>>>
>>>>>
>>>>> On 10/28/09 6:51 PM, "Marc Linsner" <mlinsner@cisco.com> wrote:
>>>>>
>>>>>> Brian,
>>>>>>
>>>>>> What I hear you saying: 'if we don't document how to spoof a PSAP,
>>>>>> then nobody will figure it out.' Isn't that a little
>>>> short sighted?
>>>>>>
>>>>>> Joey@miscreant.org will figure out how to establish a SIP session
>>>>>> with any PSAP in the world within 10 minutes of that PSAP being
>>>>>> accessible via the Internet, regardless of documentation.
>>>>>>
>>>>>> I believe there's more harm created in not documenting this for
>>>>>> John.Q.Public@ordinary_citizen.com.
>>>>>>
>>>>>> Granted, nobody here is looking to cause harm to a PSAP. But
>>>>>> Joey@miscreant.org can certainly expend public safety resources by
>>>>>> reporting a bomb threat to a local school. Should we require that
>>>>>> all SIP calls to the local school come from a trusted SP?
>>>> Where does it end?
>>>>>>
>>>>>> This isn't the way to deal with spam.
>>>>>>
>>>>>> -Marc-
>>>>>>
>>>>>>
>>>>>>
>>>>>> On 10/27/09 11:00 AM, "Brian Rosen" <br@brianrosen.net> wrote:
>>>>>>
>>>>>>> The first goal is to prevent bad calls.
>>>>>>>
>>>>>>> The second goal is to indentify the source of the bad calls.
>>>>>>>
>>>>>>> I'm starting with the first goal. I don't want you to be able to
>>>>>>> take a device out of a box, plug it into a network, and have the
>>>>>>> only call you can make be an emergency call. I want the
>>>> device to
>>>>>>> actually "work" (as in be able to place calls to all the entities
>>>>>>> that it was intended to) first, and then be able to place
>>>> emergency calls.
>>>>>>>
>>>>>>> Please spend some time in a PSAP while a kid with a
>>>> simless phone has "fun"
>>>>>>> with it. Imagine how much fun the test mechanism is as
>>>> opposed to
>>>>>>> placing real calls.
>>>>>>>
>>>>>>> If we somehow get a bad call, we need to send the cops.
>>>> That means
>>>>>>> we need an identity (and a location).
>>>>>>>
>>>>>>> I think a good cert could be the basis of a good identity, if we
>>>>>>> could get one. I don't see how we do that.
>>>>>>>
>>>>>>> Brian
>>>>>>>
>>>>>>>
>>>>>>> On 10/27/09 10:39 AM, "Richard Barnes" <rbarnes@bbn.com> wrote:
>>>>>>>
>>>>>>>> Brian,
>>>>>>>>
>>>>>>>> Is the security goal here more access control (i.e., controlling
>>>>>>>> who can send calls to a PSAP) or attribution/identification for
>>>>>>>> post-hoc action.
>>>>>>>>
>>>>>>>> If it's the latter, then ISTM that the problem can largely be
>>>>>>>> reduced to having a certificate infrastructure that binds
>>>>>>>> authenticated identities to real-world entities. The
>>>> "extended validation"
>>>>>>>> certificates that current commercial CAs issue seem to largely
>>>>>>>> satisfy this requirement.
>>>>>>>>
>>>>>>>> --Richard
>>>>>>>>
>>>>>>>>
>>>>>>>> On Oct 27, 2009, at 4:31 PM, Brian Rosen wrote:
>>>>>>>>
>>>>>>>>> Of course not all VSPs will have trust relationships with all
>>>>>>>>> PSAPs. One can hope that long term, we can evolve to
>>>> transitive
>>>>>>>>> trust relationships that work pretty well cross border.
>>>>>>>>>
>>>>>>>>> The emergency guys are actually terrified of private/individual
>>>>>>>>> domains sending them calls, and we're telling them we
>>>> expect that
>>>>>>>>> to be possible, but rare, and we're giving them mechanisms that
>>>>>>>>> will effectively allow them to turn off calls
>>>> selectively, based
>>>>>>>>> on factors including what domain the call comes from.
>>>> They expect
>>>>>>>>> that such calls will be one of the loopholes where they get
>>>>>>>>> equivalents to sim-less calls, which drive them nuts.
>>>> They don't
>>>>>>>>> want ANY calls that don't come from service providers, although
>>>>>>>>> they seem to be okay with the notion that the SP may not have
>>>>>>>>> great identity (AOL being a poster child). So, while
>>>> indeed they
>>>>>>>>> understand, and have concerns about having to take calls from
>>>>>>>>> Sierra Leone VoIP services Pty, they would much rather
>>>> have a call
>>>>>>>>> that went through them then a call that went through no service
>>>>>>>>> provider at all.
>>>>>>>>>
>>>>>>>>> I'm not trying to make calls direct from devices or private
>>>>>>>>> domains impossible, but I think the notion that we're promoting
>>>>>>>>> them is a very bad idea until we have effective mechanisms to
>>>>>>>>> prevent abuse.
>>>>>>>>>
>>>>>>>>> Brian
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On 10/27/09 9:02 AM, "Marc Linsner" <mlinsner@cisco.com> wrote:
>>>>>>>>>
>>>>>>>>>> Brian,
>>>>>>>>>>
>>>>>>>>>> I'm a little confused. I don't remember you objecting to
>>>>>>>>>> requirement RE1 from RFC5012 and I remember your use
>>>> case about a
>>>>>>>>>> Sierra Leone VSP.
>>>>>>>>>>
>>>>>>>>>> Are you implying that *all* VSPs will have a trust
>>>> relationships
>>>>>>>>>> with *all* PSAPs?
>>>>>>>>>>
>>>>>>>>>> What is the difference between a call coming from a private/
>>>>>>>>>> individual domain (as in not a commercial VSP) and a
>>>> VSP on the
>>>>>>>>>> other side of the world (outside the jurisdiction)?
>>>>>>>>>>
>>>>>>>>>> I'm trying to figure out whether you're objecting to anonymous
>>>>>>>>>> calls to the PSAP or the mechanisms proposed in this draft?
>>>>>>>>>>
>>>>>>>>>> [Don't take this as my endorsement of the draft, as
>>>> I'm not sure
>>>>>>>>>> I agree with UAs registering with the ESRP.]
>>>>>>>>>>
>>>>>>>>>> -Marc-
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On 10/26/09 8:59 PM, "Brian Rosen" <br@brianrosen.net> wrote:
>>>>>>>>>>
>>>>>>>>>>> First of all, I put it on the wrong email list, sorry
>>>> about that.
>>>>>>>>>>>
>>>>>>>>>>> Then, we have carefully arranged it so that there is
>>>> no identity
>>>>>>>>>>> coming from the access network provider, and because the
>>>>>>>>>>> location is coming from that provider, we really
>>>> don't want to.
>>>>>>>>>>> But even if we did, we would need a really good
>>>> identifier, and
>>>>>>>>>>> there isn't one.
>>>>>>>>>>>
>>>>>>>>>>> The problem we have with -direct is anonymous callers, and if
>>>>>>>>>>> they have any option, they would also be
>>>> location-less. Until
>>>>>>>>>>> and unless we get rid of anonymity, we can't
>>>> encourage service
>>>>>>>>>>> provider-less calls. The draft does not make any
>>>> provision to
>>>>>>>>>>> provide any kind of identity. Many networks (think free wifi
>>>>>>>>>>> for example) would make providing good identity difficult.
>>>>>>>>>>>
>>>>>>>>>>> The fact is that there is a SERVICE provider in
>>>> nearly all of the
>>>>>>>>>>> communications systems. The SERVICE provider is in
>>>> a position to
>>>>>>>>>>> assist
>>>>>>>>>>> the emergency calling system when it needs more information.
>>>>>>>>>>> That's what a
>>>>>>>>>>> good SERVICE provider does. Cutting them out is not a great
>>>>>>>>>>> idea. Most of the attempts to provide real time
>>>> communications
>>>>>>>>>>> between people have evolved to using service providers, even
>>>>>>>>>>> when there were alternatives. File transfer via
>>>> something like
>>>>>>>>>>> Torrent is a counterexample (which isn't real time), but even
>>>>>>>>>>> there, you end up with service providers like The Pirate Bay
>>>>>>>>>>> (R.I.P) to provide introduction services. I don't
>>>> think we're
>>>>>>>>>>> going to see changes that eliminate service providers, and in
>>>>>>>>>>> this case, they provide value to the emergency
>>>> calling systems.
>>>>>>>>>>> All of the emergency professionals I know have issues with
>>>>>>>>>>> service providers, but they would react with horror if you
>>>>>>>>>>> suggested cutting them out. Ask them, please.
>>>>>>>>>>>
>>>>>>>>>>> So, I claim you have a solution in search of a
>>>> problem. We have
>>>>>>>>>>> solved the "calling network isn't the access network" problem
>>>>>>>>>>> already. Service providers ARE in the path now, in
>>>> nearly every
>>>>>>>>>>> case (in fact a counter example escapes me, although there
>>>>>>>>>>> probably are some). There is no movement I can detect which
>>>>>>>>>>> would change that any time soon; quite the opposite.
>>>> We have a
>>>>>>>>>>> known killer problem without some kind of subscription to a
>>>>>>>>>>> service that provides a good identity, for which you
>>>> provide no
>>>>>>>>>>> answers.
>>>>>>>>>>> We have
>>>>>>>>>>> experience with the killer problem: sim-less calling was
>>>>>>>>>>> supposed to provide a way to make an emergency call
>>>> in exactly
>>>>>>>>>>> the kinds of circumstances you are describing. Our
>>>> real world
>>>>>>>>>>> experience is that you create a huge problem that diverts
>>>>>>>>>>> resources from helping people to chasing scammers and
>>>>>>>>>>> flea-market sellers.
>>>>>>>>>>>
>>>>>>>>>>> Nothing is perfect: you can get a AIM screen name
>>>> without a very
>>>>>>>>>>> good identity for example. However, the notion that
>>>> we're going
>>>>>>>>>>> to provide direct access without a service provider
>>>>>>>>>>> deliberately, especially without really good identity
>>>> from the
>>>>>>>>>>> access network is, in my opinion not only a no, it's
>>>> a heck no.
>>>>>>>>>>> I'll line up as many emergency service professionals as you
>>>>>>>>>>> would like to tell you this is a harmful idea.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> On 10/26/09 7:56 PM, "Dawson, Martin"
>>>> <Martin.Dawson@andrew.com>
>>>>>>>>>>> wrote:
>>>>>>>>>>>
>>>>>>>>>>>> I am glad this has come up. It's a debate that has
>>>> to happen if
>>>>>>>>>>>> we are to move beyond a long standing legacy misconception.
>>>>>>>>>>>>
>>>>>>>>>>>> In the circuit service world - whether it was POTS
>>>> or mobile,
>>>>>>>>>>>> the access network had full responsibility for
>>>> delivering the
>>>>>>>>>>>> emergency call. In that world, routing an emergency
>>>> call meant
>>>>>>>>>>>> getting a circuit established to the correct call center. In
>>>>>>>>>>>> most parts of the world, this was done using the
>>>> regional part
>>>>>>>>>>>> of the PSTN to switch the circuit to a call center
>>>> on the PSTN.
>>>>>>>>>>>> In some jurisdictions, such as the US, it was done directly
>>>>>>>>>>>> from the local exchange carrier to the call center.
>>>> Either way,
>>>>>>>>>>>> there was no third party involved.
>>>>>>>>>>>>
>>>>>>>>>>>> Now we have the Internet. We still have public
>>>> access network
>>>>>>>>>>>> providers.
>>>>>>>>>>>> They
>>>>>>>>>>>> switch packets onto the Internet for their subscribers. They
>>>>>>>>>>>> can similarly ensure that packets reach the local emergency
>>>>>>>>>>>> call centers.
>>>>>>>>>>>>
>>>>>>>>>>>> The fact is that there was no equivalent of a VSP in the
>>>>>>>>>>>> traditional environment. VoIP is a presence service,
>>>> and it had
>>>>>>>>>>>> no common equivalent in the PSTN world. It could
>>>> have, but the
>>>>>>>>>>>> narrowband state of technology and the common market
>>>> use cases
>>>>>>>>>>>> didn't support its development. By the time ISDN
>>>> arrived, the
>>>>>>>>>>>> PSTN had already slipped into its palliative stage without
>>>>>>>>>>>> realizing it.
>>>>>>>>>>>>
>>>>>>>>>>>> It's an entrenched misconception that because the circuit
>>>>>>>>>>>> service provided by exchange carriers was most commonly used
>>>>>>>>>>>> for "voice" (but, it should be noted, also for fax,
>>>> telex, tty,
>>>>>>>>>>>> security system monitoring and, even, IP data) that VSPs are
>>>>>>>>>>>> somehow equivalent to exchange carriers. They are not.
>>>>>>>>>>>>
>>>>>>>>>>>> Indeed, involving VSPs in emergency calls is the Internet
>>>>>>>>>>>> equivalent of involving long distance providers in POTS
>>>>>>>>>>>> emergency calls. They are neither necessary nor particularly
>>>>>>>>>>>> helpful; they can't be guaranteed to be within the emergency
>>>>>>>>>>>> jurisdiction; depending on them actually diminishes the
>>>>>>>>>>>> efficacy of emergency service access. It does not help the
>>>>>>>>>>>> caller, the emergency service, nor the third party
>>>> to insist on
>>>>>>>>>>>> the third party's involvement.
>>>>>>>>>>>>
>>>>>>>>>>>> It can't be helped if you have over sold the benefits of VSP
>>>>>>>>>>>> involvement to yourself and others Brian. It is time
>>>> to have a
>>>>>>>>>>>> reasoned debate.
>>>>>>>>>>>> From my
>>>>>>>>>>>> perspective, the argument that there is no "subscription"
>>>>>>>>>>>> involved is
>>>>>>>>>>>> patently
>>>>>>>>>>>> false. There has to be a subscription of some description in
>>>>>>>>>>>> order to get to the Internet. Yes, there is free public
>>>>>>>>>>>> Internet access (just as there are free courtesy
>>>> phones on the
>>>>>>>>>>>> PSTN and free access to emergency services from pay
>>>> phones. All
>>>>>>>>>>>> these services are still connected to the public Internet
>>>>>>>>>>>> infrastructure and they all represent an "operator"
>>>> with some
>>>>>>>>>>>> level of information about the caller.
>>>>>>>>>>>>
>>>>>>>>>>>> With the over-emphasis on VSPs, what is missing from
>>>> the ECRIT
>>>>>>>>>>>> and i3 models is the direct interface for querying
>>>> the access
>>>>>>>>>>>> network for subscriber data (should it prove
>>>> necessary). These
>>>>>>>>>>>> models need to take the long view of how emergency
>>>> calling is
>>>>>>>>>>>> done in the Internet age; they should not be protracting an
>>>>>>>>>>>> unnecessary reliance on VSPs.
>>>>>>>>>>>>
>>>>>>>>>>>> I have deleted the premature and prejudicial text from the
>>>>>>>>>>>> subject heading.
>>>>>>>>>>>> And I'll leave this on ECRIT as the most appropriate WG.
>>>>>>>>>>>>
>>>>>>>>>>>> Cheers,
>>>>>>>>>>>> Martin
>>>>>>>>>>>>
>>>>>>>>>>>> -----Original Message-----
>>>>>>>>>>>> From: ecrit-bounces@ietf.org
>>>> [mailto:ecrit-bounces@ietf.org] On
>>>>>>>>>>>> Behalf Of Hannes Tschofenig
>>>>>>>>>>>> Sent: Tuesday, 27 October 2009 8:23 AM
>>>>>>>>>>>> To: ecrit@ietf.org
>>>>>>>>>>>> Subject: [Ecrit] FW: [Geopriv] Winterbottom-ecrit-direct
>>>>>>>>>>>> considered harmful, at least given our current experiences
>>>>>>>>>>>>
>>>>>>>>>>>> FYI: feedback from Brian regarding a recent ECRIT
>>>> contribution.
>>>>>>>>>>>>
>>>>>>>>>>>> -----Original Message-----
>>>>>>>>>>>> From: geopriv-bounces@ietf.org
>>>>>>>>>>>> [mailto:geopriv-bounces@ietf.org] On Behalf Of Rosen, Brian
>>>>>>>>>>>> Sent: 26 October, 2009 23:10
>>>>>>>>>>>> To: geopriv@ietf.org
>>>>>>>>>>>> Subject: [Geopriv] Winterbottom-ecrit-direct considered
>>>>>>>>>>>> harmful, at least given our current experiences
>>>>>>>>>>>>
>>>>>>>>>>>> The notion behind -direct is to not use a service
>>>> provider to
>>>>>>>>>>>> place an emergency call. Instead, the device
>>>> registers with
>>>>>>>>>>>> an Emergency Services Routing Proxy immediately before the
>>>>>>>>>>>> call and the call is routed directly from the
>>>> device to the ESRP.
>>>>>>>>>>>>
>>>>>>>>>>>> At least at the moment, this is an exceedingly bad idea.
>>>>>>>>>>>>
>>>>>>>>>>>> Emergency calling authorities like service providers, a lot.
>>>>>>>>>>>> They like them because they can hold them
>>>> accountable, and the
>>>>>>>>>>>> service providers don't like theft of service, which is
>>>>>>>>>>>> something the emergency call guys have an analog to.
>>>>>>>>>>>>
>>>>>>>>>>>> The facts are that where unaccountable access to emergency
>>>>>>>>>>>> calling is allowed, huge numbers of false calls
>>>> occur, with no
>>>>>>>>>>>> way to stop them, and no way to tell the good ones from the
>>>>>>>>>>>> bad ones. This has been seen multiple times where
>>>> so called
>>>>>>>>>>>> "simless" or "unauthenticated" calls are allowed.
>>>>>>>>>>>>
>>>>>>>>>>>> -direct precisely duplicates simless calling. The only
>>>>>>>>>>>> "registration" is an emergency registration, only emergency
>>>>>>>>>>>> calls are allowed, any device can make an emergency call if
>>>>>>>>>>>> all it has is a (radio) connection to any network.
>>>>>>>>>>>> We can predict, with a very high degree of
>>>> certainty, that the
>>>>>>>>>>>> feature will be horribly abused: for example to test that a
>>>>>>>>>>>> phone without a service plan works.
>>>>>>>>>>>>
>>>>>>>>>>>> There have been studies which show tens of thousands of bad
>>>>>>>>>>>> calls with zero good ones. Nearly every authority I know
>>>>>>>>>>>> where the regulator has insisted on simless calling
>>>> wants it
>>>>>>>>>>>> repealed. There is one counter example I know
>>>> where the fact
>>>>>>>>>>>> that they got a couple, literally, of good calls among the
>>>>>>>>>>>> tens of thousands of bad calls was considered
>>>> enough reason to
>>>>>>>>>>>> put up with the problem.
>>>>>>>>>>>>
>>>>>>>>>>>> Service providers give us information that may be useful: a
>>>>>>>>>>>> subscriber name and address for example, which is not
>>>>>>>>>>>> spoofable by the caller. They have ways to trace callers,
>>>>>>>>>>>> especially bad callers. They don't want their
>>>> systems abused
>>>>>>>>>>>> any more than the emergency calling authorities do.
>>>>>>>>>>>>
>>>>>>>>>>>> This is a bad idea. A very bad idea. Please stop it.
>>>>>>>>>>>>
>>>>>>>>>>>> Someday, we may have better ways to prevent abuse. Until we
>>>>>>>>>>>> do, service providers are a good thing on an emergency call.
>>>>>>>>>>>> We don't want them cut out.
>>>>>>>>>>>>
>>>>>>>>>>>> Brian
>>>>>>>>>>>>
>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>> Geopriv mailing list
>>>>>>>>>>>> Geopriv@ietf.org
>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/geopriv
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>> Ecrit mailing list
>>>>>>>>>>>> Ecrit@ietf.org
>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/ecrit
>>>>>>>>>>>>
>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>> Ecrit mailing list
>>>>>>>>>>>> Ecrit@ietf.org
>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/ecrit
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> _______________________________________________
>>>>>>>>>>> Ecrit mailing list
>>>>>>>>>>> Ecrit@ietf.org
>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/ecrit
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> _______________________________________________
>>>>>>>>> Ecrit mailing list
>>>>>>>>> Ecrit@ietf.org
>>>>>>>>> https://www.ietf.org/mailman/listinfo/ecrit
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> Ecrit mailing list
>>>> Ecrit@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/ecrit
>>>>
>>
>>
>
>
_______________________________________________
Ecrit mailing list
Ecrit@ietf.org
https://www.ietf.org/mailman/listinfo/ecrit
