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

##########################################################################################

Emergency Context Resolution with Internet Technologies - WG - 18:30-19:30
Thursday Afternoon session III

> 18:30 (18:34) * Agenda Bashing, Draft Status Update (Chairs)
- Milestone update discussed further on the list

> 18:35 (18:39) * Data-Only Emergency Calls (Brian)
> https://datatracker.ietf.org/doc/draft-ietf-ecrit-data-only-ea/

  fixes
  did a WGLC prior, but not a lot of review, did make changes, chairs decided
  to run another WGLC currently in WGLC now. Will get NENA folks reviews Pretty
  simple mechanism, have had to make sure of the details. Marc - how many
  people are looking at this draft. Brian - Plea for review, wouldn't take long.

> 18:45 (18:44) * A LoST extension to return complete and similar location info
(Brian) > https://datatracker.ietf.org/doc/draft-ietf-ecrit-similar-location/ -
Provide "Did you mean" messages for invalid addresses - Question: Who would
review this draft?

  mechanism is simple
  Need more reviews
  Marc - need people to review these things, look for nits.
  Anyone volunteering?
  Brian - I will get a bunch of people to review.

> 18:55 (18:49) * Validation of Locations Around a Planned Change (Brian)
> https://datatracker.ietf.org/doc/draft-ietf-ecrit-lost-planned-changes-00/ ->
ISSUED > Slide:
https://www.ietf.org/proceedings/96/slides/slides-96-ecrit-2.pdf - Area
annexation -> Response to changes
  Andrew - we're in a city (Berlin) that about 20 years ago had a lot of
  planned changes.
- Changes are pushed to the LoST server -> functionality given by a special URL
- Option to ask a server, if a certain address will be valid in x days
- Periodical validation is not a good way, because it uses many resources
-> Provided draft attemts to introduce a new mechanism for pushing updates
- Randal: Is this used by random clients? Concerned about pushing to random
clients. -> No, by infrastructures only (e.g. LIS Operator) -> security
conderations already in document
  Marc - Need reviews.  Take comments to the list.

> 19:05 (19:00) * Internet Protocol-based In-Vehicle Emergency Calls (Randy)
> http://www.ietf.org/id/draft-ietf-ecrit-car-crash-08.txt
- Randall - new version -10 published today,
  to align with work in 3GPP - asn now binary encoding, no longer xml
  now vehicle sends a MSD inside a new INFO message
  lot of comments from lot of people, thank all them, want to thank Christer
  two open issues remain
  1. capabilities element - suggestion to move it back to ecall draft, but make
  it optional 2. INFO package registration, now draft says can use INFO to send
  a body part. question on whether legal.  2 approaches.
- Christer - want to thank Randy, many comments from 3GPP came out, there are
still a few issues.
  main issue is this INFO - definition of which MIME types.
  this draft says use any MIME type in the IANA registry.
- Christer: Info package can be used in a wrong way, if everyone can put data
in them -> Dont flood them with an endless number of MIME-Types - Suggestion:
Define a new INFO-Package for every new MIME-Type.
  with a specification & expert review - to restrict which MIME types
  Also, another section to describe how the MIME types are used, including how
  INFO package is used. summary - we should define new INFO packages, not use
  IANA registry, Asia could do this, etc. I feel strongly about this. This is
  the main point where we're not on the same page.
- Brian: If the MIME-Types need a new INFO-Package, it's the SIP-Guys to decide
it. - Discussion in general: How to use the SIP INFO-Package in the right way.
- Christer - needs to be "a public" document available. - Alissa -
specification doesn't have to be an RFC, just has to be written down. - Brian -
decide what level of information is required - can say must be specification
required or expert review. - Not in favor of playing games with SIP INFO - Marc
- chairs are trying to get some input around this (Robert?) - Andrew -
sympathetic to Christer's arguments, as Brian said, can make a template, fill
in the blanks. - Randall - can I play devil's advocate? If I was a game
designer trying to do that, I could do that now... - Hannes - I think that the
example that Christer used is a little constructed. - Christer - they would
define their own registry, then all these get associated with a single INFo
package. - If we move forward with the registry approach, we need a lot of
text, therefore defining INFO packages would be easy. - Georg(?) (3GPP),
support Christer as well. - Andrew - pretty much you can fill in the blanks -
put it in an RFC, here's what you need. - Randall - risk is some other region,
like China, who needs their own. (back and forth) - Marc - let's get through. I
want my five minutes.

> 19:15 (19:22) * Next-Generation Pan-European eCall and CarCrash (Randy)
> http://www.ietf.org/id/draft-ietf-ecrit-ecall-08.txt
> https://datatracker.ietf.org/doc/draft-ietf-ecrit-car-crash/
  once we decide capabilities, then
- Brian - just looked up MIME type - more onerous than specification
- Randall - it depends on which tree you use.
- Dale - for public safety, I hope that it would not be in the vendor tree.
- Brian - it's too late, but we should have done that (?) for additional data.
- Randall - [missed comment]

> 19:20 (19:25) * Discussion
Marc - document status
- No individual drafts currently
- 3 in WGLC
- Chair: Request to review the WGLC documents
- getting to a place of winding down.
- last ietf meeting request there were 25 more requests than time slots avail.
- we need to get through the ecall, car-crash etc.
- Brian - it depends on reviews, and I'm gonna work hard to get reviews.
- Brian: There is more work to do and it would be better to leave the WG open
for a little longer - Alissa: Keep the WG open, it costs nothing, but finish
the documents anyway - Alissa - in general, don't have to meet. - Andrew - 2
more 3GPP meetings - Is it possible that new requirements will be popping up in
November? - Christer: Even though there are some open issues, this is a stable
WG and there are no "main" issues left - Marc - remember, we were going to hold
before AD hits submit to publish. - Marc - don't want to be discussing INFO
package in Soul. - Andrew - comment is a single service ecall - Alissa - 3GPP
issues resolved with this - Andrew - we aren't quite there, but could use a
liaison if needed at that time from 3GPP.

> Closing: 19:33