Subject: [Ecrit] ECRIT (prior) interim meeting notes - for Webex Virtual Mtg. on Feb 26, 2009

From: "Roger Marshall" <[email-masked]>
Date: Tue, 16 Jun 2009 16:20:58 -0700

It seems that I have neglected to distribute to the list, the raw
meeting minutes for the prior ECRIT Interim meeting, (Feb 26, 2009
meeting date).  Please find the raw minutes inline.  I've also attached
as a MS Word file, in case of formatting issues.
 <<ECRIT_Interim_Meeting_20090226.doc>> 
Many apologies.

-roger marshall.
ECRIT Secretary
[email-masked]

***

ECRIT virtual meeting notes - via Webex
Date/Time: 2/26/2009:11:00-1:00PM (Pacific, or GMT -8)

Attendees:
James Polk
Milan
Roger
Richard
Tony pike
Cullen
Gabor
Guy
Brian
Andrea
Hannes
Benard
Jon
(missed some)

Agenda: (Hannes) at link: http://trac.tools.ietf.org/wg/ecrit/trac/wiki

Agenda bashing (Marc) none heard.

Phonebcp & Framework drafts

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 in 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

--

Notewell does apply - needs to be added to slide deck

--

Discussed Lost-sync

Brian: doesn't think this will see wide use.
Brian: 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.

-- 

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" other civic
address, for example, for routing, and follow up with a more precise
location.

Hannes: hopefully, Richard can apply some of the comments made here,
before expiration date.
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 document what would happen if not there -
error cases
Milan: yeah, good to do.

--

Brian: 
Marc: we can come back to this one.

--

Andrea?

--

LoST Service Boundaries - Karlheinz: 

Comments:
Hannes: Thinks its good, but see it maybe as an experimental

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 (?)

-- 

Premature Disconnet - Brian 

Have asked for this to be considered, and have been told...
Seems like they (those in the IETF?) 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?

--

12:48 Pacific

Forte 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...
Andrea:
Hannes: 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? What is the plan?

? Discussion around the deadline

--

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.

Marc: should probably have meetings for...
Brian: would agree, but not agree to having a single 2hr meeting for one
document only.

--

/end.

CONFIDENTIALITY NOTICE: The information contained in this message may be privileged and/or confidential. If you are not the intended recipient, or responsible for delivering this message to the intended recipient, any review, forwarding, dissemination, distribution or copying of this communication or any attachment(s) is strictly prohibited. If you have received this message in error, please notify the sender immediately, and delete it and all attachments from your computer and network.