[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Ecrit] Location Protocols in Phone BCP
The plane is a great example of an indirect connection to a network. My RV
was another. You can't make assumptions about mobility or anything else of
relevance to the group from the characteristics of the device placing the
emergency call, or it's first hop connection. It's another example of how
difficult it is to make use of layer 2 specific LCPs. Generally, assuming
that bridging devices will bridge LCPs is a losing proposition.
Brian
-----Original Message-----
From: ecrit-bounces at ietf.org [mailto:ecrit-bounces at ietf.org] On Behalf Of
Thomson, Martin
Sent: Friday, November 21, 2008 11:43 AM
To: Roger Marshall
Cc: ecrit at ietf.org
Subject: Re: [Ecrit] Location Protocols in Phone BCP
I strongly disagree with this from a philosophical standpoint. Type of
access should only affect protocol design where attributes of that access
affect the protocol.
For instance, we design protocols for networks with long delays, which
happen to be applicable to inter-planetary communication. This means that
when someone uses that protocol for shipping data on reindeer, it doesn't
break because someone assumes that it a radio link in space.
So, what we need to do is identify attributes of the network that are
relevant to the protocol design. As far as the document is currently
specified, the attribute that we're interested in is mobility - that is, the
fact that location changes. Do not mistakenly assign this attribute to
wireless networks.
For an example of how this is harmful, imagine that it is possible that a
wired connection on a plane (now, why don't they do that...seems logical).
If we had a client that was on a wire, there is the risk that they continue
this assumption to detrimental effect.
Cheers,
Martin
> -----Original Message-----
> From: ecrit-bounces at ietf.org [mailto:ecrit-bounces at ietf.org] On Behalf
> Of Roger Marshall
> Sent: Friday, 21 November 2008 9:29 AM
> To: DRAGE, Keith (Keith); 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
>
> Keith:
> I agree completely with the first part of what you said, and want to
> clarify my intent of highlighting differences in general:
>
> We've already got different requirements by access 'type' (i.e.,
> 'wireless' and 'mobile' mentioned by name), so for some other
> requirements - certainly, I would think those that mention the term
> 'wire database' - those imply their application to a fixed type of
> network access (it wouldn't work to well for mobile).
>
> What I was asking for, (and to my understanding, it was agreed to in
> the
> ecrit meeting), was that since these requirements already mention
> different access types, that there should be some additional text that
> acknowledges the existance of these different access types, as
> background for their respective requirements.
>
> -roger.
>
>
> > -----Original Message-----
> > From: DRAGE, Keith (Keith) [mailto:drage at alcatel-lucent.com]
> > Sent: Thursday, November 20, 2008 9:22 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
> >
> > We are moving towards a state where devices support multiple
> > of these, and in some cases where they may be active at the same
> time.
> >
> > We certainly already have devices that may be simultaneously
> > registered in WLAN and 3GPP access.
> >
> > As soon as you start distinguishing any type of phone by
> > access technology, you will end up with these devices having
> > to support multiple different requirements.
> >
> > regards
> >
> > Keith
> >
> > > -----Original Message-----
> > > From: ecrit-bounces at ietf.org
> > [mailto:ecrit-bounces at ietf.org] On Behalf
> > > Of Roger Marshall
> > > Sent: Thursday, November 20, 2008 9:07 PM
> > > 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
> > >
> >
> _______________________________________________
> 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
_______________________________________________
Ecrit mailing list
Ecrit at ietf.org
https://www.ietf.org/mailman/listinfo/ecrit