Re: [Ecrit] Location Protocols in Phone BCP

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

James:
My scenario was the non-IMS one (no P-CSCFs, etc.)

-roger. 

> -----Original Message-----
> From: Winterbottom, James [mailto:James.Winterbottom at andrew.com] 
> Sent: Thursday, November 20, 2008 3:30 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
> 
> Hi Roger,
> 
> You and I have a different understanding then on how SUPL is 
> invoked for emergency calling.
> 
> It is my understanding that a SET has N x E-SLP certificates 
> configured into it.
> 
> When an emergency call is made, the network (P-CSCF) 
> determines that an emergency call is being made, and proceeds 
> to contact the local E-SLP.
> At that point, the E-SLP contacts the device, and IF the 
> device has the cert for that E-SLP, then it will initiate 
> communication back to the E-SLP for SUPL to continue.
> 
> This is not really device discovery of the LCP-server in the 
> same way that is done for HELD or DHCP.
> 
> Cheers
> James
> 
> 
> > -----Original Message-----
> > From: Roger Marshall [mailto:RMarshall at telecomsys.com]
> > Sent: Friday, 21 November 2008 10:10 AM
> > To: Winterbottom, James; 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
> > 
> > Wait on... not the case for non-IMS emergency calls in SUPL.
> > 
> > While it is true that SUPL goes to its home network for commercial 
> > location and for any IMS call, it is not specified to do so with
> non-IMS
> > Emergency Roaming in SUPL 2.0 (Section 5.1.15.3).  For that, an 
> > emergency call uses the local (visited) E-SLP (and lesser-tiered
> V-SLP).
> > Both are assumed to be in the visited network.  The device discovers
> the
> > E-SLP via MNC/MCC (network & country codes) supplied.
> > 
> > -roger.
> > 
> > > -----Original Message-----
> > > From: Winterbottom, James [mailto:James.Winterbottom at andrew.com]
> > > Sent: Thursday, November 20, 2008 2:07 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
> > >
> > > Only if the device is connected to its home network, else you 
> > > require a world in a database solution. Inter-carrier 
> roaming with 
> > > SUPL is problematic to say the least.
> > >
> > > 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:13 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
> > > >
> > > > No objection to saying that SUPL in its present form is 
> not a good 
> > > > choice for wire-map, but would object to saying the 
> same for other
> > > types
> > > > of 'non-measured' location.
> > > >
> > > > Rather, SUPL is in fact an excellent choice for
> > > non-endpoint measured
> > > > location such as 'CellID'.
> > > >
> > > > -roger.
> > > >
> > > > > -----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]
> > >
> > >
> 
> --------------------------------------------------------------
> ----------------------------------
> 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