ECRIT Meeting
Minutes – IETF78, Maastricht
Date Time: 7/29/2010 13:00-15:00
===============================
Summary of
Minutes (prepared by Roger Marshall):
Chairs'
Introduction.
The chairs, (ref.
agenda presentation for RAI-ECRIT at https://datatracker.ietf.org/meeting/78/materials.html),
after a brief announcement of the next upcoming Emergency Service Workshop
(ESW8) in Berlin, in Sept 2010, reviewed current ECRIT document status, drafts
that have been deferred elsewhere (not ECRIT), and other drafts, including
those that have been AD sponsored in the past.
Robert Sparks, AD, asked if any had objections to AD sponsorship of –rph-namespace. Some
comments, but no objections were heard from the room.
Individuals’
Presentations.
><
Update on PhoneBCP & Framework (Brian Rosen/James
Polk)
http://tools.ietf.org/html/draft-ietf-ecrit-phonebcp-15
http://tools.ietf.org/html/draft-ietf-ecrit-framework-11
-- framework
Brian Rosen gave
an update on –framework changes. There
were comments that the text that describes keying SRTP needs corrected.
One open issue
described was around P-A-I, when included, has a spec(t)
security constraint per RFC3325. The
decision posed to the wg was whether to 1.) leave this to the PSAP to
define a spec(t), or 2.) define spec(t) within phonebcp. Brian
Rosen’s recommendation was choice 1. No
objection from the room. Cullen Jennings
asked why it couldn’t be removed in rare cases (e.g., Sierra Leone), where
there is no spec(t).
-- phonebcp
Brian Rosen
mentioned that there were a lots of changes in the
latest version.
A change from
“can” to “MUST” had been made w/regard to endpoints getting their location via
an LCP. Randall Gellens suggested that
since there were no clear requirements for this, it should say "MAY". The wg agreed to
change it to say “MAY”.
It was also
pointed out that due to requirements numbering changes, other documents (e.g.,
NENA’s i3 documents) would need to change as well. Keith Drage asked
whether the purpose of this presentation update is to seek wg
approval for these changes. Brian Rosen
confirmed that it was the case. Keith
and others made the request that an email with a link to the diff for these
changes be sent to the email list, requesting approval as well. James Polk asked that enough time be provided
for him to have an adequate period for review (>2 weeks).
><
Rough Location (Richard Barnes)
http://tools.ietf.org/html/draft-barnes-ecrit-rough-loc-03
Intention:
Update on changes required to match Location Conveyance.
Richard
Barnes stated that this has been revved, since it had languished.
><
Additional Data (Brian Rosen)
http://tools.ietf.org/html/draft-rosen-ecrit-additional-data-00
Intention:
Evaluate for WG item candidate - determine next steps.
As
a clarification, Geoff Thompson asked whether this (idea) is intended to be
from some arbitrary 3rd party? Brian says, see me after, since there is a
technicality, though said the simple answer is no. Hannes said that there is a need for security
considerations in this draft. Keith Drage whether Call-Info headers are accumulative, can you
have more than one? Brian answered, more
than one, that an INVITE can have lots of them, and each
should have a different purpose.
>< Data
Only (Brian Rosen/Hannes Tschofenig)
http://tools.ietf.org/html/draft-rosen-ecrit-data-only-ea-01
Intention:
Evaluate for WG item candidate - determine next steps.
Brian Rosen
presented this (non wg) draft, which fits the context
of calls sent toward the PSAP (i.e., citizen-to-authority). This draft differentiates between a normal
emergency call by whether or not you have two-way interactive media (this is
one-way). James Polk liked the draft,
thought is
was well done. Alex Mayerhoffer suggested that this might be a good use of geo:
URI instead of a PIDF-LO. Brian said
that he would talk offline, but doesn’t think so. Cullen pondered that it was interesting to
think about where you can’t use this, e.g., fire sprinklers, etc. – a potential
congestion nightmare. Brian repeated
that’s the reason why he mentioned “aggregator” earlier as on possible end
point of this. Richard Barnes stated
that this draft needs some text and discussion around security. Brian welcomes input in this regard. James Polk asks if ultimate recipients are
always PSAPs, or if e.g., a university might be the destination. Brian confirms that the recipient is whatever
LoST returned.
>< 10 min. *
PSAP Callback (Henning Schulzrinne)
http://tools.ietf.org/html/draft-schulzrinne-ecrit-psap-callback-03
Intention:
Evaluate for WG item candidate - determine next steps.
Hannes Tschofenig talked about the
PSAP needing to do callbacks, after an emergency call has ended. He described a questionnaire that sent to NENA, EENA, EMTEL
asking about call-backs (www.ietf.org/mail/archive/web/ecrit/current/msg07084.html). Geoff Thompson asked whether responders know
what a call-back is, because he doesn't.
Hannes answers that this was defined in problem statement (with drawings
and other niceties). Hannes notes that
the call-back document needs to be updated to reflect the questionnaire
feedback. Hannes also notes that it is
difficult to judge the operational complexity of this, especially security
considerations. Hannes asks if this
document should go for Experimental? (Ed. No record of
the response here.)
Hannes asked for
volunteers to implement this, especially PSAP UI. REACH 112 and BEACH project will also be
asked. Suggested solution: define call
marking separate from the authorization model (identity based versus role
based); offer end-to-end and hop-by-hop security protection; add discussion of
identity and trait-based (role) authorization.
After these
changes, further feedback will be requested from EENA, NENA, and ETSI EMTEL.
A
question was raised, is meant by both pieces?
Brian Rosen stated that phonebcp says you
provide both a Contact element (URI) and the AoR. Hannes plans to contact the Reach project and
PEACE, both in Europe. John Elwell asked, if these callbacks can also come from non-PSAPs, will that
be taken into consideration? Hannes said
yes, I think it should be. Randall
asked, as a clarification, who was doing the callback? Hannes – for example, the PSAP hands it to a
responder, and they call back. Hannes says this complicates things, but is
covered in document.
><
Trustworthy Location (Hannes Tschofenig/Bernard Aboba)
http://tools.ietf.org/html/draft-tschofenig-ecrit-trustworthy-location-03
Intention:
Evaluate for WG item candidate - determine next steps.
Bernard
Aboba covered Trustworthy Location, (not yet a WG document), which includes
both location spoofing and identity spoofing.
Brian Rosen asked what out of this document can be done, and commented
that security only needs to be
good enough for deployment work. Discussion
of infrastructure required to have a worldwide VESA root with certificates for
every PSAP trusted by every LIS in the world.
Bernard comments that NENA i2 has text saying to use particular security
mechanisms without an understanding of what is involved and what it buys.
(Several comments were received from floor,
noting that people like the document, that it is needed.) Marc
Linsner asked, what’s the author’s goal for this document, is it to recommend,
or just to talk about the issues? Cullen
Jennings made the statement, “I also, like Brian, got out of this document, ‘we shouldn’t try anything because it’ll fail’”. Bernard responded that that is not what the
document says. Richard Barnes added, “I
didn’t get the same thing out of it – but think it’s a great draft to discuss
what some of the potential solutions/implications are. Hannes Tschofenig said, yes, that’s where we
started from, many security scenarios are trade-offs, and it is difficult to
see the big picture. Martin Thomson
said, “I like this work, somewhat overdue in terms of the analysis. To me, this is one of the most important
drafts considered today.”
><
Civic Boundary (Martin
Thomson) http://tools.ietf.org/html/draft-thomson-ecrit-civic-boundary-00
Intention:
Review applicability to ECRIT.
Martin
Thomson presented on civic address boundaries, (not yet a wg
draft, and same presentation that he had hoped to
present at IETF77, but was unable to fit within the agenda time for).
><
SOS Parameter (Milan Patel)
draft-patel-ecrit-sos-parameter
Intention:
Evaluate recent changes
Milan
Patel asked if document is going in right direction (if so, will take to
DISPATCH). Robert Sparks – who in this
room has read the draft – just published this week? There was a comment that only one person in
room has read latest version (which was posted very recently). Cullen said he just now looked through the
draft, says he doesn't think the draft is going in the right direction - to fix
the identified problems. Examples
include extensibility (suggests removing "="); semantics of tag need
much better definition, too fuzzy now ("do as I say" vs. "do
what I mean"). Robert stated, “to correct Cullen’s statements, this doesn’t talk about this
as an emergency call”, and suggested making a significant prose touch on
it. Cullen offered his help with the
changes. Milan said that he will get in
touch.
><
IEEE 802.23 (Geoff Thompson)
Update
on 802.23 work in the IEEE.
Geoff reminded
the group that he spoke to it last time at the meeting in March. He explained that their plan is to provide a
layer-2 shim, to support the oft agenda-listed topic in ecrit of
unauthenticated access. Geoff invited
participation in their working group, stated that the next meeting, an interim, is planned for
the big Island of Hawaii. Martin Thomson
agreed to provide comments to the IEEE wg list server
as indicated on the slides.
>< Unauthenticated
Access (Gabor Bajko)
(No minutes
recorded here.)
><
Open Discussion on five drafts which are candidates for WG adoption and their
prioritization.
Many individuals
voiced their opinion on which drafts were of higher importance.
Chairs ask if
anyone feels these documents aren't suitable for WG?
Martin Thomson
was concerned about additional-data, said:
-- Looks like a data dump from NENA
-- Needs more grooming; underlying
requirement is sound
Cullen says he
feels that additional-data is a laundry list of what could be provided, not
what is needed. Cullen Jennings said
that this prioritization scheme is not too useful
-- Need to know 'what's second'
Cullen says it's
not useful to have three out of the five marked medium priority.
James Polk said
he thinks data-only should be moved from ‘low’ to 'high'
Hadriel Kaplan said: Prioritize network-side stuff,
such as sos-param, it should be high.
Comment from
floor that unauthenticated-access should be high priority.
RjS: Guidance is that sos-param
is going to DISPATCH, not presently AD-sponsored
-- Other than that, psap-callback
-- trustworth-location should be fairly low; might not need to be an RFC
Andrew Allen:
callback -> high priority, needed in 3GPP
-- May have terminal impact; important use
case
-- Think that data-only is useful, but ok
to stay low-priority, since it’s still in the early stages in 3GPP.
Hannes Tschofenig:
<Complaining about timing>, said some of these documents have been
languishing for two years, waiting for phonebcp and
framework to finish, says, Why do we sequence artificially, not getting any
work done. Hannes said that the group
can just work on all these at same time, and if had not been held up, might
have been finished by now.
Hannu says he'd be happier if "high
priority" meant something, joked that he liked this approach, in the hope
that marking high priority items can actually speed them up (!)
-- He seconds Andrew on psap-callback, regulatory requirement some places (need
marking), and therefore is high-priority.
Marc Linsner asks
Hannu,
“Is this draft what you need, as it is now?”
-- Hannu:
Need to consult with technical people
Martin: Agree on
callback/high, trustworthy-location/low
-- Maybe also sort according to
difficulty, hard, medium, and easy.
-- additional-data and data-only are
pretty easy, others are hard
Brian Rosen:
Agree to the difficulty classification, says NENA needs the two easy ones,
(additional-data and data-only). Sees a
need that all of these should be worked on, don’t see a need to pick some not
all. The milestone schedule is what we
need to be talking about.
Robins George:
What about service classification?
-- Chairs: Dispatch
Jon Peterson: back
when LoST was being developed, there was a process to
prioritize other drafts, not necessarily a need to throttle here, now.
Randall Gellens:
Agree that callback is high priority
-- Unclear that unauthenticated access has
the same urgency… maybe low?
RjS: Adopting these documents is on the table
--
if we take a milestone date approach, then I want to
make is serially, and take is seriously.
-- Wants the group to stick to dates,
focus on nailing things at the top of the list
[End
of Summarized Minutes.]
[RAW MEETING
MINUTES BELOW]
===============================
Raw
meeting minutes, [Randall Gellens]
ecrit notes (raw)
chairs review status of existing
documents
Chairs
note recent Emergency Services Workshop and upcoming one in Berlin in September
2010
Brian
Rosen gives update on framework -11
Comments
that text on keying SRTP needs to be corrected.
Open
issue: If a P-A-I is present, it needs to be passed to PSAP; but RFC 3325 says
this can only be done with a spec(t) that defines
security. Group can choose to either leave it to PSAPs to create spec(t), or define spec(t) in phonebcp.
Brian recommends leaving it up to PSAP. No one in room
objects. Cullen asks why not just let it be removed in the rare
case that the calls comes in to a PSAP from a carrier outside its usual area
(e.g., Sierra Leone) with which it has no spec(t).
Brian
Rosen gives update on phonebcp -15
Lots
and lots of changes.
Discussion
on new text saying that endopints MUST use first
location supplied by an LCP. Randall Gellens suggest there aren't clear
requirements for this, should just say "MAY". After discussion,
group agrees to say "MAY".
Note
that requirements have been renumbered (meaning NENA i3, other documents which
reference will need to be changed).
Keith
Drage asks if the purpose of this presentation is to
seek WG approval for the changes. Brian confirms this. Keith and
others request that an explicit email with a link to the diff be sent to the
group asking for group approval.
James
Polk expresses concern that the changes to sip-location-conveyance have been been totally ironed out in text yet, hence approval for
changes in phonebcp may be premature. James
asks for extra time to review changes (he will be on vacation for two weeks).
Richard
Barnes gives update on rough location draft.
Brian
Rosen presented on additional data draft (not yet WG document).
Geoff
Thompson asks about source of data -- does it include an arbitrary third party in
a three-point call? Brian says see him after.
Discussion
of SIP implications.
Hannes says we need privacy considerations text.
Keith
Drage asks if additional Call-Info headers are
additive. Brian confirms that an INVITE can have lots of them.
Brian
Rosen presents on data-only (non-human initiated) calls (not yet a WG
document).
Brian
Rosen presents on PSAP Callback (non-WG document).
Richard
Barnes suggests security issues needs more work.
James
Polk asks if ultimate recipients are always PSAPs, or if e.g., a university
might be the destination. Brian confirms that the recipient is whatever LoST returned.
Hannes
presented on questionnaire sent to NENA, EENA, EMTEL
asking about call-backs
www.ietf.org/mail/archive/web/ecrit/current/msg07084.html
Geoff
Thompson asks if responders know what a call-back is, because he doesn't.
Hannes answers that this was defined in problem statement (with drawings and
other niceties).
Hannes
notes that the call-back document needs to be updated to reflect this feedback.
Hannes
also notes that it is difficult to judge the operational complexity of this,
especially security considerations.
Hannes
asks if this document should go for Experimental?
Hannes
asks for volunteers to implement this, especially PSAP UI. REACH 112 and
BEACH project will also be asked.
Suggested
solution: define call marking separate from the authorization model (identity
based versus role based); offer end-to-end and hop-by-hop security protection;
add discussion of identity and trait-based (role) authorization.
After
these changes, further feedback will be requested from EENA, NENA, and ETSI
EMTEL.
Question
about call-backs from non-PSAP entities (e.g., responders). Hannes says this
complicates things, but is covered in document.
Bernard
Aboba presented on Trustworthy Location (not yet a WG document)
Brian
Rosen comments that security only needs to be good enough for deployment work.
Discussion
of infrastructure required to have a worldwide VESA root with certificates for
every PSAP trusted by every LIS in the world.
Bernard
comments that NENA i2 has text saying to use particular security mechanisms
without an understanding of what is involved and what it buys.
Several
comments from floor that people like the document, it is needed.
Martin
Thomson presented on civic address boundaries.
Milan
Patel presentation on SOS parameter draft.
Asks
if document is going in right direction (if so, will take to DISPATCH).
Comment
that only one person in room has read latest version (which was posted very
recently).
Cullen
says he doesn't think the draft is going in the right direction to fix the
identified problems. Examples include extensibility (suggests removing
"="); semantics of tag need much better definition, too fuzzy now
("do as I say" vs. "do what I mean").
Report
from 802.23 by Geoff Thompson <thompson@ieee.org>
Richard
Barnes appointed IETF liaison to 802.23
Mailing
list is open to everyone.
Presentation
by Gabor Bajko on Unauthenticated emergency services
Discussion
on five drafts which are candidates for WG adoption.
Chairs
ask if anyone feels these documents aren't suitable for WG.
Martin
Thomson says the additional-data one, marked high priority, looks like a data
dump from a NENA document, needs much more work.
Cullen
says he feels that additional-data is a laundry list of what could be provided,
not what is needed.
Cullen
says it's not useful to have three out of the five marked medium priority.
James
Polk wants data-only document moved from low to high.
Comment
from floor that unauthenticated-access should be high priority.
Robert
Sparks says draft should be taken to DISPATCH, and maybe be AD sponsored.
Andrew
Allen says that, from 3GPP perspective, psap-callback
should be high priority, data-only low since that's still in early stages in
3GPP.
Hannes
says some of these documents have been languishing for two years, waiting for phonebcp and framework to finish, says the group can just
work on all at same time.
Hannu says he'd be happier if "high priority" meant
something.
Hannu says he agrees with Andrew Allen that psap-callback
is high priority.
Marc
(chair) asks Hannu if psap-callback
in current state is good. Hannu says he needs
to consult with others before answering.
Martin
Thomson suggests that we look at which drafts are hard, which easy, and the
group can do easy ones right away.
Brian
Rosen says NENA needs the two (additional-data and data-only) and suggests the
group adopt all five.
Randall
Gellens agrees that psap-callback should be high
priority.
===============================
Raw
Minutes – [Richard Barnes]
Here
are my raw notes on the discussion section at the end:
--
Martin Thomson: Concerned about additional-data
-- Looks like a data dump
from NENA
-- Needs more grooming;
underlying requirement is sound
--
Cullen: This prioritization scheme is not too useful
-- Need to know 'what's
second'
--
Polk: Think data-only should be a 'high'
-- Hadriel: Prioritize network-side stuff, such as sos-param
-- RjS:
Guidance is that sos-param is going to DISPATCH, not
AD-sponsor
-- Other than that, psap-callback
-- trustworth-location should
be fairly low; might not need to be an RFC
--
Andrew Allen: callback -> high priority, needed in 3GPP
-- May have terminal impact;
important use case
-- Think that data-only is
useful, but ok to stay low-priority
--
Hannes: <Complaining about timing>
-- Hannu: Like this approach, hope that marking high priority
items can speed them up
-- Second Andrew on callback,
regulatory requirement some places (need marking)
-- Linsner: Is this draft
what you need, as it is now?
-- Hannu:
Need to consult with technical people
--
Martin: Agree on callback/high, trustworthy-location/low
-- Maybe also sort according
to difficulty?
-- additional-data and
data-only are pretty easy, others are hard
--
Rosen: Agree to the difficulty classification
--
George: What about service classification?
-- Chairs: Dispatch
--
Peterson: Not necessarily a need to throttle here
--
Gellens: Agree that callback is high priority
-- Unclear that
unauthenticated access has the same urgency --> low?
-- RjS: Adopting these documents is on the table
-- Want the group to stick to
dates, focus on nailing things at the top of the list
===============================
Raw
minutes – [Roger Marshall]
15
min * Agenda Bashing, Draft Status Update, Charter tweaks (Marc Linsner,
Richard Barnes, Roger Marshall)
Robert
Sparks - asked question of the room – does anyone object to having the –rph-namespace draft be AD sponsored?
James
Polk - asked whether ECRIT would be mentioned anywhere in the process.
Brian
Rosen suggested that it didn’t matter, and that no objections exist.
--/next
20
min * PhoneBCP & Framework (Brian Rosen/James
Polk)
http://tools.ietf.org/html/draft-ietf-ecrit-phonebcp-15
http://tools.ietf.org/html/draft-ietf-ecrit-framework-11
Intention:
Discussion about the latest changes - There have been
changes due to IESG review, more changes required due to Location-Conveyance
rework.
-phonebcp, Brian going through the presentation
Keith
Drage – why can’t you take the second (location), for
example?
Brian
– we could change this…
Keith
– is the constraint to process the call quickly? So, for example, it could take any location
so as long as there is no delay in processing the call.
Brian
– then, I would have to be deterministic, for example – say x no. of
milliseconds.
Randall
Gellens – normatice replacement for can is “may”
Brian
– any objection to using “may”
Robert
–
Bernard
Aboba – taking the first location, may not result in a more accurate
location. The less said about this is
probably better.
John
– who is the target of this “must”
Brian
– Access providers
John
– I thought this was phonebcp – therefore the phone
mfr’s
(mumur) no! wait!
Robert
– does anyone see the need for another wglc? I will only be satisfied if I get a feeling
that enough people will have eyes on this at the IETF last call.
James
– I want to make sure that this isn’t rushed through.
Keith
– I’ve asked for an announcement to the list pointing to the diffs.
--/next
5
min. * Rough Location (Richard Barnes)
http://tools.ietf.org/html/draft-barnes-ecrit-rough-loc-03
Intention:
Update on changes required to match Location Conveyance.
Richard
– this is revved, had languished.
--/next
10
min. * 10 min. * Additional Data (Brian Rosen)
http://tools.ietf.org/html/draft-rosen-ecrit-additional-data-00
Intention:
Evaluate for WG item candidate - determine next steps.
Geoff
Thompson – is this intended to be from some arbitrary 3rd party?
Brian
– see me after, since there is a technicality, but simple ans. Is no.
Barc
–
Hannes
– need privacy
Keith
– is this accumulative, or can you have more than one?
Brian
– more than one. Each should have a different purpose.
--/next
10
min. * Data Only (Brian Rosen/Hannes Tschofenig)
http://tools.ietf.org/html/draft-rosen-ecrit-data-only-ea-01
Intention:
Evaluate for WG item candidate - determine next steps.
Brian
– sent towards the PSAP (citizen-to-authority)
Brian
– differentiation is whether or not you have two-way interactive media (this is
one-way)
James
Polk – I like this. Well done.
Alexander
Mayerhoffer – may be more useful to use a geo: URI
instead of a PIDF-LO.
Brian
– I’ll talk to you offline, but I don’t think so.
Cullen
– interesting to think about where you can’t use this – e.g., fire sprinkler,
etc. – this is
a congestion nightmare potentially.
Brian
– that’s why I mentioned aggregator.
Richard
Barnes – need some text and discussion around security.
Brian
– I welcome your input on this.
--/next
10
min. * PSAP Callback (Henning Schulzrinne)
http://tools.ietf.org/html/draft-schulzrinne-ecrit-psap-callback-03
Intention:
Evaluate for WG item candidate - determine next steps.
(presented by Hannes Tschofenig)
?
– what do you mean by both pieces
Brian
– phonebcp says you provide both a Contact element
(URI) and the AoR.
Hannes
– planning to contact the Reach project and PEACE, both in Europe.
John
Elwell – I understand that these callbacks can also come from non-PSAPs, will you be taking that into consideration?
Hannes
– yes, I think we should.
Randall
– to clarify, who was doing the callback?
Hannes
– for example, the PSAP hands it to a responder, and they call back.
--/next
10
min. * Trustworthy Location (Hannes Tschofenig/Bernard Aboba)
http://tools.ietf.org/html/draft-tschofenig-ecrit-trustworthy-location-03
Intention:
Evaluate for WG item candidate - determine next steps.
Bernard
– covers both location spoofing and identity spoofing.
Brian
– what I don’t get out of this document is what can be done.
Marc
– what’s the author’s goal for this document, is it to recommend, or just to
talk about the issues?
Cullen
– I also, like Brian, got out of this document, “we shouldn’t try anything
because it’ll fail”
Bernard
– that is not what the document says.
Richard
– I didn’t get the same thing out of it – but think it’s a great draft to
discuss what some of the potential solutions/implications are.
Hannes
– yes, that’s where we started from, many security scenarios are trade-offs,
and it is difficult to see the big picture.
Martin
Thomson – I like this work, somewhat overdue in terms of the analysis. To me, this is one of the most important
drafts considered today.
--/next
10
min. * Civic Boundary
(Martin Thomson)
http://tools.ietf.org/html/draft-thomson-ecrit-civic-boundary-00
Intention:
Review applicability to ECRIT.
--/next
5
min. * SOS Parameter (Milan Patel)
draft-patel-ecrit-sos-parameter
Intention:
Evaluate recent changes
Robert
Sparks – who in this room has read the draft – just published this week?
Cullen
– did just read the diff, don’t think it’s going in the right direction. One issue is that the extensibility of the
parameter use. Second issue,
Robert
– to correct Cullen’s statements, this doesn’t talk about this is an emergency
call.
Robert
– consider a significant prose touch on…
Cullen
– happy to help…
Milan
– will get in touch with you.
--/next
5
min. * IEEE 802.23 (Geoff Thompson)
Update
on 802.23
Geoff – spoke to
you last time at the meeting in March.
Geoff – Layer 2
shim, we talk a lot about unauthenticated access.
Geoff – next
meeting, an interim, located on big Island of Hawaii.
Martin – will
provide comments to the IEEE wg list server.
--/next
10 min. *
Unauthenticated Access (Gabor Bajko)
--/next
10 min. * Open
Discussion
Priority of the 5
individual drafts
Cullen – don’t
get much out of the low-medium-high rating
James Polk –
would like the low go to high (data only)
Hadriel Kaplan – sos-parameter
s/b highest
Marc – AD
sponsored
Robert – told
Milan to take to Dispatch
Hadriel – would rate callback as 1 and
unauthenticated as 2
Andrew Allen - ?
Hannes – some of
the docs date back 2 years, not made progress
Why do we
sequence artificially, not getting any work done.
Hannu – second Andrew, that callback is a
priority, one critical piece missing, the marking.
Martin Thomson –
somewhat tempted to agree with the callback, but do we have a different
category ranking, such as easy, medium, and hard?
Richard – could
you rank them as such?
Martin – top and
bottom are easy ones, and the rest, pretty hard.
Brian – I agree
with him. I see that all of these should
be worked on, don’t see a need to pick some not all. The milestone schedule is what we need to be
talking about.
Robins George –
Jon Peterson –
back when LoST was being
developed, there was a process to prioritize other drafts,
Randall –
Robert – if we
take a milestone date approach, then I want to make is serially, and take is
seriously.
Marc – I assume
that this means that the easier
/end