Re: [Ecrit] Location Protocols in Phone BCP

["Roger Marshall" <RMarshall at telecomsys.com>]

I don't think those fixed operator's wanting to introduce mobile
services think of these feature distinctions as 'old school'.  Nor do I
believe that current mobile operators view the separation as a slippery
slope.

 I do think you are failing to tease out the reasons why SUPL does
contain those specific measurement techniques - that is, that it does
the job of an LCP for conforming mobile networks, as well as additional
underlying data exchange (which LCP's by design, don't do - but rely on
other associated protocol suggestions like the new grip, the draft
titled, 'Providing Satellite Navigation Assistance Data using HELD',
etc.
<http://www.ietf.org/internet-drafts/draft-thomson-geopriv-held-grip-00.
txt>).

So, in a way, SUPL </> HELD + GRIP

p.s. I think you meant "is NOT relevant"

> The distinction between fixed and mobile, wireline and 
> wireless is relevant,

-roger.


> -----Original Message-----
> From: Winterbottom, James [mailto:James.Winterbottom at andrew.com] 
> Sent: Thursday, November 20, 2008 2:23 PM
> To: Roger Marshall; Brian Rosen; Stark, Barbara; Richard Barnes
> Cc: Gabor.Bajko at nokia.com; hannes.tschofenig at nsn.com; 
> marc.linsner at cisco.com; ecrit at ietf.org
> Subject: RE: [Ecrit] Location Protocols in Phone BCP
> 
> The distinction between fixed and mobile, wireline and 
> wireless is relevant, it is old-school thinking and isn't 
> really applicable anymore.
> We are talking about an Internet-based device, which can be 
> any or all of the above, and often at the same time.
> 
> I think that dissecting the networks in the manner being 
> described below leads to a very slippery slope very quickly.
> 
> Our requirements for an LCP were that it MUST be implemented 
> by all devices, not that it MUST be implemented by all device if....
> 
> LCPs, the ones currently in Phone BCP, all provide a local 
> service discovery technique, SUPL does not. This aspect of an 
> LCP is important, as it puts the target device in contact 
> with the location server responsible for determining the 
> location of the Target in the local access network. In this 
> way, it is possible for the device to ask for location in the 
> same way every time, regardless of the network technology. 
> Again, this is not true for SUPL, different access 
> technologies require the Device and the home SLP to support 
> new measurement types, and potentially additional "out of scope"
> connectivity back to the actual serving network to use this 
> information.
> 
> Don't get me wrong, SUPL has a place in providing location in 
> some access network architectures, but it is far from 
> ubiquitous, the aim of phone BCP is specify what MUST be 
> supported by all devices.
> 
> 
> Cheers
> James
> 
> 
> 
> > -----Original Message-----
> > From: ecrit-bounces at ietf.org 
> [mailto:ecrit-bounces at ietf.org] On Behalf
> Of
> > Roger Marshall
> > Sent: Friday, 21 November 2008 8:07 AM
> > To: Brian Rosen; Stark, Barbara; Richard Barnes
> > Cc: Gabor.Bajko at nokia.com; hannes.tschofenig at nsn.com; 
> > marc.linsner at cisco.com; ecrit at ietf.org
> > Subject: Re: [Ecrit] Location Protocols in Phone BCP
> > 
> > Isn't there a need to set the scope [text] of phonebcp, so that it
> makes
> > clear what that the requirements apply (without bias) to both fixed
> and
> > mobile end devices (and their associated network deployment types)?
> > 
> > Below is some keyword sampling to show some implications with regard
> to
> > fixed vs. mobile, but which isn't as crisp as it could be (depending
> on
> > the scope).
> > 
> > A search of phonebcp for the following terms yields the associated
> > references:
> > 
> > Fixed:
> > (none);
> > 
> > Wireline:
> > (none);
> > 
> > Mobile:
> > AN-11;
> > ED-35/AN-19;
> > ED-35;
> > 
> > Wireless:
> > AN-7/INT-6;
> > AN-9;
> > AN-7;
> > INT-6;
> > 
> > From the toc, it is listed...
> > 
> >        6.2.2.  Access network "wire database" location 
> information  .
> 7
> >        6.2.3.  End-system measured location information . . 
> . . . . .
> 7
> >        6.2.4.  Network-measured location information  . . . 
> . . . . .
> 8
> > 
> > -roger.
> > 
> > 
> > No mention of fixed, wireline, wireless, or mobile in any 
> of the text 
> > sections (Intro, etc.)
> > 
> > > -----Original Message-----
> > > From: Brian Rosen [mailto:br at brianrosen.net]
> > > Sent: Thursday, November 20, 2008 12:32 PM
> > > To: Roger Marshall; 'Stark, Barbara'; 'Richard Barnes'
> > > Cc: Gabor.Bajko at nokia.com; marc.linsner at cisco.com; 
> > > hannes.tschofenig at nsn.com; ecrit at ietf.org
> > > Subject: RE: [Ecrit] Location Protocols in Phone BCP
> > >
> > > Phonebcp doesn't have a pre-disposition.  It's neutral.  
> If we need 
> > > to parse more carefully, SUPL isn't very suitable for 
> wiremap forms 
> > > of location determination.
> > >
> > > Brian
> > >
> > > -----Original Message-----
> > > From: Roger Marshall [mailto:RMarshall at telecomsys.com]
> > > Sent: Thursday, November 20, 2008 3:22 PM
> > > To: Brian Rosen; Stark, Barbara; Richard Barnes
> > > Cc: Gabor.Bajko at nokia.com; marc.linsner at cisco.com; 
> > > hannes.tschofenig at nsn.com; ecrit at ietf.org
> > > Subject: RE: [Ecrit] Location Protocols in Phone BCP
> > >
> > >  > Generally, I agree that SUPL is unsuitable for access
> > > > networks that don't use GPS or some form of measured location.
> > >
> > > [rsm - measured only - really? - surely you aren't 
> suggesting that 
> > > OMA (and therefore 3GPP, 3GPP2) throw away their reliance 
> on 'rough 
> > > location' via CellID, are you?
> > >
> > > Wiremap location - given (manually input)] CellID 
> location - given 
> > > Terrestial trilateration - measured Celestial trilateration - 
> > > measured Geocoded/reverse geocoded - derived
> > >
> > > I would hope that PhoneBCP doesn't show a pre-disposition 
> to 'given'
> > > location scenarios, aka wiremap, etc. that are more Wireline 
> > > oriented, rather than mobile.  For the future, wireline devices 
> > > reduce in number, mobile (or even nomadic) devices will 
> continue in 
> > > their distribution bias.  Fixed vs. Mobile has been the 
> fundamental 
> > > difference between how the IETF looks at things vs. these 
> mentioned 
> > > other fora.  I contend that if we solve this for mobile - then we 
> > > can begin communicating better with OMA/3GPP/3GPP2, 
> and... Solving 
> > > fixed will be easier.
> > > /]
> > >
> > > > -----Original Message-----
> > > > From: Brian Rosen [mailto:br at brianrosen.net]
> > > > Sent: Thursday, November 20, 2008 12:07 PM
> > > > To: 'Stark, Barbara'; Roger Marshall; 'Richard Barnes'
> > > > Cc: Gabor.Bajko at nokia.com; marc.linsner at cisco.com; 
> > > > hannes.tschofenig at nsn.com; ecrit at ietf.org
> > > > Subject: RE: [Ecrit] Location Protocols in Phone BCP
> > > >
> > > > Gabor accuses us of ignoring reality.  The 3GPP crowd 
> has its own 
> > > > version of that.
> > > >
> > > > All 3GPP networks I know of support a raw packet 
> service.  On that 
> > > > service will run applications like MSN or AOL instant messaging.
> > > > Those services
> > > > will need to be able to make emergency chats.   To route
> > > > properly, they need
> > > > location.  That means that EVERY handset must deploy 
> some LCP, and 
> > > > must be able to get location suitable for emergency call
> > > routing and
> > > > dispatch per -phonebcp.  The RV example is yet another 
> case of the 
> > > > same thing.  The mistake is assuming that all emergency 
> calls will 
> > > > come through the E-CSCF.
> > > > They won't, and the 3GPP access network must conform to all the 
> > > > -phonebcp requirements.
> > > >
> > > > Generally, I agree that SUPL is unsuitable for access networks
> that
> > > > don't use GPS or some form of measured location.
> > > >
> > > > Brian
> > > >
> > > > -----Original Message-----
> > > > From: Stark, Barbara [mailto:bs7652 at att.com]
> > > > Sent: Thursday, November 20, 2008 2:54 PM
> > > > To: Roger Marshall; Brian Rosen; Richard Barnes
> > > > Cc: Gabor.Bajko at nokia.com; marc.linsner at cisco.com; 
> > > > hannes.tschofenig at nsn.com; ecrit at ietf.org
> > > > Subject: RE: [Ecrit] Location Protocols in Phone BCP
> > > >
> > > > I cannot support requiring SUPL in DSL routers, desktop
> > > computers (and
> > > > related operating systems, SIP soft clients), analog terminal 
> > > > adaptors, or other similar devices that are intended 
> for use in a 
> > > > wireline environment. I think that organizations that can drive 
> > > > requirements for devices intended to be use in an environment
> where
> > > > SUPL would actually work, should be responsible for 
> having device 
> > > > requirements requiring SUPL. In other words, 3GPP/3GPP2 are
> > > absolutely
> > > > in a position to require SUPL support for devices that
> > > operate in an
> > > > environment where SUPL works. This is a perfect example of the 
> > > > "closed" network that Brian describes somewhere (framework,
> > > I think).
> > > >
> > > > Phonebcp is about requirements for devices in access 
> environments 
> > > > where the operators of the access environment cannot be 
> assumed to 
> > > > have any control over the type or nature of devices that
> > > connect to or
> > > > through it. Phonebcp needs to continue to have that as its
> purpose.
> > > >
> > > > I agree that nothing in phonebcp should preclude the use of
> > > SUPL, or
> > > > be incompatible with the use of SUPL. And I don't think it does.
> > > > Barbara
> > > >
> > > > -----Original Message-----
> > > > From: ecrit-bounces at ietf.org
> > > [mailto:ecrit-bounces at ietf.org] On Behalf
> > > > Of Roger Marshall
> > > > Sent: Thursday, November 20, 2008 2:36 PM
> > > > To: Brian Rosen; Richard Barnes
> > > > Cc: Gabor.Bajko at nokia.com; marc.linsner at cisco.com; 
> > > > hannes.tschofenig at nsn.com; ecrit at ietf.org
> > > > Subject: Re: [Ecrit] Location Protocols in Phone BCP
> > > >
> > > >
> > > >  If the choice is between preventing, allowing, or
> > > requiring PhoneBCP
> > > > suppport of SUPL, then my vote is to NOT prevent!  I 
> would prefer 
> > > > 'require' since *most* of the location-aware 3G compatible 
> > > > handsets/aircards over the next several years will (I
> > > predict) have a
> > > > SUPL stack included.  In the same time frame, many of those
> > > will also
> > > > have WiFi support, others will have LTE or WiMAX support as
> hybrids.
> > > >
> > > > SUPL will be common-place.  OMA may not be 'Open-Source', it is 
> > > > open-minded, and there is movement afoot to expand 
> OMA/SUPL (as we 
> > > > heard in the geopriv mtg. on Tuesday) w/respect 
> expected proposals 
> > > > such as LocSIP, etc.  Over the fairly near-term, I think
> > > there will be
> > > > fewer protocol, location representation, and privacy
> > > discontinuities -
> > > > things that too often get cited - yet are seldom well 
> understood.
> > > >
> > > > Let's encourage continued IETF communication with OMA/SUPL
> > > - not block
> > > > its use altogether.  This is a case where we need to be
> > > inclusive, not
> > > > exclusive.
> > > >
> > > > As to the mobile RV sample case, the solution is also 
> forseeable - 
> > > > especially given that the location of the 3G aircard in the
> > > router is
> > > > good enough for routing.  The scenario given needs some
> > > integration,
> > > > but is doable.  Given that the aircard acts as a logical
> > > SET, with a
> > > > SUPL stack on board, and a GPS/AGPS chipset inside.  This
> > > combination
> > > > *WILL* (I believe) interoperate with a number of end client 
> > > > applications to initiate and complete a location-routed, 3261
> style
> > > > SIP, emergency call through the core, and into an ESInet.
> > > >
> > > > -roger.
> > > >
> > > > > -----Original Message-----
> > > > > From: ecrit-bounces at ietf.org
> > > > [mailto:ecrit-bounces at ietf.org] On Behalf
> > > > > Of Brian Rosen
> > > > > Sent: Thursday, November 20, 2008 8:23 AM
> > > > > To: 'Richard Barnes'
> > > > > Cc: Gabor.Bajko at nokia.com; hannes.tschofenig at nsn.com; 
> > > > > marc.linsner at cisco.com; ecrit at ietf.org
> > > > > Subject: Re: [Ecrit] Location Protocols in Phone BCP
> > > > >
> > > > > It's very hard to have L2 specific LCPs.  The problem is that
> the
> > > > > clients are generally not very L2 aware.  It's the clients
> > > > that have
> > > > > the problem.
> > > > > You can do things like interwork an L2 specific LCP to a
> > > > common LCP so
> > > > > that non L2 aware devices can work, but you have to 
> do that, and 
> > > > > usually, that's impractical.  Use my example.  Suppose
> > > that the L2
> > > > > used SUPL.  It's possible for the PC Card that is plugged
> > > into the
> > > > > router could implement a SUPL client and a HELD server and
> > > > interwork
> > > > > SUPL in the GSM system to HELD on the Ethernet so the
> > > Ethernet VoIP
> > > > > phone could get location via HELD.  Possible, but not 
> practical.
> > > > > There are all sorts of these kinds of problems.  That's why
> > > > > L2 specific LCPs don't work.
> > > > >
> > > > > Brian
> > > > >
> > > > > -----Original Message-----
> > > > > From: Richard Barnes [mailto:rbarnes at bbn.com]
> > > > > Sent: Thursday, November 20, 2008 11:11 AM
> > > > > To: Brian Rosen
> > > > > Cc: Gabor.Bajko at nokia.com; James.Winterbottom at andrew.com; 
> > > > > ecrit at ietf.org; marc.linsner at cisco.com;
> hannes.tschofenig at nsn.com
> > > > > Subject: Re: [Ecrit] Location Protocols in Phone BCP
> > > > >
> > > > > The IETF can't (and shouldn't) try to make particular
> > > standards for
> > > > > every access technology that's out there.  What we can say
> > > > is that the
> > > > > paradigm for those protocols should be the same as at the
> > > IP layer:
> > > > > Clients MUST implement all, networks MUST implement at least
> one.
> > > > >
> > > > > (This is a little different from the text I sent before,
> > > > and clearer,
> > > > > I
> > > > > think.)
> > > > >
> > > > > All I'm saying is that we shouldn't try to enumerate all
> > > > the possible
> > > > > protocols at lower layers, we should just state the general
> > > > rule.  It
> > > > > seems to me that this achieves the same level of
> > > > interoperability at
> > > > > all layers.
> > > > >
> > > > > --Richard
> > > > >
> > > > > > If there are exactly two LCPs all UAs must implement, and
> > > > > any number
> > > > > > of optional ones, then every network has to implement at
> > > > > least one of
> > > > > > those
> > > > > two
> > > > > > LCPs, and any number of optional ones.  That means that
> > > > > "any number of
> > > > > > optional ones" is useless for both parties.
> > > > > > If the network can limit UAs to ONLY those that implement
> > > > > one of the
> > > > > > optional protocols, then it works, but in practice, it
> > > is usually
> > > > > impossible
> > > > > > to do that.  My example is the wired, Ethernet connected
> > > > > phone in an
> > > > > > RV traveling down the road with wireless data card in a
> > > > > router.  These
> > > > > > EXIST, now.
> > > > > >
> > > > > > Brian
> > > > > > -----Original Message-----
> > > > > > From: Richard Barnes [mailto:rbarnes at bbn.com]
> > > > > > Sent: Thursday, November 20, 2008 10:11 AM
> > > > > > To: Brian Rosen
> > > > > > Cc: Gabor.Bajko at nokia.com; James.Winterbottom at andrew.com; 
> > > > > > ecrit at ietf.org; marc.linsner at cisco.com;
> > > hannes.tschofenig at nsn.com
> > > > > > Subject: Re: [Ecrit] Location Protocols in Phone BCP
> > > > > >
> > > > > > I think we need to pull up a level.  It's not reasonable
> > > > > for an RFC to
> > > > > > try to list all of the location protocols out there, if for
> > > > > no other
> > > > > > reason than that it will rapidly become obsolete.  Instead,
> > > > > we should
> > > > > > say something like the following:
> > > > > >
> > > > > > "
> > > > > > INT-12 Devices MUST support the DHCP location options
> > > > [RFC4776] and
> > > > > > [RFC3825] and HELD
> > > > > [I-D.ietf-geopriv-http-location-delivery].  Devices
> > > > > > SHOULD support all location protocols supported at lower
> > > > layers by
> > > > > > their interfaces (e.g., LLDP-MED [LLDP-MED]).
> > > > > > "
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > Brian Rosen wrote:
> > > > > >> The problem with SUPL is that the majority of networks
> > > > where SUPL
> > > > > >> would
> > > > > be
> > > > > >> available have a proxy (E-CSCF) insert location.  It
> > > also has an
> > > > > >> incompatible location representation, and an incompatible
> > > > > privacy model.
> > > > > >> That makes it very hard to interwork with any of the rest
> > > > > of the IETF
> > > > > > work.
> > > > > >> I will say this.  For quite some time, the IETF has been
> > > > trying to
> > > > > > interest
> > > > > >> OMA into cooperation on location so that we have
> > > > > interoperability at
> > > > > >> the protocol, location representation and privacy
> > > > levels.  So far,
> > > > > >> that has
> > > > > > not
> > > > > >> happened.  If, as part of a comprehensive agreement to
> > > > accomplish
> > > > > >> such a goal, SUPL became one of the LCPs, I would 
> not object.
> > > > > >>
> > > > > >> Brian
> > > > > >>
> > > > > >> -----Original Message-----
> > > > > >> From: ecrit-bounces at ietf.org
> > > [mailto:ecrit-bounces at ietf.org] On
> > > > > >> Behalf Of Gabor.Bajko at nokia.com
> > > > > >> Sent: Thursday, November 20, 2008 9:26 AM
> > > > > >> To: James.Winterbottom at andrew.com; ecrit at ietf.org
> > > > > >> Cc: hannes.tschofenig at nsn.com; marc.linsner at cisco.com
> > > > > >> Subject: Re: [Ecrit] Location Protocols in Phone BCP
> > > > > >>
> > > > > >> Hi,
> > > > > >>
> > > > > >> Is the intent to list the LCPs which are access-type
> > > > > agnostic but not
> > > > > >> supported anywhere, or instead have a list of LCPs which
> > > > > are highly
> > > > > >> probable to produce the intended result?
> > > > > >>
> > > > > >> There are restrictions everywhere, things come at a cost
> > > > > even in the
> > > > > >> general Internet model. The reality is that most of the
> > > > > devices with
> > > > > >> internet access have a home network already.
> > > > > >>
> > > > > >> - Gabor
> > > > > >>
> > > > > >>
> > > > > >>   >-----Original Message-----
> > > > > >>   >From: ext Winterbottom, James
> > > > > [mailto:James.Winterbottom at andrew.com]
> > > > > >>   >Sent: Thursday, November 20, 2008 12:06 AM
> > > > > >>   >To: Bajko Gabor (Nokia-CIC/MtView); ecrit at ietf.org
> > > > > >>   >Cc: marc.linsner at cisco.com; Tschofenig Hannes (NSN
> > > - FI/Espoo)
> > > > > >>   >Subject: RE: [Ecrit] Location Protocols in Phone BCP
> > > > > >>   >
> > > > > >>   >Hi Gabor,
> > > > > >>   >
> > > > > >>   >The list of LCPs in the phone BCP is a must support
> > > > list, and is
> > > > > >> access-
> > > > > >>   >type agnostic.
> > > > > >>   >I am curious that you say that SUPL is a MUST support
> > > > > given that:
> > > > > >>   >a) it requires a home network in order to operate
> > > > > >>   >b) it simply doesn't work for DSL or Cable
> > > > > >>   >c) it is questionable whether it is really deployable
> > > > for WiFi
> > > > > >> networks
> > > > > >>   >
> > > > > >>   >Can you perhaps describe how it fits into the general
> > > > > Internet model?
> > > > > >>   >
> > > > > >>   >Cheers
> > > > > >>   >James
> > > > > >>   >
> > > > > >>   >
> > > > > >>   >-----Original Message-----
> > > > > >>   >From: ecrit-bounces at ietf.org on behalf of
> > > > Gabor.Bajko at nokia.com
> > > > > >>   >Sent: Thu 11/20/2008 12:48 AM
> > > > > >>   >To: ecrit at ietf.org
> > > > > >>   >Cc: marc.linsner at cisco.com; hannes.tschofenig at nsn.com
> > > > > >>   >Subject: Re: [Ecrit] Location Protocols in Phone BCP
> > > > > >>   >
> > > > > >>   >I was requested to send my observations regarding this
> > > > > requirement:
> > > > > >>   >
> > > > > >>   >  ED-21/INT-12 Devices MUST support all of: DHCP
> > > > > location options
> > > > > >>   >   [RFC4776] and [RFC3825], HELD
> > > > > >>   >   [I-D.ietf-geopriv-http-location-delivery] and
> > > > > LLDP-MED [LLDP-MED].
> > > > > >>   >
> > > > > >>   >
> > > > > >>   >I believe we should come up with a list of LCPs which
> > > > > are likely
> > > > > >> to be
> > > > > >>   >supported in devices in a not so distant future. Since
> > > > > I have no
> > > > > >> seen or
> > > > > >>   >heard about LLDP support yet, at least that should be
> > > > replaced
> > > > > >> with what
> > > > > >>   >is mostly used today (OMA SUPL) and the 802.11
> > > > > mechanism, with the
> > > > > >>   >condition that this MUST only be supported if there
> > > is a wifi
> > > > > >> interface
> > > > > >>   >available on the device.
> > > > > >>   >
> > > > > >>   >- Gabor
> > > > > >>   >
> > > > > >>   >
> > > > > >>   >
> > > > > >>   >________________________________
> > > > > >>   >
> > > > > >>   >From: ext Tschofenig, Hannes
> > > > > >>   >
> > > > > >>   >Sent: Tuesday, November 18, 2008 12:49 PM
> > > > > >>   >To: Bajko Gabor (Nokia-CIC/MtView); 
> marc.linsner at cisco.com
> > > > > >>   >Subject: Location Protocols in Phone BCP
> > > > > >>   >
> > > > > >>   >
> > > > > >>   >
> > > > > >>   >Gabor,
> > > > > >>   >
> > > > > >>   >Could you please raise your question about location
> > > > > protocols in
> > > > > >> Phone
> > > > > >>   >BCP mentioned at ESW5 in the ECRIT WG session again?
> > > > > >>   >
> > > > > >>   >Ciao
> > > > > >>   >Hannes
> > > > > >>   >
> > > > > >>   >
> > > > > >>
> > > > > >>>
> > > > >
> > > 
> --------------------------------------------------------------------
> > > > > >>> ---
> > > > > >> --
> > > > > >>   >-----------------------
> > > > > >>   >This message is for the designated recipient 
> only and may
> > > > > >>   >contain privileged, proprietary, or otherwise private
> > > > > information.
> > > > > >>   >If you have received it in error, please notify 
> the sender
> > > > > >>   >immediately and delete the original.  Any
> > > unauthorized use of
> > > > > >>   >this email is prohibited.
> > > > > >>
> > > > > >>>
> > > > >
> > > 
> --------------------------------------------------------------------
> > > > > >>> ---
> > > > > >> --
> > > > > >>   >-----------------------
> > > > > >>   >[mf2]
> > > > > >>
> > > > > >> _______________________________________________
> > > > > >> Ecrit mailing list
> > > > > >> Ecrit at ietf.org
> > > > > >> https://www.ietf.org/mailman/listinfo/ecrit
> > > > > >>
> > > > > >> _______________________________________________
> > > > > >> Ecrit mailing list
> > > > > >> Ecrit at ietf.org
> > > > > >> https://www.ietf.org/mailman/listinfo/ecrit
> > > > > >>
> > > > > >
> > > > > >
> > > > >
> > > > > _______________________________________________
> > > > > Ecrit mailing list
> > > > > Ecrit at ietf.org
> > > > > https://www.ietf.org/mailman/listinfo/ecrit
> > > > >
> > > >
> > > > CONFIDENTIALITY NOTICE: The information contained in this
> > > message may
> > > > be privileged and/or confidential. If you are not the intended 
> > > > recipient, or responsible for delivering this message to
> > > the intended
> > > > recipient, any review, forwarding, dissemination, 
> distribution or 
> > > > copying of this communication or any attachment(s) is strictly 
> > > > prohibited. If you have received this message in error,
> > > please notify
> > > > the sender immediately, and delete it and all attachments from
> your
> > > > computer and network.
> > > > _______________________________________________
> > > > Ecrit mailing list
> > > > Ecrit at ietf.org
> > > > https://www.ietf.org/mailman/listinfo/ecrit
> > > >
> > > > *****
> > > >
> > > > The information transmitted is intended only for the person
> > > or entity
> > > > to which it is addressed and may contain confidential,
> proprietary,
> > > > and/or privileged material. Any review, retransmission,
> > > dissemination
> > > > or other use of, or taking of any action in reliance upon this 
> > > > information by persons or entities other than the intended
> > > recipient
> > > > is prohibited. If you received this in error, please 
> contact the 
> > > > sender and delete the material from all computers. GA621
> > > >
> > > >
> > > >
> > >
> > >
> > _______________________________________________
> > Ecrit mailing list
> > Ecrit at ietf.org
> > https://www.ietf.org/mailman/listinfo/ecrit
> 
> --------------------------------------------------------------
> ----------------------------------
> This message is for the designated recipient only and may 
> contain privileged, proprietary, or otherwise private information.  
> If you have received it in error, please notify the sender 
> immediately and delete the original.  Any unauthorized use of 
> this email is prohibited.
> --------------------------------------------------------------
> ----------------------------------
> [mf2]
> 
> 
_______________________________________________
Ecrit mailing list
Ecrit at ietf.org
https://www.ietf.org/mailman/listinfo/ecrit