[Ecrit] Meeting Minutes, ECRIT Virtual Interim Meeting

["Hannes Tschofenig" <[e-mail]>]

ECRIT virtual meeting notes - via Webex 
=======================================

Date/Time: 2/26/2009:11:00-1:00PM (Pacific, or GMT -8) 


Participants: 

James Polk
John Elwell
Jon Peterson 
Karl Heinz Wolf
Milan Patel
Roger Marshall
Richard Barnes
Tony Pike
Cullen Jennings
Guy Caron 
Gabor Bajko
Brian Rosen
Andrea Forte 
Marc Linsner
Janet Gunn
Anna Zacchi
Bernard Aboba
Keith Drage 
Hannes Tschofenig

Notes by Roger.


Slides at link: http://trac.tools.ietf.org/wg/ecrit/trac/wiki 

Agenda - Hannes
---------------

Hannes goes through the slides and explains the status of the work. 

Marc: Agenda bashing? None heard. 

Phonebcp & Framework - Brian 
----------------------------

Brian: Framework redline update - plan to release today.  No substantive
change, but asks now if we want to discuss Stephen Edge's comments -
relating to Wireless.

PhoneBCP also due out today.  Good comments from John Elwell, probably will
submit anyway, then if we need to update w/changes, we'll do that.  At least
one i-spot that needs something new, not sure what to do.  Problem: if
device didn't know how to do LoST, mark the call - if you don't see a route
header, then default. fine.  If you did see a route header, how would you
know.(?)  Seems like a bad idea to have every Proxy check the route header
to make sure it's a PSAP URI.

(repeat) phonebcp requirement that a proxy help out a call that didn't get a
LoST answer.  if LoST hasn't been done, then the proxy should do it.  A good
requirement, but how does a proxy ensure that this is done rightly?

Idea is try to have a marker in the SIP message - don't know how to do this.


Trying to avoid having to force the proxy from doing the check. 

John: isn't there something already in the geolocation field as a "use for
routing" ? 

Keith: what about the socks parameter (?) 

Brian: 2 good comments, that we'll cosider. 

Also, another point of discussion, Henry claims that you can't do a SHOULD
to an INFORMATIONAL document (downref exception).

Jon: Advise would be to change the text, to be as if it would not be
normative.  If there are things that are normative here, replicated them (in
Framework?)

Keith: what's the new status? 

Brian: Framework will be INFORMATIONAL now. 

Brian: Is there a document status that is BCP?  If xml2rfc has that, then
I'll change it to that 


-- 

LoST Sync - Hannes
------------------

Brian: doesn't think this will see wide use. 
Keith: Other database sync mechanisms exist 
Brian: NENA is looking at OGC's database layer mechanism to replicate 

Hannes: maybe you could pass the OGC doc link to the list. 

-- 

ECRIT RPH - James Polk 
-----------------------

Diagram - 01 shows insertion of "esnet" as RPH marker 
Janet: short read - 7 pages w/boilerplate 
Marc: any comments for James? 
Brian: I want to make this a wg approved document. 
James: Already is a wg document. 
Hannes: We had some re-scope activity. based on our earlier hope to submit
framework document to the IESG... 
Keith: Is this a wg doc or not? 
Jon: technically, a wg chair is empowered to accept anything they think s/b
accepted, but there should also be an wg charter item to cover it.  So,
between two views.

Keith: 
Jon: If there is a wg sense to work on it - I'm not going to say don't do
it. 
Jon: kinda like the same tone of "resignation"? 
Hannes: need to read through the document, but basically, the diagram looks
better than what was there before. 
James: describes any VSP that is a "trusted" entity with the ESInet. 

-- 

Rough location - Richard Barnes 
-------------------------------

Discussed geo requirements 
Geo - points out that the greater shape provided encompasses all of the more
precise location possibilities. 
Civic location - harder to do, since filter areas may be harder to
delineate. 

Roger: I think it's probably impossible to have a general solution that
works with civic location. 

Brian: civic does work - you can provide a "precise" - but wrong civic
address that routes to the same PSAP. 

Roger: Need to indicate that the returned location isn't correct. 

Richard: Need to investigate how todo this. PIDF-LO method field? 

Hannes: hopefully, Richard can apply some of the comments made here for the
submission deadline. 

Richard: maybe. 

-- 

Sos-parameter - Milan Patel 
---------------------------

Presentation given 
Questions?  No response. 
Hannes: Jon & Keith, SIP expert opinion? 

Keith: Haven't worked through all of part 4 yet 
Milan: Wouldn't recognize the contact address as an emergency use case -
contact 
Jon: 

Hannes:  Would be good to describe in the document what happens if the SIP
UA sends an emergency registration with the SOS parameter and the proxy does
not support it. 

Nobody really knew what happens in that case. 

Milan: yeah, will investigate it. 

-- 

LoST Service Boundaries - Karl Heinz
------------------------------------

Comments: 
Hannes: Thinks its good, but see it maybe as an experimental 
James: Why do you think it should be experimental? 
Hannes: Optimization for LoST where we don't have a lot of deployment
experience with. Would be finished faster. 
Karl Heinz: Not an optimization - a gap in LoST. 
Richard: I think it's a good, useful draft. 
Roger: It's good - another example of this could be campus security (hole)
within a greater metro region. 

Brian: I don't really care - don't see any danger. 
Cullen: Introduces hole, but probably already well down that road. 
Brian: yeah. 
Hannes: we should discuss this more on the list. maybe we get a few more
folks to support it.  

-- 

Premature Disconnet - Brian 
---------------------------

Have asked for this to be considered, and have been told. 
Seems like some folks in the group only want to solve it through UI only. 
Don't know what to do to move this forward. 

Has been a discussion of solution paths 

Keith: Did you get my comments? 
Brian: Will have to go back and look - I know some were addressable, some
don't know how to handle. 

Guy: (missed) 

Brian: Can't do this through UI 
Cullen: Do you think you could get consensus on that point, that you can't
do it through UI? 
Brian: Depends on how you frame the requirement. 

Hannes: maybe I should try to set up a conference call, to include several
of you who have comments or interest. 
Keith: I've made some detailed comments - need to have the requirements in
front of me. 

Hannes: forgetting the requirements for the moment, could we proceed then? 
Keith: The solution that mimicks the PSTN is not acceptable to me. 

Guy: That is not what we're asking for. 
Hannes & Marc to put together a meeting to discuss.  Should include:
Henning, Ted, Keith, Randy, Guy, Brian. 
Guy: Just so I understand, this is not yet a working group item? 
Hannes/Marc: yes, not a wg item. 
Guy: In order to get there, we need to have rough consensus? 
Hannes: yes. 
-- 

Lost Extensions - Andrea 
-------------------------

Define the service URNs 
Hannes: Very much in favor of this - since in many cases, IANA mechanisms
require too much effort to get extensions.  we shouldn't have originally
done this... expert review is all that's needed.  So I would be very much in
favor.

Andrea: okay. 
Hannes: Keith, you had comments on the list on this?  Some proposed wording
you didn't like? 
Keith: the question.? 
Hannes: Are you in favor of changing IANA registration to expert review
instead. 
Keith: May have thoughts regarding the hierachical structure. need to see
actual words, are they in the draft? 
Keith: need to say what the rules are when we've got some kind of hierarchy,
can't just be independent. 
Hannes: yeah. will have to think about that. 
Hannes: Andrea, will you be updating the document? 
Andrea: yes, will update the document, wanted here to see what the working
group was thinking about this. 
Hannes: could you or Henning trigger the discussion on this service urn
update?
Andrea: yes.  


-- 

Unauthenticated Access
----------------------
 
Hannes: Henning couldn't participate, which is probably good since we're
running out of time. 

-- 

Hannes: Was this meeting helpful? 

(2 or 3 yes responses) 
James: probably a good idea to have this kind of meeting 3 or 4 weeks ahead
of a f2f (for Roger) and the rest of us. 

Jon: should have phone conferences in other groups as well.  
Brian: would agree, but not agree to having a single 2hr meeting for one
document only.