[Ecrit] ECRIT Interim Meeting Notes - ECRIT Conf Call June 3, 2009

["Roger Marshall" <[e-mail]>]

Please find the raw minutes from our last ECRIT Interim meeting, June
03, 2009, inline.  

 

Do send any corrections my way, in case of errors, etc.

 

I've also attached as a MS Word file, in case of formatting difficulties
- which may or may not make it through the list server.

 

-roger marshall.

ECRIT Secretary

[e-mail]

 

***

 

ECRIT Interim Meeting

Date: Jun 03, 2009

Minutes by: R. Marshall

Chairs: Marc Linsner & Hannes Tschofenig

Wiki page at:

http://trac.tools.ietf.org/wg/ecrit/trac/wiki

Local start time: 10:06 AM Pacific

Agenda:

 

Attendees:

James Polk

Keith Drage

Hannes Tschofenig

Greg Burdett

Gabor Bajko

John Elwell

Karl Heinz

Randall Gellens

Richard Barnes

Robert Sparks

Roger Marshall

Spencer Dawkins

Marc Linsner

Brian Rosen

Cullen Jennings

Milan Patel

Dan Romascanu

 

Webex Session:

Notes of Meeting Discussion:

SLIDE 1-4...

SLIDE 5 - review the status of drafts...

Sos-parameter

Lost-sync WGLC is complete, waiting for a couple of implementers
feedback since it is an exp

Location Hiding

Specifying Holes in LoST service boundaries (correction: Cullen to talk
to Martin Thomson)

(more details are in the link listed in the slide 5)

James: Why isn't there a milestone for RPH here?

Hannes: Discussion with AD's - in short, we need to have a wg
rechartering.

James: yes, for -00, but I'm on -05

Cullen: not unique circumstance, some drafts are not going to go forward
until rechartering happens.

James: Other drafts (after) have been brought in.

Cullen: I'm a little lost myself on RPH - I didn't realize that we
needed to recharter for RPH.

James: I don't think we need to update the charter.

Cullen: IESG will have to approve the recharter.

Keith: Which situation are we now in - I believe the wg asked for a
milestone addition at Dublin

Hannes: RPH is listed as from October, other drafts from June - it was
up to Jon and Cullen as to whether these fit within the existing
charter, they were considered within the charter.

...Skip to info in mail message sent out with milestone update (see
SLIDE 9)

James: Other drafts seem to be sneeking in.

Cullen: What do you mean.  We have the charter, then there is the goals
& milestones, then there is the Internet drafts.

Keith: One of the AD's (presumably) will give us the determination of
whether this draft is within scope, or not.

Cullen: Some hesitancy here (on the phone) in light of new AD's coming
in... If Jon said it was within scope, then I'll go with it, but I want
to go back and look at what was decided.

Hannes: Recounting some history, when asked, Jon may have agreed to
allow additional drafts to be submitted, possibly because the phonebcp &
framework draft completion was right around the corner.

Hannes: Secondly, there was a milestones listing mistake, which is why I
asked to have the milestones updated.

Brian: I think that we're only waiting on one critical issue - the
applicability statement - the other issues, I don't think are critical
enough to hold up the document.

 

Next Discussion Item - PhoneBCP and the text added based on SF ECRIT
discussion:

Hannes: SLIDE 6, Marc asked for consensus, but has noted that there is
no clear consensus.

James: Just one or two people who don't want to take it out.

Brian: More than just one or two.

Brian: It's a chair call, as  to whether there is rough consensus.

Hannes: The question in the consensus call that Marc issued was not
whether people agreed with the applicability statement, but rather is
the present wording acceptable.

Randy: I'm saying, ask a different question - we have a draft out there,
can that version go forward?

Keith: The version with the statement is fine with me, could be
clarified, but has a caveat.

Hannes:  Maybe we should resubmit the document without the statement, 

Brian: As you have to do is revert.

Randy: We should ask whether the current version of the draft can go
forward.

Hannes: what is the previous version

Randy: If we go back, we know from SF that there are problems with the
previous version

Hannes: You believe there are problems...

[skip]

Marc: Current version is -09, we could ask the simple question, should
we ask do we go forward with -09 or -08?

Randy: But, -08 is the same as in SF, and we will get back into the
controversy again as in SF.

Hannes: We can't avoid the controversy, 

Randy: Let's not call it an applicability statement, it's just a note of
text.

Marc:  We've got ____ people who didn't like the changes from -08 to
-09.

Randy: My point was that the question as worded, ...

Marc: My proposal of 3 minutes ago... 

Brian: I think I mis-spoke, since there are other changes as well.
You'd have to have a more detailed question to differentiate the two.

Hannes:  The compromise text was premature, done by a small group.

Brian: It was done on the list - not done by a small group of people.

Cullen: Consensus is something taken at a point in time, and over time,
may change - a good thing - since that's how agreements are reached...
it sounds like the chairs are saying, it sounds like we didn't have
consensus at that time.

Randy: We had a lot of debate on the mailing list, yes during the ietf
meeting, but also in the week following.

Randy: I think there was consensus that people weren't content with -08

Hannes:

Marc: (reading the consensus question from email)

Marc: that vote, if by plurality was 10 for, ________ against, etc.

Hannes: If there is something in the document that prevent ES from
working in certain environments, then we should discuss it, though it
comes a little late...

Keith: It's not late, these 3GPP documents have been available for a few
years.

Hannes:  3GPP doesn't put these kinds of statements (e.g., about IETF
shortcomings) in their documents

Randy: I think we've got some emotional baggage tied in with this.

Richard: It doesn't say, "X is a situation, in which things won't work"

Hannes: (reading the applicability statement) 

Randy: All it does it to alert the reader

James: This is applies to IP networks

Keith: Who says that 3GPP is not an IP network

Randy: It's not an applicability statement, doesn't limit a solution in
any way.  Most documents in the IETF are self-limiting.  This document
sets itself up as being "the single way" that all emergency calls
happen.

Hannes: The primary focus of this document is around access providers
providing location, and doesn't take into consideration other models,
such as the communication service providers to provide, etc.

Richard: This document allows for other stuff, but just doesn't map it
out...

Hannes: There's a big difference, it doesn't talk about emergency
registration, etc.

Keith: You wouldn't get a 3GPP LoST server, for example...

Keith: A Service Provider implementing the 3GPP standard, wouldn't
implement a LoST server, because it doesn't mention one.

Marc: (voice breaking up)

Richard: What do change in the document to eliminate the notion that
other models can exist?

Keith: To a certain extent, some have suggested that tried that, 

Richard: If I recall, Stephen (Edge's) comments were fairly general, not
specifically pointed changed suggested.  Do you think this kind of thing
can be done?

Keith: I'd have to go back through it.

Randy: I'd have to do another detailed read of the document.

Spencer: I think the thread indicated that... 3GPP 

Keith: Sometimes CT1 vs. SA2 need pointed questions asked.

Hannes: We've had many conversations with 3GPP, it depends on which
questions are asked... which group.

Brian: 3GPP...

Hannes: I think it's even worse than that, in that some of the
communication models are very different.  E.g., the split of services
vs. being provided by the same provider.

Hannes: What is different to the enterprise environment is the
interaction between roaming and local...

Brian: We should be asking, Is it all right that the service provider
queries LoST, if it's not all right...

Keith: not the question - the question I am raising, is that if
different addressing info is used in a 3GPP network, since 3GPP looks
for specific call marking, and the call may not get to the PSAP at all.

Brian: The main difference is due to the location being done by the UA
or not.

Roger: It's a difference between "core" vs. "edge" routing based on
location.

Marc: If we exclude all other standards development organizations out of
this, then it's not overarching.

Keith: I'd have to go back and look at the document.

Marc: Can you look at it within a week?

Keith: Other ietf documents are explicit as to what they apply to...

Randy: This statement is helpful, is not harmful to have it here.

Hannes: But if it's not a big deal, why do you care so much about this
text?

Keith: All docs have a scope, what does the document do, and what is the
document applicable to.

Hannes: Most of the documents are written in such a way as to be generic
building blocks... maybe I'm wrong about this assumption, but if what
you point out the UA LoST lookup problem is not adequately covered,
maybe we should read through again, and makes sure the document says
what it needs to say.  My opinion is that this is what the document
says...

Brian: The underlying protocols support either model where a UA gets
location & queries LoST or a Proxy gets location & queries LoST, but the
phonebcp doesn't really talk about the latter, other than in a fail-case
scenario.

Roger: Phonebcp is really just a profile for edge-based routing based on
location, there is no comparable profile document that describes a
proxy-inserted location & routing model architecture.

Brian: Yes, but the underlying protocols support it.

Roger: yes.

Marc: Doesn't the title PhoneBCP suggest the edge context?

Brian: As to the applicability statement, I don't think this wording
really matters.

Keith: I've already referred to wording in the abstract that gives the
impression of a universal solution.

[skip]

Hannes: 

Randy: Would like the question asked - are people happy with the
existing document?

Marc: If we could have a -10 w/o the statement, then ask do you (wg)
want -09 or -10, would that work?

Randy: No, I don't think so.

Randy: Ask, given that other documents are being held up, is the present
document acceptable?

Cullen: you can't leave it binary then, it either needs...

James: Ask the question, do you want something, but not what's in -09?

John: I think that James' suggestion could break the (apparent)
deadlock.

Richard:  suggest a rev -10 w/o text - two independent consensus calls.

Randy: There is a difference between a preference and a strong
objection.

Brian: ok, suggest asking the question, who is strongly opposed to -09
and who is strongly opposed to -10?

James: does that take into consideration whether people want something,
but something different?

Brian: no,

James: right, then it becomes a two-step process.

James: I strongly oppose the suggestions.

Brian: you need to start with something non-prejudiced.

Marc: I will discuss with the AD's.

Summary: NO CLEAR CONSENSUS REACHED

/end of mtg. at 11:48 AM Pacific

 


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.