RE: [Ecrit] RE: Comments on: draft-ietf-ecrit-phonebcp-01

["Brian Rosen" <br at brianrosen.net>]

So far, the location hiding thing is you get coarse location and you LoST
route with it.  There are people unhappy with that, who want the LCP to
return LoST data, or LoST to do dereference.  My read of rough consensus was
coarse location, but chairs have to call that one.

Brian

> -----Original Message-----
> From: Winterbottom, James [mailto:James.Winterbottom at andrew.com]
> Sent: Friday, June 01, 2007 6:30 PM
> To: Brian Rosen; Matt Lepinski; ECRIT; James M. Polk
> Subject: RE: [Ecrit] RE: Comments on: draft-ietf-ecrit-phonebcp-01
> 
> Except that the end-point doesn't do the LoST thing
> 
> 
> > -----Original Message-----
> > From: Brian Rosen [mailto:br at brianrosen.net]
> > Sent: Saturday, 2 June 2007 8:29 AM
> > To: Winterbottom, James; 'Matt Lepinski'; 'ECRIT'; 'James M. Polk'
> > Subject: RE: [Ecrit] RE: Comments on: draft-ietf-ecrit-phonebcp-01
> >
> > But that is case 1
> >
> > > -----Original Message-----
> > > From: Winterbottom, James [mailto:James.Winterbottom at andrew.com]
> > > Sent: Friday, June 01, 2007 6:24 PM
> > > To: Brian Rosen; Matt Lepinski; ECRIT; James M. Polk
> > > Subject: RE: [Ecrit] RE: Comments on: draft-ietf-ecrit-phonebcp-01
> > >
> > > I was assuming that the end-point is given a location URI, local
> > > dialsring, and service URNs. Say in the location hiding case.
> > >
> > >
> > > > -----Original Message-----
> > > > From: Brian Rosen [mailto:br at brianrosen.net]
> > > > Sent: Saturday, 2 June 2007 8:18 AM
> > > > To: Winterbottom, James; 'Matt Lepinski'; 'ECRIT'; 'James M. Polk'
> > > > Subject: RE: [Ecrit] RE: Comments on: draft-ietf-ecrit-phonebcp-01
> > > >
> > > > If by that you mean the endpoint gets location, recognizes an
> > > emergency
> > > > call, but does not route, then the proxy server has to route.
> That
> > > case
> > > > is
> > > > complex because without the LoST query, the endpoint doesn't have
> the
> > > > local
> > > > dialstring(s).
> > > >
> > > > If that was not what you mean, then who routes?
> > > >
> > > > Brian
> > > >
> > > > > -----Original Message-----
> > > > > From: Winterbottom, James [mailto:James.Winterbottom at andrew.com]
> > > > > Sent: Friday, June 01, 2007 5:35 PM
> > > > > To: Brian Rosen; Matt Lepinski; ECRIT; James M. Polk
> > > > > Subject: RE: [Ecrit] RE: Comments on:
> draft-ietf-ecrit-phonebcp-01
> > > > >
> > > > > I think that there is one other variant on two.
> > > > >
> > > > > The End-point makes the call the service URN and includes a
> provided
> > > > > locationURI. Outbound-proxy does nothing special.
> > > > >
> > > > > > -----Original Message-----
> > > > > > From: Brian Rosen [mailto:br at brianrosen.net]
> > > > > > Sent: Friday, 1 June 2007 10:36 PM
> > > > > > To: 'Matt Lepinski'; 'ECRIT'; 'James M. Polk'
> > > > > > Subject: [Ecrit] RE: Comments on: draft-ietf-ecrit-phonebcp-01
> > > > > >
> > > > > > Thanks for your comments.
> > > > > >
> > > > > > The BCP really shouldn't be SIP specific.  We need to broaden
> it
> > > to,
> > > > > for
> > > > > > example, XMPP.  We can have SIP specific information, but it
> > > should be
> > > > > > discussed as just that.
> > > > > >
> > > > > > There is a consensus, I believe, on how to mark emergency
> calls,
> > > > > > represented
> > > > > > by the thread, but chairs have to call consensus, not me.  I
> think
> > > > > there
> > > > > > are
> > > > > > three cases:
> > > > > > 1. The endpoint recognizes it's an emergency call, does the
> LoST
> > > > > routing,
> > > > > > and passes the call to its outbound proxy server.  In this
> case
> > > the
> > > > > > Request
> > > > > > URI will be the PSAP URI from LoST, and adds a Route header
> with
> > > the
> > > > > > service
> > > > > > URN.
> > > > > > 2. The endpoint recognizes it's an emergency call, but doesn't
> > > LoST
> > > > > route
> > > > > > it.  In this case the Request URI would be the service URN.
> The
> > > > > outbound
> > > > > > proxy server would do the LoST routing, put the Route header
> with
> > > the
> > > > > > service URN in and change the Request URI to the PSAP URI.
> > > > > > 3. The endpoint doesn't even recognize it's an emergency call.
> In
> > > > > this
> > > > > > case, the endpoint would put the dialstring in the Request
> URI.
> > > The
> > > > > > outbound proxy would behave as in 2 above.
> > > > > >
> > > > > > When the PSAP gets the call, it will always have its URI in
> the
> > > > > Request
> > > > > > URI,
> > > > > > and there will be a service URN in a Route header.
> > > > > >
> > > > > > Probably, phonebcp should say that more clearly.
> > > > > >
> > > > > > Brian
> > > > > >
> > > > > > > -----Original Message-----
> > > > > > > From: Matt Lepinski [mailto:mlepinski at bbn.com]
> > > > > > > Sent: Friday, June 01, 2007 12:49 AM
> > > > > > > To: ECRIT; James M. Polk; br at brianrosen.net
> > > > > > > Subject: Comments on: draft-ietf-ecrit-phonebcp-01
> > > > > > >
> > > > > > > Brian and James:
> > > > > > >
> > > > > > > First, two very high level questions.
> > > > > > >
> > > > > > > A) [Is this document supposed to be SIP-Centric?] It is
> unclear
> > > to
> > > > > me
> > > > > > > whether the document is intended as a BCP for SIP User
> Agents
> > > and
> > > > > SIP
> > > > > > > proxies, or whether it is more generally a BCP for end
> points
> > > and
> > > > > > > signaling-path devices which may or may not use SIP. For
> > > instance,
> > > > > > > Section 6.4 is written as though SIP signaling were a
> special
> > > case,
> > > > > and
> > > > > > > yet paragraph four of Section 5 indicates that all emergency
> > > calls
> > > > > on
> > > > > > > the wire should contain a Route header (which is a
> SIP-specific
> > > > > > > signaling component). Personally, I don't care whether or
> not
> > > the
> > > > > > > document is SIP centric, or whether SIP is a special case,
> as
> > > long
> > > > > as
> > > > > > > the document is consistent.
> > > > > > >
> > > > > > > B) [Is there consensus on how to mark emergency calls?] The
> > > current
> > > > > > > version of phonebcp indicates that (in the normal case when
> > > > > end-points
> > > > > > > perform the LoST mapping) emergency calls are marked by
> putting
> > > the
> > > > > URN
> > > > > > > in a Route header (with a "loose" parameter that I'm not
> > > familiar
> > > > > with
> > > > > > > ... can someone provide me with a reference) and that the
> URN is
> > > > > placed
> > > > > > > in the Request-URI when the end-point is unable to perform
> the
> > > LoST
> > > > > > > mapping). Personally, I don't understand the current
> mechanism
> > > > > because
> > > > > > > I'm not sure what an "ordinary" (RFC3261-compliant) proxy
> does
> > > when
> > > > > it
> > > > > > > sees a service URN in the top Route header. However, given
> the
> > > long
> > > > > > > discussion that occured on call marking in January (See:
> > > > > > >
> > > http://www1.ietf.org/mail-archive/web/ecrit/current/msg02963.html),
> > > > > > > perhaps the more important question is "Has consensus been
> > > reached
> > > > > that
> > > > > > > (something like) the current mechanism is an appropriate way
> to
> > > mark
> > > > > > > messages?"
> > > > > > >
> > > > > > > ---------------------------------
> > > > > > > More detailed comments:
> > > > > > >
> > > > > > > Section 2: (paragraph 3 - number 2)
> > > > > > > Is it clear what the "visited location's emergency number"
> means
> > > in
> > > > > this
> > > > > > > context?
> > > > > > > Consider changing to "the local emergency number for its
> current
> > > > > > > location" or providing a forward reference to the discussion
> of
> > > > > > > dial-strings in Section 5.
> > > > > > >
> > > > > > > Section 2: (paragraph 4)
> > > > > > > I agree with Barbara that if this is intended to an overview
> of
> > > call
> > > > > > > setup for the special case of an Ethernet connected phone
> then
> > > the
> > > > > > > bullets should match up more clearly with the numbered items
> in
> > > the
> > > > > > > previous paragraph.
> > > > > > >
> > > > > > > Section 2: (last paragraph)
> > > > > > > It is unclear whether the antecedent of "it" in the last
> > > paragraph
> > > > > is
> > > > > > > [RFC4103] or [RFC4504].
> > > > > > >
> > > > > > > Section 3:
> > > > > > > Consider changing "should support" to "SHOULD support"
> > > > > > >
> > > > > > > Section 3: (paragraph 2)
> > > > > > > It seems that the point of this paragraph is to say that a
> > > certain
> > > > > class
> > > > > > > of devices that communicates over IP networks should support
> > > > > emergency
> > > > > > > calls. However, I find the phrase "using current (evolving)
> > > > > standards"
> > > > > > > to be unclear and in particular I'm not sure what the phrase
> > > > > modifies.
> > > > > > > (E.g. Do you mean "Devices that create media sessions using
> > > current
> > > > > > > (evolving) standards and exchange audio ...")
> > > > > > >
> > > > > > > Section 4: (first paragraph)
> > > > > > > Consider replacing "the norm" with "required" (or a similar
> > > word). I
> > > > > > > think the point is not that automatic location is
> common/normal
> > > but
> > > > > that
> > > > > > > it is necessary since most users are unable to provide
> accurate
> > > > > > location.
> > > > > > >
> > > > > > > Section 4.1: (first paragraph)
> > > > > > > I think "cellular" (or "traditional wireless")  is more
> precise
> > > than
> > > > > > > "mobile".
> > > > > > >
> > > > > > > Section 4.2: (first paragraph ... also, the last paragraph)
> > > > > > > Consider changing the phrase "the desired result" to
> something
> > > like
> > > > > "an
> > > > > > > equivalent result", or perhaps something even more explicit.
> > > > > > >
> > > > > > > Section 4.2: (first paragraph)
> > > > > > > Consider addition a phrase to the last sentence indicating
> why
> > > it is
> > > > > > > recommended that the network support a standardized LCP.
> (This
> > > may
> > > > > not
> > > > > > > be obvious to the reader). Also, consider changing
> "recommended"
> > > to
> > > > > > > "RECOMMENDED".
> > > > > > >
> > > > > > > Section 4.2: (paragraph 2)
> > > > > > > Given that the paragraph covers what both devices and access
> > > > > networks
> > > > > > > MUST support, consider changing "For all other devices" to
> "In
> > > all
> > > > > other
> > > > > > > scenarios".
> > > > > > >
> > > > > > > Section 4.3: (paragraph 3)
> > > > > > > The term "geo-location" is not used in RFC 3825 to describe
> a
> > > > > > > lat/lon/alt - style location. (Instead it uses terms like a
> > > > > > > "coordinate-based geolocation"). Also, given that the
> > > "geolocation"
> > > > > > > header allows for civic locations, I think using
> geo-location
> > > here
> > > > > is
> > > > > > > potentially confusing.
> > > > > > > Note: This comment also applies to the use of "geo reported"
> in
> > > the
> > > > > > > third paragraph of Section 6.3
> > > > > > >
> > > > > > > Section 4.4:  (last paragraph)
> > > > > > > Consider re-writing the second-to-the-last sentence as:
> "Certain
> > > > > > > commonly-used techniques for measuring location create a
> > > conflict
> > > > > > > between the time it takes to generate a precise location and
> the
> > > > > desire
> > > > > > > to route the call quickly." (Also, in the following sentence
> I
> > > think
> > > > > > > "precise" is a better word than "accurate")
> > > > > > >
> > > > > > > Section 5: (paragraphs 5 and 6)
> > > > > > > Paragraph 5 says that devices MUST mark calls using a
> > > service:sos
> > > > > URN.
> > > > > > > However, paragraph 6 says that mapping from dialstring to
> URN
> > > SHOULD
> > > > > be
> > > > > > > done by the endpoint. Either both paragraphs should use
> "MUST"
> > > or
> > > > > else
> > > > > > > they should both use "SHOULD".
> > > > > > >
> > > > > > > Section 5: (paragraph 8)
> > > > > > > I don't understand what it means to be "roaming" or
> "nomadic" in
> > > a
> > > > > > > system where there is no "visited network"
> > > > > > >
> > > > > > > Section 5: (last paragraph)
> > > > > > > The last sentence of this paragraph seems to be redundent.
> > > Consider
> > > > > > > deleting it.
> > > > > > >
> > > > > > > Section 6.1:
> > > > > > > I agree with Barbara that the use of IPSec should not be
> > > prohibited
> > > > > by
> > > > > > > this BCP.
> > > > > > >
> > > > > > > Section 6.1: (number 6)
> > > > > > > These instructions are for the User Agent,
> P-Asserted-Identity
> > > > > headers
> > > > > > > and Identity headers should not be inserted by the UA
> > > > > > >
> > > > > > > Section 6.1: (number 10)
> > > > > > > This item is unclear to me. Is the author's intention that
> this
> > > item
> > > > > > > handles the case where a UA does not know its own location?
> If
> > > so, I
> > > > > > > guess that updating this item should be deferred until
> consensus
> > > is
> > > > > > > reached on location-hiding.
> > > > > > >
> > > > > > > Section 6.1:
> > > > > > > Consider Re-ordering the items as:
> > > > > > > 11, 10, 12, 14, 15, 13
> > > > > > > Also, consider deleting 12, I believe it is redundent given
> 9,
> > > 10
> > > > > and
> > > > > > 11.
> > > > > > >
> > > > > > > Section 6.2: (number 1)
> > > > > > > Consider adding an example after "... URN appropriate for
> the
> > > > > emergency
> > > > > > > dialstring." That is, consider adding (e.g., ...)
> > > > > > >
> > > > > > > Section 6.2: (number 3)
> > > > > > > I'm afraid that I don't understand the meaning of this
> sentence.
> > > > > > >
> > > > > > > Section 6.3: (paragraph 3)
> > > > > > > The sentence that begins "This can be an enclosing ..." is
> > > unclear
> > > > > to
> > > > > > > me. Are you suggesting that when a PSAP coverage region is
> > > complex,
> > > > > that
> > > > > > > a LoST server SHOULD return a simple polygon that (a)
> contains
> > > the
> > > > > > > location of the device; and (b) is entirely contained within
> the
> > > > > PSAP
> > > > > > > coverage region?
> > > > > > >
> > > > > > > Section 6.5: (number 3)
> > > > > > > This seems to imply that proxies should expect to SUBSCRIBE
> to
> > > > > Presence.
> > > > > > > Do you mean that proxies should expect the PSAP to SUBSCRIBE
> to
> > > > > > Presence?
> > > > > > >
> > > > > > > Section 6.5: (number 4)
> > > > > > > I'm not very familiar with Session Timers, can you provide a
> > > > > reference.
> > > > > > >
> > > > > > > Section 6.6:
> > > > > > > I'm afraid I don't understand the parenthetical remark after
> the
> > > > > "Call
> > > > > > > Forward" bullet. (Consider removing the remark or re-wording
> it
> > > if
> > > > > it is
> > > > > > > important).
> > > > > > >
> > > > > > > Section 7:
> > > > > > > Given the text in Section 4.4 it seems to me that the first
> > > > > paragraph of
> > > > > > > Section 7 is redundent and should be deleted.
> > > > > > >
> > > > > > > Section 10.2:
> > > > > > > Given the difficulty of implementing location signing in a
> > > useful
> > > > > > > manner, I think that that either paragraph 2 should either
> be
> > > > > removed or
> > > > > > > else it should reference some other document that explains
> > > location
> > > > > > > signing in more detail. (That is, one paragraph does not do
> > > location
> > > > > > > signing justice and it seems irresponsible to strongly
> recommend
> > > > > > > location signing without providing additionaly guidence to
> the
> > > > > > > implementor).
> > > > > > >
> > > > > > >
> > > -------------------------------------------------------------------
> > > > > > > Minor Nits: (That don't change the meaning of the text)
> > > > > > >
> > > > > > > Section 2: (last paragraph)
> > > > > > > Put a space between [RFC4103] and "media"
> > > > > > >
> > > > > > > Section 3: (paragraph 1)
> > > > > > > Add commas to second sentence "Future PSAPs will, however,
> > > support
> > > > > ..."
> > > > > > > and remove the extra period at the end of the sentence
> > > > > > >
> > > > > > > Section 4.1: (paragraph 2)
> > > > > > > Change "... where it is the access network that knows the
> > > location
> > > > > ..."
> > > > > > > to "... when only the access network knows the location ..."
> > > > > > >
> > > > > > > Section 4.4: (paragraph 1)
> > > > > > > Change "... process engaged from establishing a VPN ... " to
> > > "...
> > > > > > > process engaged by establishing a VPN ..."
> > > > > > >
> > > > > > > Section 4.4: (paragraph 2)
> > > > > > > Change "... related to the mobility of the device and ..."
> to
> > > "...
> > > > > > > related to the degree of device mobility and ..."
> > > > > > >
> > > > > > > Section 4.4: (paragraph 2)
> > > > > > > Combine the final 2 sentances as follows:
> > > > > > > "When a device is aware that it has moved, for instance when
> it
> > > > > changes
> > > > > > > access points, the device SHOULD refresh its location."
> > > > > > >
> > > > > > > Section 4.4: (last paragraph)
> > > > > > > Change "... getting more recent location ..." to "...
> getting
> > > > > updated
> > > > > > > location ..." or "... obtaining a fresh location"
> > > > > > >
> > > > > > > Section 5: (first paragraph)
> > > > > > > Consider re-writing as:
> > > > > > > "A device (or a downstream signaling element) identifies an
> > > > > emergency
> > > > > > > call by an "address", which in most cases is a dialstring,
> > > although
> > > > > > > other user interfaces may be used."
> > > > > > >
> > > > > > > Section 5: (paragraph 2)
> > > > > > > First sentence has too many words modifying the word
> "element".
> > > > > > Consider:
> > > > > > > "Note: It is undesirable for a user-interface to enable a
> user
> > > to
> > > > > place
> > > > > > > an emergency call by pressing a single button."
> > > > > > >
> > > > > > > Section 5: (paragraph 3)
> > > > > > > Consider changing the first sentence:
> > > > > > > "... in other countries there are several 3 digit numbers
> used
> > > for
> > > > > > > different types of emergency calls."
> > > > > > >
> > > > > > > Section 5: (paragraph 6)
> > > > > > > Change "... some entity needs to ..." to "... some entity on
> the
> > > > > > > signaling path must ..."
> > > > > > >
> > > > > > > Section 5: (paragraph 9)
> > > > > > > Change "... from North America, the home ..." to "... from
> North
> > > > > > > America, then while in North America the home ..."
> > > > > > >
> > > > > > > Section 5: (last paragraph)
> > > > > > > Add a close parenthesis ")" after "dialstrings."
> > > > > > >
> > > > > > > Section 6:
> > > > > > > Change "... is expected be supported ..." to "... is
> expected to
> > > be
> > > > > > > supported ..."
> > > > > > >
> > > > > > > Section 6.1:
> > > > > > > Change "signaling Method" to "signaling method" (lower
> case).
> > > > > > >
> > > > > > > Section 6.1: (number 1)
> > > > > > > Change "To: SHOULD" to "Request-URI: SHOULD"
> > > > > > >
> > > > > > > Section 6.1: (number 2)
> > > > > > > Add a space between [I-D.rosen-iptel-dialstring] and "with"
> > > > > > > Also change "sips MUST be ..." to "a sips URI MUST be ..."
> > > > > > >
> > > > > > > Section 6.2: (number 1)
> > > > > > > Change "If it finds it it MUST:" to "If it finds the
> dialstring
> > > it
> > > > > > MUST:"
> > > > > > > Also, change "... for the endpoint" to "... of the end
> device."
> > > > > (note
> > > > > > > that period was missing)
> > > > > > >
> > > > > > > Section 6.3: (paragraph 3)
> > > > > > > Non-parallel sentence structure. Consider re-writing the
> last
> > > > > sentence
> > > > > > as:
> > > > > > > "In the case of civic location, the LoST server SHOULD
> report
> > > that
> > > > > the
> > > > > > > same mapping is good within a community name or even a
> street,
> > > as
> > > > > this
> > > > > > > is helpful for WiFi connected devices that roam and obtain
> civic
> > > > > > > location from the AP to which they connect."
> > > > > > > (Or perhaps "Despite the fact that civic location is
> uncommon
> > > for
> > > > > mobile
> > > > > > > devices, the LoST server SHOULD ...")
> > > > > > >
> > > > > > > Section 6.3: (paragraph 4)
> > > > > > > Change "... URI of the service URN ..." to "... URI of a
> service
> > > URN
> > > > > > ..."
> > > > > > >
> > > > > > > Section 6.3: (last paragraph)
> > > > > > > Re-write the last sentence as: "The proxy then replaces the
> > > > > Request-URI
> > > > > > > with the resulting PSAP URI."
> > > > > > > Or perhaps "The resulting PSAP URI then replaces the
> > > Request-URI"
> > > > > > >
> > > > > > > Section 6.4: (first paragraph)
> > > > > > > Consider adding the phrase "Once the mapping to a PSAP URI
> has
> > > been
> > > > > > > performed," to the begining of the paragraph (to improve the
> > > flow of
> > > > > the
> > > > > > > document).
> > > > > > >
> > > > > > > Section 6.6:
> > > > > > > Change "The emergency dialstrings ..." to "Emergency
> dialstrings
> > > > > ..."
> > > > > > >
> > > > > > > Section 7: (paragraph 3)
> > > > > > > Change "For calls send with ..." to "For calls sent with
> ..."
> > > > > > >
> > > > > > > Section 8: (paragraph 1)
> > > > > > > Change "... media streams on RTP ... " to "... media stream
> > > using
> > > > > RTP
> > > > > > ..."
> > > > > > > or perhaps "... media streams via RTP ..."
> > > > > > > Also, consider re-writing the 4th sentence as:
> > > > > > > "Future IP-enabled PSAPs should accept a wider array of
> > > potential
> > > > > media
> > > > > > > types."
> > > > > > >
> > > > > > > Section 8: (paragraph 2)
> > > > > > > Add a period between "the offer" and "Silence suppression".
> > > > > > >
> > > > > > > Section 10:
> > > > > > > Change "... it specifies use of several ..." to "... it
> > > specifies
> > > > > the
> > > > > > > use of several ..."
> > > > > > >
> > > > > > > Section 10.1: (paragraph 2)
> > > > > > > Change "... DHCP is the LCP [RFC3118] ..." to "... DHCP is
> the
> > > LCP,
> > > > > > > [RFC3118] ..." (add a comma)
> > > > > > > Also, change "... spoofing would be ..." to "... spoofing is
> > > ..."
> > > > > > >
> > > > > > > Section 10.1: (last paragraph)
> > > > > > > Add an 's' to change "Client SHOULD" to "Clients SHOULD"
> > > > > > >
> > > > > > > Section 10.2: (last paragraph)
> > > > > > > Change "... signaling would help significantly." to "...
> > > signaling
> > > > > helps
> > > > > > > significantly."
> > > > > >
> > > > > >
> > > > > >
> > > > > > _______________________________________________
> > > > > > Ecrit mailing list
> > > > > > Ecrit at ietf.org
> > > > > > https://www1.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]
> >
> 
> --------------------------------------------------------------------------
> ----------------------
> 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://www1.ietf.org/mailman/listinfo/ecrit