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

ECRIT SUMMARY Minutes, 11/13 scheduled for 13:00-15:00

Roger Marshall & Marc Linsner chairs

ECRIT note-taker Paul Kyzivat

Chairs provided work group activity overview.

1. draft-ietf-ecrit-additional-data-24 - Randy Gellens
Comments received of late will be incorporated (or discussed on the list), and
spun out as -25. After this, it will be ready for IESG submission.

2. draft-ietf-ecrit-data-only-09 - Brian Rosen
The WGLC is done as of today (11/13) for this.  Comments received so far from
Randy and Christer. Brian will incorporate these or otherwise will bring to the
list for the wg to discuss/resolve.

3. draft-ietf-ecrit-car-crash-01 - Randy Gellens
This draft (as Brian later pointed out) represents a use case of the
additional-data mechanism

4. draft-ietf-ecrit-ecall-01 - Randy Gellen
There is a request/comment from Keith Drage requesting that there be action to
pull out what defines the service URN, as well as how to deliver to a service
provider - those bits (details/mechanism/procedure) need to be common. there
are common definitions in a couple of the documents. Keith had a comment on the
list about it that has not been responded to, yet Randy thinks that Keith's
commments have been address already, and will check and see if all of Keith's
comments are addressed, and included the fact that there are now cross
references between the two documents.

5. draft-ietf-ecrit-similar-location-00 - Brian Rosen
Discussion w/regard to need to explain explicit ranking for alternative
addresses. It was suggested that a ranking number is needed to represent
higher/lower or same ranking. Scott Bradner agreed to review this draft.

6. Other misc. topics discussed due to additional available time - see raw
notes at end.

End of summary minutes.

***********************
Unedited NOTES (2 sets follow)

***********************

Paul's notes:

Here is what I got for notes. I got lost in a few places, so these need some
careful editing.

        Thanks,
        Paul

Rough notes for ECRIT, Thursday Nov 13, 2014 Note taker: Paul Kyzivat

Jabber Scribe: none (Ted talking to himself)

* Agenda Bashing, Draft Status Update - Chairs

There was a question about comments on drafts in the RFC Editor Queue.
Allison thought this should be a mistake. Will investigate later.

Keith: there are common definitions in a couple of the documents. He had a
comment on the list about it that has not been responded to. The chairs will
follow up on that.

Looking for liaison from [what org? ETSI?] that will create a new milestone. It
may just not have gotten to the WG. Chairs will look for it.

* draft-ietf-ecrit-additional-data-24 - Randy

[There was a long conversation between Keith, Randall and others about an email
he had sent for which no response has been given. It later turned out that this
pertained not to this document, but to the car-crash document below. I have
moved the notes on it there.]

* draft-ietf-ecrit-data-only-ea-09 - Brian

Will update for IETF90 comments. Nothing new.

* draft-ietf-ecrit-car-crash-01 - Randy

Keith: he had sent an email about URNs

Randall: was referring to some other ones.

Keith: there are common definitions in a couple of the documents. He had a
comment on the list about it that has not been responded to.

Randall: there are now cross references between the two documents. Have tried
to address all of Keith’s comments.

Keith: pull the part about the service URN in its own draft, along with the
text about what the deliverer needs to do into a single draft.

Randall: the service URNs are different in the two drafts because they are
different services. Don’t understand how to what isn’t clear.

Robert Sparks: need to settle the difference here – is there something common
between the two drafts that may be in conflict.

Chairs: could deal with this during LC.

Keith: objectgs to LC when there is unaddressed issue – says there were no
replies to the email.

Randall will read the email and reply to it on the list, one way or the other.

* draft-ietf-ecrit-ecall-01 - Randy

Ted: application/emergency-call-data: suggest renaming vehicle-call-data.

Randall: gave an explanation – that this is the generic mechanism, and the
car-crash data is a specific instance of it.

This draft is specific to pan-European eCall data.

* draft-ietf-ecrit-similar-location-00 - Brian

Mark: asked with is expected of sender after invalid response. Send the
returned address in another request?

Brian: yes. But the server can’t determine if the suggestion is *right*.

Ted: in the invalid case, can there be alternatives? Are they ranked?

Brian: yes there can be multiple ones. After discussion, don’t think there is
ranking.

Ted: want to be clear, so that user doesn’t infer order is significant if it is
not.

Ted: gave some examples where ranking makes sense, and some when it does not.

Brian: will take that into consideration.

Brian and Chairs asked for reviewers.

Scott Bradner volunteered as a reviewer.

* free time at end of meeting

Chairs: had some errata on RFC5222. Would be good to have someone look at that.

Ted: volunteer to pursue those – working with Andy.

Alissa looked and there has been no liaison from ETSI. Need to investigate.

[NOTE: This is about two related things, but I wasn’t able to sort out which
was which. So it doesn’t make sense.] Brian: have a draft that hasn’t been
pushed. Has to do when unincorporated territory is incorporated (annexed) into
an existing entity. Example of reality that things change so that old valid
addresses become invalid. Current solution is periodic revalidation of
everything. That impats the load on the LoST server. The mechanism to register
a URL for notification when an address becomes invalid would be valid in this
case too.

Marc: new data stored for every address?

Brian: yes. This is a small amount of data.

Mark: how would you secure that? (Could allow malicious behavior.)

Brian: sees that as a policy issue. But would need to address as a security
consideration?

Brian: will spin the draft, update based on this discussion. Will cover both
planned update and revalidation – two uses for the same mechanism.

Chairs: working on location accuracy when indoors. Watch for a draft on the
subject.

***********************
Roger's notes:
Backup note-taker Roger Marshall - raw

Chairs (Marc & Roger) provided overview of ECRIT activity.

Keith Drage: (comment) 2 service URNs - similar - go back and resolve/answer
(these were later id'd as ecall & car crash)

Keith Drage - ETSI use case via liaison was approved 2 weeks ago.

***

additional-data - Randy Gellens (draft version -24)

Guy, Keith, Chris, Archie all sent comments

*** [following comments apply to car-crash and ecall, NOT Additional Data,
though they were made in this order]

Keith: only had one comment - to do with service URN

Randy: (recounted some of Keith's comments)

Keith: Wants the bits that relate to the creation of the service URN to be put
into the same draft.

Randy: reluctant to lump ecall into ACN in general, bcz ecall is a specific
service.

Keith: I think what needs to be made common is the delivery.

Randy: [miss]

Keith: pull out what defines the service URN, as well as how to deliver to a
service provider - those bits need to be common.

Randy: The service URNs are different between the two drafts.

Keith: [miss]

Randy: Not sure why they need to be pulled out, I guess we can take it to the
list.<<

Robert Sparks - Restating impression that

Marc: Can you (Keith) review these two drafts and make summary comments?

Randy: These could be done via Last Call

Keith: I can't believe you'd send this draft to LC w/o resolving this comment!

Allisa: Keith please forward that part of your email to make sure it gets
addressed.

***

data-only - Brian Rosen

Brian: WGLC over today

Brian: Did spin

***

car-crash - Randy Gellens

Randy: (provided overview of draft)

***

ecall - Randy Gellens

Ted Hardie: Seems more generally applicable to many kinds of use cases, suggest
changing name

Randy: (clarified the general use nature)

Brian: reinforcing this notion, you should have said in the prior presentation,
that car-crash is a specific use case of additional-data.

Randy: right.

Randy: this one is pan-European specific

Randy: Keith's comments - I believe - have all been addressed.  I will check.

***

Similar location - Brian Rosen

Brian Rosen:

Marc Linsner: On number 2, are you requiring that the requester resubmit?

Brian: Yes.

Brian: You won't get the "route" with the alternative address that is sent.

Ted: In the second case, when returning multiple valid locations, are you
returning ranking?

Roger: I don't think there is any explicit ranking, I think it is up to the
implementation.

Ted: I'm concerned that no implicit ranking is done when there should not be.

Brian: Need reviewers - Scott Bradner agreed to review this.

***

Marc: Done with agenda items.

Since we have more time, there is an errata email from Dan Banks (DDTI).

Ted: (Looking at errata)  Looks like one may be correct, and one that is not
correct.

Marc: Ted will work with Andy Newton to resolve the comments.

***

Marc:  Any other comments?

Brian: I do have another draft, draft-rosen-planned-changes(?), that I haven't
worked on in light of these other wg drafts...

Brian: boundary expiration topic - looking for advise as to whether to redo the
draft, or split into two drafts, etc.

Brian: in reality, things don't remain static, reasons why things don't remain
valid.  Up to point, only periodic validation can be used.

Brian: the mechanism in the planned-changes draft will have a URI for each
validated civic address.

Marc: So you don't care about the storage requirements as much as the
transaction requirments.

Brian: Yes.

Brian: I will currently leave this draft as one document.

Marc: Committed to have this by next meeting.

***

Marc: Since we've got time... Roger & I have been working on higher accuracy
location, which we'll put together for next IETF92.