Minutes for ECRIT at IETF-89
minutes-89-ecrit-1

IETF89 ECRIT
This file contains MINUTES followed by the meeting notes at end.
14:30-15:30, Wednesday, March 5, 2014 London
Room: Cathedral/Tower

=========================================================================
Note taker: Christine Runnegar
Blue sheets handed out.
Note Well presented.

5 min * Agenda Bashing, Draft Status Update (Chairs)
Presenters: Marc Linsner, Roger Marshall
Presentation: http://www.ietf.org/proceedings/89/slides/slides-89-ecrit-7.pptx
BASH: Brian Rosen asked for agenda time to talk about
rosen-ecrit-addldata-subnot-01 ACTION: no objection from room, chairs allocated
the 5 minutes of discussion at end for this purpose, if available ACTION: Brian
and Randy to review policy-urn draft and post comments to the list. ACTION:
Noted that IPR issue was raised a while back regarding
draft-ietf-ecrit-psap-callback-13, Alissa Cooper will coordinate with going-out
AD as to next steps ACTION: Chairs to bundle for a milestone submission request
for Alissa Cooper (AD) for 3 or 4 individual drafts that people want to be WG
items ACTION: Brian to send an email pointer to list relating to Christer’s
proposed text for draft-rosen-ecrit-addldata-subnot-01

=============================================
5 min * Additional Data related to an Emergency Call
Presenter: Randall Gellens
http://www.ietf.org/id/draft-ietf-ecrit-additional-data-20.txt

ACTION: Authors to revisit Figure 5
ACTION: Brian (and authors?) to work on making registries text less ambiguous
ACTION: After cleanup – chairs will consider asking for WGLC

=============================================

10 min * Common Alerting Protocol (CAP) based Data-Only Emergency Alerts using
the Session Initiation Protocol (Brian)
http://www.ietf.org/id/draft-ietf-ecrit-data-only-ea-06.txt

Brian presented this and explained that NENA needs this for their NG9-1-1 spec.
ACTION: Chairs asked authors to spin the draft, post to the list – seek wg
review.

=============================================

5 min * A LoST extension to support return of complete and similar location
info (Brian) http://www.ietf.org/id/draft-marshall-ecrit-similar-location-03.txt

Brian presented and briefly explained purpose of this draft as a way to define
a way to return location information in a RFC5222 LoST <findservice> response
to provide missing fields if location input is valid but not complete, or not
valid, and returning a “did you mean this?” suggestion. Version -03 includes
IANA considerations.

Brian pointed out that this is a need for NENA/EENA, although no references
yet, and would extend LoST protocol at the extension point.  No backward
compatibility issues – either put into the request - if server does not
understand, it will drop it, or alternatively the server supplies it and if not
client supported, then end will drop –

Question about whether to adopt or pursue individual draft AD sponsorship? 
Chairs asked audience whether if worthwhile? - a couple of hands showing
interest (only 4 people read, no reviews) –

ACTION: Scott and Barbara will read it

=============================================

10 min * Internet Protocol-based In-Vehicle Emergency Calls (Randy)
http://www.ietf.org/id/draft-gellens-ecrit-car-crash-02.txt

Randall presented, explained how the mechanisms apply in/to vehicles -
emergency calls placed by vehicles, the common term: ACN - automatic and
manually-triggered

Background: split off from an earlier draft - ACN in general, and Pan-European
“eCall” - 3 revisions since the split, and describes the architectures in use
today - how the call are identified and presented to PSAP/ESInet - how crash
data is attached and identified as being a particular form of standardized data
- how PSAP can pull put the data it wants - for NENA, vehicle manufacturers

In trying to ask whether this draft should be adopted as wg draft, room gaged
for how widely this draft has been read.  Brian stated that some people want to
use this, Keith had questions on how multiple formats would be handled at
PSAPs.  Randall - VEDs is in there now - in theory could be done

ACTION: Confirm on list the results of a Hum, which showed positive consensus
in the room in favor of this to become a WG item.

=============================================

10 min * Next-Generation Pan-European eCall (Randy)
http://www.ietf.org/id/draft-gellens-ecrit-ecall-03.txt

Randall presented this and described this as a companion draft to car-crash
(ACN), which has been split off from the original combined (ecall+car-crash)
draft.  This eCall draft describes how to use IETF mechanisms to enable
next-gen pan-European eCall, needed by ETSI/3GPP eCall work.  Discussion from
Keith, Randall on how this will likely be used within 3GPP, ETSI – and how 3GPP
needs contributions (Keith).

Proposal was made to adopt the draft as a WG draft, with chair asking whether
anyone has read (not many). ACTION: Christer and Roland will read it ACTION:
Reaffirm on the list – the in-room Hum, and consensus in the room to adopt as a
WG item

=============================================

X min * Updating Additional Data related to an Emergency Call using Subscribe/
Notify http://www.ietf.org/id/draft-rosen-ecrit-addldata-subnot-01

(note: Brian inadvertently presented this out-of-order, ahead of
lost-planned-changes as listed on agenda)

Brian presented as how to send an update to data.  Christer did not like it,
and proposes INFO package as an additional mechanism at the choice of the
caller - a very short piece of text. Brian doesn’t like having two mechanism
but if need to get going to it - will do it. So far no one responded to his
proposal.

Christer in support of adding it - in existing or new draft
Brian raised an objection to rate control – so will propose an alternative to
that piece of text. Discussion whether devices would support both, Brian stated
that it would be sender choice. Christer explained that 3GPP devices would use
INFO package. Chairs - call for objections to wg adoption – observed none. 
Called for people to commit to read and review and comment on the text and then
go from there

ACTION: Randy volunteered to review

Keith made the point that for things done in the IETF that NENA needs – need to
be brought into 3GPP.

=============================================

10 min * Validation of Locations Around a Planned Change
 http://www.ietf.org/id/draft-rosen-ecrit-lost-planned-changes-01

Brian presented this individual draft, provided overview of LIS data – provides
way to effect re-validation without long revalidation periods that leave
out-of-date mappings, and to eliminate loading problems caused from periodic
validation approaches.

Without this, there is no way to push an invalidation.
Draft proposes that you include a URI - server provides the push mechanism and
an as of date Added a time to live (TTL) and provided guidance on periodic
revalidation.

Author proposal is to get it adopted and get it reviewed.

Chair - how many people understand the draft and think it is valuable? (Scott,
Randall (seems so, not following closely).  It was mentioned that this
addresses some of the issues arising from LoST deployment experience

Chairs asked for review - with data expiration and other concepts in mind
(observation made that a lot of regulars are not here at this meeting).

ACTION: (Chairs?) Take this one to the list – tough to make a call here because
a lack of interest at this point.

=============================================
=============================================

Raw NOTES as Follows
ECRIT Agenda - 16:30-17:30 GMT, Afternoon Session III, Wednesday, March 5, 2014
London

* Note Well
* Blue Sheets
* Tea (Monkey-picked oolong tea) for Gonzalo

5 min * Agenda Bashing, Draft Status Update (Chairs)

-- Additional item added to the agenda: Individual draft -
draft-rosen-ecrit-addldata-subnot-01

-- Document status - 3 active drafts

Chairs:
- would like more reviews of draft-ietf-ecrit-additional-data-20 because there
have been some revisions - draft-ietf-ecrit-data-only-ea-07 has been revved, we
but don't think there have been any comments on the list on this - 3 issues
identified but no comments - is that draft no longer interesting? - respond to
Andrei's comments and get the document out of stall - Brian and Randy will do
that

-- IESG processing of draft-ietf-ecrit-trustworthy-location-08 and
draft-ietf-ecrit-unauthenticated-access-08 are in play

-- RFC editor queue
- draft-ietf-ecrit-psap-callback-13
- draft-ietf-ecrit-country-emg-urn-03

Note: An IPR issue was raised a while back regarding
draft-ietf-ecrit-psap-callback-13 - need to report back on what is AD needs to
made aware of the author's concerns Alissa Cooper - will coordinate with
going-out AD

-- RFC publication
- none

-- Milestones
(see slides)

Chairs: not in bad shape at this point - 3 or 4 individual submissions that
people want to be WG items - could put in a bundle for a milestone submission
request for Alissa Cooper (AD)

* Brian to send a pointer to email from Christer on the list regarding his
proposed text for draft-rosen-ecrit-addldata-subnot-01 (item discussed later in
the meeting)

=============================================
5 min * Additional Data related to an Emergency Call (Randy)
http://www.ietf.org/id/draft-ietf-ecrit-additional-data-20.txt

Has been going on for a long time, a lot of progress, updates in the last
couple of months Framework for transferring data related to an emergency call
General mechanism but with several specific blocks of data Mechanism by which
the data is identified Also registries for the additional blocks in the future
No comments since 15 Appreciate reviews of v20 recent changes - editorial, new
section on how easy it is to come up with an idea for a new block but how hard
it is to deploy clarifications roger's comments name spaces were all over the
place - has now been cleaned up - everything should now be consistent (see
slides) New mechanism that we discussed at the previous meeting on the list - a
way for the data provider to mark all the blocks that the provider is providing
- for consumers of data to find the data provided as one set - now called data
provider reference - now in all the blocks - global unique value - RFC 822
syntactically, like CD changes to schemas caused by name changes long example
re-worked New registry for the service environment DeviceInfo now permits
multiple IDs

Open Issues => Device Classification Registry in Figure 5 needs a bit of work -
all registries need a review for ambiguity (some issues listed in the slide)

Brian offered to help with the registry review - list is unnecessarily complex
- plan to do this this week (time permitting)

View of authors - Once tables are cleaned up, the document should be ready for
Last Call

=============================================
10 min * Common Alerting Protocol (CAP) based Data-Only Emergency Alerts using
the Session Initiation Protocol (Brian)
http://www.ietf.org/id/draft-ietf-ecrit-data-only-ea-06.txt

Use this with additional data
SIP with CAP message embedded and some blocks of additional data
This is a message rather than an invite - text about this
adds text about call backs and external servers

Brian reporting that Christer wants to add the INFO package to this (but Brian
saying that this isn't really the issue he raised) - If the one issue is
resolved (whatever that issue actually is), can we be done with this?

NENA needs this

Chairs - spin it and put it to the list and see if we get reviews

=============================================
5 min * A LoST extension to support return of complete and similar location
info (Brian) http://www.ietf.org/id/draft-marshall-ecrit-similar-location-03.txt

Individual draft - similar location - Brian and Roger
Defines a way to return location information in a <findservice> response
Two uses - provide missing fields if location in request is valid but not
complete - not valid, but did you mean this? Status - v3 added IANA
considerations text; NENA/EENA does need this Time to decide: Adopt or we will
pursue individual submission? Mark L - versioning in LoST? Brian - no
versioning - defined in the extension point - request and you get it back - if
server does not understand, it will drop it - other end will drop - no backward
compatibility issues Randall - ways in which NENA/EENA need the work? Brian -
when supply address for LIS - validating - would like to tell you what is wrong
- also useful because in NENA defined valid as only one place that you could be
on the map (NY city street example) - it does not automatically do anything -
just gives additional information Roger - you covered my use cases enough - add
that this is done by LIS - is logged which allows the analyst to hopefully find
the right answer quickly Keith - what happens when a call Brian - used in
validation before the call Keith - user makes the call …. Brian - you do this
way ahead of the call - when put the location in the LIS - provisioning Randall
- are there references to it it yet in NENA? Brian - not yet - will do
something in NENA if not here

Brian is willing to get an AD sponsor
Chair - is this worthwhile to work on? - a couple of hands showing interest
(only 4 people read, no reviews) - Randall will read but will not commit to
read it Scott and Barbara will read it

=============================================
10 min * Internet Protocol-based In-Vehicle Emergency Calls (Randy)
http://www.ietf.org/id/draft-gellens-ecrit-car-crash-02.txt

describes how the mechanisms working on in this group apply in/to vehicles -
emergency calls placed by vechiles ACN - automatic and manually-triggered
Status - split off from an earlier draft - ACN in general and Pan-European
eCall - 3 revisions since the split Describes the architectures in use today -
how the call are identified and presented to PSAP/ESInet - how crash data is
attached and identified as being a particular form of standardized data - how
PSAP can pull put the data it wants - for NENA, vehicle manufacturers Proposal
- adopt draft as WG draft? Brian - some people want to use it

Chair - who has read, who is interested?
Keith has read - query re multiple formats of data - how would that handle -
when don't know which formats PSAPs would support Randall - VEDs is in there
now - in theory could be done Keith - how do you know that the PSAP supports
the data - also an issue in additional data - need to be careful defining new
data Brian - no negotiation of this - better to tamp done variations in data
rather than negotiate Randall - not proposing jungle - anything new has to go
through a process - needs acceptance for deployment

Chair - split off, have milestone for a WG item

Hum - consensus is in the room for this to a WG item - take to the list

(Randall - no one objected on the email list and some support on the email list)

=============================================
10 min * Next-Generation Pan-European eCall (Randy)
http://www.ietf.org/id/draft-gellens-ecrit-ecall-03.txt

Companion draft - eCall draft
describes how to use IETF mechanisms to enable next-gen pan-European eCall
split off from original eCall draft
4 revisions since split
needed by ETSI/3GPP eCall work
Proposal to adopt the draft as a WG draft

Chair - asking whether anyone has read

Keith - no work item in 3GPP on this - has been presented but no more
Randall - proposals - clear the way it will go
Keith - can't say one way or the other
Chair - liaison?
Randall - ETSI is preparing a report on migration to SIP messaging - will
reference this draft - then CRs will go into 3GPP to change the requirements
Keith - only CS domain is defined at the moment Randall - they won't do
anything before ETSI finishes Chair - checking

Chair - Christer and Roland will read it
Randall - email from eCall community who support the work

Chair - sense of room but take to the list

Hum

Consensus in the room to adopt as a WG item - take to the list

=============================================
10 min

* Updating Additional Data related to an Emergency Call using Subscribe/ Notify
draft-rosen-ecrit-addldata-subnot-01

Brian
How to send an update to data
Christer does not like it - proposes INFO package as an additional mechanism at
the choice of the caller - a very short piece of text - I don't like having two
mechanism but if need to get going to it - will do it but no one responded to
his proposal Christer - I am in support of adding it - in existing or new draft
Brian - if do - will add Randall - apologies did not respond to the email -
clarify Subscribe notify or Info package Brian - yes and Randall - then support
that Christer - same format - so short text to do that Keith - what will be the
requirement on the sender? Brian - sender choice - so does not have to support
both Brian - subscribe-notify creates an additional block - info package would
have tags Chair - Christer has devices that would not support subscribe-notify
so that is why he wants Info Package Brian - I object re rate control - will
propose an alternative to that piece of text Randall - devices always support
both? Brian - one Randall - so support Info Package and then Subscribe-Notify
if wants to Brian - no draft would not say which one

Chairs - call for objections - want people to commit to read and review and
comment on the text and then go from there

Randy volunteered to review

Keith - you keep adding things into IETF docs that NENA needs - you need to
bring into 3GPP

=============================================
* Validation of Locations Around a Planned Change
 http://www.ietf.org/id/draft-rosen-ecrit-lost-planned-changes-01

Brian:
Planned changes - individual draft
LIS data - revalidation of load on LIS (studies show if 2 week period)
no way to push an invalidation
propose you include a URI - server provides the push mechanism and an as of date
Added a time to live (TTL) and provided guidance on periodic revalidation
Would like to get it adopted and get it reviewed

Chair - how many people understand the draft and think it is valuable? (Scott,
Randall (seems so, not following closely) Chair - some of the issues arising
from LoST - trying to deal with them Brian - running against deployment
experience Chair - anyone that can talk about LoST Chair - anyone agree to
review with data expiration and other concepts in mind?

(observation that a lot of regulars are not here)

Take this one to the list - tough because a lack of interest at this point

=============================================
5 min * Discussion

Meeting declared closed