[Ietf-not43] minutes
Ted Hardie
Ted.Hardie@nominum.com
Wed, 11 Dec 2002 14:43:32 -0800 (PST)
My apologies to the group for the long delay in sending the minutes.
Both George (our official minute taker) and David (who provided
additional notes) turned their notes over to me the night of the
meeting, so all the delay from then until now is entirely my fault. I
have produced an edited version of the minutes from their input; that
is attached, as are the two input documents for your reference.
Please send corrections or clarifications to the list.
regards,
Ted Hardie
Minutes, Cross Registry Information Service Protocol WG (crisp)
Tuesday, November 19 at 1930-2200
CHAIR: Ted Hardie <Ted.Hardie@nominum.com>
Minutes edited by : Ted Hardie
Minute takers: George Michaelson, David Blacka
AGENDA: (post-bashing)
Agenda Bash, 5 mins (Chair)
Evaluation Process, 60 mins (Chair)
IRIS Diffs, 20 mins (Andy Newton)
LW Diffs, 20 mins (Eric Hall)
Requirements doc changes, 30 minutes. (Andy Newton)
Milestone & Charter Review, 10 mins (Chair)
During the discussion of the evaluation process, the chair proposed
that the requirements draft be re-written to distinguish between
protocol requirements and service requirements, and to eliminate
all MUST/MAY/SHOULD language from the service agreements. Those
present agreed to this change, and the document author will go
forward with re-drafting and forward to the list.
During discussion of the evaluation process, those present felt
the best strategy to be making an informal matrix matching
requirements to protocol capabilities, evaluate according to
that matrix, dropping or publishing as experimental candidate
protocols which were not selected. After confirmation by the
working group mailing list, this will go forward.
Rick Wesson volunteered to maintain the matrix, should the
working group mailing list confirm the view of those present.
Andy Newton then presented the IRIS diffs, most of which reflect
changes based on lessons learned during implementation of the
code base documented at http://iris.verisignlabs.com/ .
Slides containing details of the changes will be made available
for the proceedings.
Eric Hall presented changes to the LDAP-whois documents. Primary
change has been split of monolithic document into sections; two
intended as WG documents; four as experimental. Current issues:
internationalization, client input methods, SRV, the use of server
data stores, query output, and structured data elements. Those
present discussed search strategies in some detail, both for
internationalized strings and for the use of specific elements (such
email addresses). For the internationalization issues, it was felt
that the problem was common across uses of LDAP and that matching
the solution used here to the common LDAP solution was important.
Kurt noted that the LDAP community is working on the problem.
Those present then discussed how some of the security and privacy
considerations worked in this context. Eric Hall agreed that
redrafting the language around those issues would be appropriate
and he will revise the drafts as appropriate.
Andy Newton then led a discussion of the requirements document
issues which were raised during the last call period. This
discussion was a detailed review, resulting in the following
action items:
Andy will add a description of DDoS attacks to the security
section.
Eric and Michael will help redraft the paragraph on using the
DNS to discover the appropriate CRISP servers.
Those present agreed that specific language about abusive users
would be added to the draft, and that such language would
reference abuse definitions being service specific (as defined
in a document like an AUP).
Those present agreed to shift the current escrow language to a more
general requirement for serialization. Future language will
note that this may be useful for escrow, but is not sufficient
for itself. Discussion of the service requirements for escrow
indicated that a range of perceived need would make it difficult
to capture the escrow service requirements in this document.
Ted and Andy will draft new language on how error messages
to query access denials should work and post it to the list.
This language will make the explicit point that the protocol
must be capable of supporting access authentication but
that the service operators use of that is according to
local policy.
Those present carried on a lively discussion of query referral, but
did not come to a consensus. Objections were raised that the
requirements were presuming or imposing a particular query
distribution mechanism. Rick Wesson volunteered to write more on the
subject for the group. Those present did agree to split the protocol
requirements for querying a particular service operator from those
applied when a query applied to multi
Those present then discussed the question of settlements. It was
agreed that this question would be set aside until further
discussion of the distributed query mechanism could take place.
The group then discussed resetting milestones. Jan '03 was proposed
as the milestone for the requirements document; Feb '03 for the
protocol use specifications (which will be inputs into the matrix
to be maintained by Rick Wesson). The domain spec will be complete
by Vienna IETF.
----------------------------
From: George Michaelson <ggm@apnic.net>
Cross Registry Information Service Protocol WG (crisp)
Tuesday, November 19 at 1930-2200
=================================
CHAIR: Ted Hardie <Ted.Hardie@nominum.com>
AGENDA: Re-ordered from website to be
Agenda Bash, 5 mins (Chair)
Evaluation Process, 60 mins (Chair)
IRIS Diffs, 20 mins (Andy Newton)
LW Diffs, 20 mins (Eric Hall)
Requirements doc changes, 30 minutes. (Andy Newton)
Milestone & Charter Review, 10 mins (Chair)
Agenda Bash
Deliverables overdue. need to do charter bash and milestones
at the end.
Eval Process
Ted spoke to the eval process. has two components
a) protocol requirements
b) service requirements
hum 1: ok to change language of draft to distinguish service from proto
hum 2: not ok.
consensus is to do this change.
strategy choices
Ted spoke to seven strategies for evaluation
Mark Whal
Experimental in docs: used because an experiment is going
on, not to do this kind of thing
Ted, yes, but there are other uses
Paf there can be other uses of Experimental. Don't over-use other
taggings like Standard unless you know a doc is on that track.
Strategy 1)
1) describe choices in separate docs
2) eval and make choice in WG
3) document reasoning but single doc outcome
Strategy 2)
1) make a single doc, with a matrix of choices
2) eval and make choice in WG
3) document reasoning but single doc outcome
Strategy 3)
1) Make a matrix informally
2) eval and make choice in WG
3) Drop runner(s) up, or publish as experimental
Strategy 4) to oo
humorous
Ted calls for choices. feelings
Eric argues for strategy 3. too early to define one way
Mark Kosters seconds Eric on this
at least start with informal process
Ted calls for HUM to go to list, to proceed with 3
consensus is to do this
Peter Gee would like one of the jokes as a real choice
Strategy 4)
1) Publish both as experimental, and then
2) Review and
3) Decide
both have strong interest, proponents, whoever makes
the matrix has too much power, fairer strategy is to
do both as experimental, and then see
Rick Wesson no, lets stick to hum decision. we can do this fairly
Andy Newton I second Rick.
Ted ruled to stick to hum.
Rick Wesson volunteered to act as Matrix keeper
15-20 minutes to eval process
IRIS Diffs, 20 mins (Andy Newton)
changes to RFC2119 language. across all drafts
reflects development of the implementation
http://iris.verisignlabs.com/
<detailed changes per draft, see his slides>
(over in 10)
LW Diffs, 20 mins (Eric Hall)
listing issues, to be worked on, not done changes
republished original monolithic draft into sections
two as WG, four as experimental
enhancements, Internationalization issues
client input
SRV
server data store
structured data elements
query output
issues reflect IPR management
Rick Wesson ACE encoding for substring matching. its implementation
issue for almost all fields except domain name portion
Eric Substring search is in LDAP.
Rick but we don't have a requirement
Eric but its an issue for me as I do development on this stuff
Andrew There is a requirement apart from this substring, for
registrant name as well as domain name elements
summary
short term, need use domain component and ACE syntax
to meet requirements
longterm, alternatives emerging, subsequent issues
and damage to other services
Email lookup issues
'find user by email address' -nichdl functionality
lots of issues undefined. matching/filter/element syntax
undefined
i18n issues
search-scope issues
Nameserver lookups
similar issues to email.
syntax re-use possible need generalized mechanism
for defining structured resource records in ASN.1
Summary
Basic model is highly virtualized, flexible, allows
multiple entities top present authoritative views of
a common resource
a few big issues to resolve
Andy substring search in i18n is an issue?
Eric yes, but its also that LDAP needs extensions to cope, thats
another timeline. applies to lots of things, not just searches
trying to avoid decisions
Kurt working on it.
Andy extensible match filters for any of this?
Eric only defined for limited things.
Andy Section 5 of one draft talks about permissions.
Eric we can talk about this.
Andy people might think you are defining policy. that wasn't the intent
Rick can you use UTF8 in suitable elements eg common name?
Mark Whal Yes explicitly. its definedly so
Ted Eric said some of this belongs in the security considerations.
we can talk about how LDAP can work for us on this, and in
security considerations say things about privacy, very important
which mean that as you select the privacy settings for a container
you need to pay attention to that issue. but here, say how the
container can be used to do different permissions. ACL like.
Michael Sands? from DENIC?
what does accurate mean?
Eric means correct
Michael. its impossible. SHOULD is achievable, MUST doesn't reflect reality
Eric very uncomfortable pulling that out
Kurt Must is an implementation requirement when capitalized. a server
cannot know.
Eric wordsmithed it, to make it should for accuracy by must for protection
Requirements doc changes, 30 minutes. (Andy Newton)
Ted review topics, then go back
addition to security section
appending info to domain info lookup
dns label reference section, discussion on separate category
on misuse
discussion of abusive users
discussion of escrow support
change to yokohama decision on query access levels
access implies only 2 levels
authentication distribution wording changes
domain registrant search changes
nameserver search needed or not
query on cost settlements
addition to security section
talk about DDOS. using this info to do data mining
Rick I prefer option 2 (as does Andy)
<no further discussion in the room>
appending info to domain info lookup
Andy prefers number 2
Rick I offered 1, I am ameanable to 2
dns label reference section, discussion on separate category
on misuse
Rick explain the para proposed. not using another protocol to find
the server, but using DNS itself.
Eric and Michael from DENIC volunteered to help redraft the paragraph
with Andrew
discussion of abusive users
Rick Add text about AUP ie Option 2
Ted particularly important to capture sense 'counter to the AUP as defined'
type wordings. Its about the people providing the service who set
the AUP -its how you define abusive.
Ted policy should be stated, or stick to 'intended'
Hum decision is 'intended'
discussion of escrow support
Rick my intent was to capture that escrow has issues, that have
to be addressed. they have requirements, they may differ from
schema here, and going through this here may not be appropriate
may be able to use, but its different requirements
Andy Escrow does mean much more than serialization
Rick please strike Escrow
Ted move away from escrow to serialization, in protocol, to go to list
John Klensin this is the 'punt' action. Much better to try and do this
explicitly. we don't like punts. put language somewhere else implies
its somebody else's problem. it shouldn't be remove and forget, it
has to be remove and fix elsewhere, its part of the problem. its not
the text but the context and the trend
Leslie Daigle: Q: do we, the WG, feel we know the escrow requirements to
adequately capture them?
Andy can Rick tell us about issues?
Rick we've had discussions with people that want escrow, iterations of
what they want. in talking with 3rd parties, who provide escrow
we get different ideas. too many to do here. can do on list
Andy do couple of hairy ones
Rick ICANN want to be able to verify and validate elements, attributes
in escrow. that you can point to other references, so you don't
have to expand the file, but inside a single document. in escrow
you talk about set and delta's but here we talk about single doc.
its different.
Andy if we start defining escrow is there policy we have to define too?
Rick, sure there is but not off the top of my head
Ted when I worked for SRI, we made backup tapes from the DB. readable
only by the DB itself! (tops-20 reader specific) all of the
definitions about this stuff, is out of scope to an access protocol.
offline serialization is independant of operations. the schema used
by the servers should be capable of this kind of thing, take off
the escrow comment say instead, 'this might be one element in a
data escrow mechanism but it is not sufficient in and of itself'
hum went with this but
Cathy wordsmithing issues. in earlier options, say MAY, say you can,
but in option 3, its a MUST.
Ted the protocol must be capable of a serialization but it MAY be used
Mark K two things in this para. one is backup, and it says its
may be used for ...
Ted remember at beginning I said drop this for service requirements?
(use of must/may/should) the ones for protocol, keep, but the ones
for service, drop
Burt Hubert The problem with the SHOULD, is that if its for protocol or schema
then at some point w'll have to make a decision, that decision is going
to turn off some options. so I argue the SHOULD should be a MUST so
that if, in the future data serialization can be done, those who chose
not do to offline serialization,
hum for first thing MUST be capable of offline serialization
hum agreed to put MUST in first para
change to yokohama decision on query access levels
brought up on mailing lists, change wording to make it
deny queries meaningfully, but not to tell in advance
if a query is allowed
Ted don't know I agree this should be a requirement. should be in
protocol, but must it be done? its a matter of service policy
about the second thing
lets re-work the para to call out the protocol requirement
but remove a MUST on service, take new language to the list
Leslie to be followed up when the text is finalized. this text lacks
clarity, loose context reading the second sentence. needing
prescience would be bad
Andy clear requirement to return error message, second sentence
is about service.
Rick this opens the door to hacks/holes. invites problems
Andy I don't disagree, but the service operator has to make the
decision.
don't mind this option but it has to be clarified.
access implies only 2 levels
this wasn't deliberate. the intention was to permit levels
of access. no proposed text yet.
Eric privilege levels need to be defined by the operator. minimize
this to 'operators MAY impose security restrictions they wish
or desire or whatever'
authentication distribution wording changes
Rick whats the intention on the second sentence
Andy there is the posibility of distributed services, including
authentication, it shouldn't be forbidden
John Klensin I get a nervous feeling. this particular slide brings
out the problem by being right. as an IETF activity, its
ok to say what has to be in protocol, and what has to be
in policy, but a lot of these statements go over the line on
policy into what operators have to do. what we say is that
we have to provide mechanisms for them to do this, not they
have to do this. and pulling the MUST/MAY out of service is
good too. but a lot of language is going way beyond what the
IETF does
Andy protocol requirement or service requirement?
John protocol requirement makes me more comfortable. service not.
even saying 'the protocol must work this way' steps into service
policy sometimes
Ted this is beyond the level of wordsmithing we do here. thats not
the intention, lets use the high bandwidth time to find out if
there are major problems, cognitive dissonances with the ideas.
it still has to come to the list. bring issues to the list.
followon to John. at the beginning we did agree to move away
from using MUST/MAY/SHOULD in service requirements. Its clear
we may have to reword things once we do that, thats when we will
go back and say 'protocol must allow for this' etc etc, but I do
want ot make sure this document continues as a guideline for someone
to understand the context this document is in, for somebody
doing development. what a cross registry info service IS, so they
understand why we are making protocol choices, not to slip over
the policy line, but to capture why we do things this way.
Andy should the draft be re-broken up a bit, re-evaluate which things
are in which section?
Ted lets try doing a shift first, then do an extra rev. I know its
extra work? anybody disagree? make immediate cut here?
Nem Con
John Klensin. I strongly agree. as long as you are very clear, take
out the MUSTs etc, don't loose the fine tuning,
domain registrant search changes
Andy lightweight or not. modify opt-out to not go beyond protocol/service
issues rework
Rick context I was concerned about, was client wanting to perform a
search, eg for joe, 150 participants in the mesh, 10 have 90%,
and 90% have 10% of the answers, for the service to work, to
have a complete set of referalls, they have to do 150 referalls
and so what I was concerned with, was finding a reasonable mechanism
for participation, an incentive to the process, acknowledgement that
I have no answers, unfair that small service providers have to
answer the same number of queries as large
Andy we're not talking about the same thing when we talk about
'query distribution' in general.
Leslie what does 'generic' mean here?
Andy referall has to be useful, used in a subsequent query, not some
generic answer.
Ted after this change, split para at 'Results Set Change'
a base requirement that the protocol must support q referral
such that q referral isn't 'ask some other service' it must
be able to contain the context of the original query, and like
any other result, and carry further data being, eg 'for sale'
tokens, meaningful to the other registrars to whom the query
was made, so that when that query got passed, that token got
carried with it. that might help coordinate use of the mesh.
wordsmith to describe the protocol capabilities here. has least
to do with immediate delivery of results, the service descr
is about inter-provider stuff, the meaning of which is out
of scope.
Leslie ok. its been illustrated. attempting to define solution
at the requirements stage, originally, proposal was to
wind up with distributed search system/mechanisms, by virtue
of specific things in opt3 you pre-suppose how that will be done
either we talk about query dist, or we don't, and I don't think
3 captures the stuff to let us talk about it later
Rick to talk about this would require update to charter? is that
what you advocate?
Leslie, option 3 isn't big enough to go in this direction.
Rick its complicated. Its hard to communicate. I'll write more.
Ted serious objections to all of the current options. not worth a hum.
Teds capabilities for searching for registrants by exact name match
or ... (convert service to protocol) any objects? I suggest we
move these into two requirements.
1) what must be done for proto capabilities, when querying a
particular service operators
2) what capability protocol must provide when query applied
to multiple service operators
this way we don't loose the sense of 1) in fixing 2)
flag about crossing service operators boundaries
Hum to split apart
Carried.
nameserver search needed or not
Andy options: 1) remove because it can't scale and can re-create
private zone info, eg when data mining forbidden
2) modify, make it refer to data mining
do we need this section at all? used to do glue and other
functions
Rick two points, dealing with glue, and query mechanism, look
them up by IP not name. (Andy it does say IP address in the text)
in an operational perspective, if optional, and can be turned off
then most ops will do so. its asking for the customer list.
Andy so take it out altogether?
Rick yes, one option. just saying how I read it.
query settlements
Andy mechanism to do cost recovery and settlements
out of scope or use CRISP transparent tokens for
transactions. use for settlement or other purposes
out of scope
Ted It can make (business?) sense to do this stuff by letting <n> through
and then refer to a 1-900 charged service. So you can
argue you need a mechanism to support this.
but use of the term 'settlement' there, tends to assume its
inter-provider, if you presume this, you've constrained what
is going on. in an obscure way described mechanisms without
actually doing it. thats a concern.
using CRISP transparent tokens -need to create a requirement
pushing this out to implementation
Andy it is hard to discuss without talking about implementation
but the intent was to use these like Opaque, with the referrals
Rick take an idea to the list. something which will allow for
inter-provider, intermediary to do settlements in the
same context as query distribution. I understand your earlier
comments, but its like how queries can be limited, the marketplace
will solve some of this.
Ted do we need an interoperable way to do cost recovery to a single
service or leave this service by service basis?
Eric separate protocol and service
Andy I disagree, may need out of scope mechanism but has implications
for what we do here.
Rick exactly.
Eric there are any number of technologies for this. defining anything
about this external process seems totally out of place. hand it
off as a generic settlement negotiation, oob, like we talked about
before
Rick I think the reason I raised this issue was to try and address
the issue of answering all these queries that 'I have nothing'
find a way to make it so we can distribute, have incentives if
for some reason mesh participants have to provide stuff, an
incentive like settlement this is a reasonable thing to try and
do to solve the problem. lets find the right language
Eric we said split out the distributed issue, leave settlements on the
table until we get there.
Hum agree table this question until we have more fully discussed distributed
query issues, revisit at end
Hum if need to include this requirement now
called as 'table' (first hum)
Rick want more requirements for i18n and will write them
Andy accepted
about 1 to 2 hours. felt like it.
Milestone & Charter Review, 10 mins (Chair)
Ted
late on requirements. have milestones in the middle of passing
for delivery of first rev of protocol use statements. cant say
we delivered them, because we don't have requirements to measure
them against. so, re-visit both sets of milestones.
based on list activity, can close soon, but coming into hols.
propose Jan 03 as new milestone for reqts.
propose Feb 03 for protocol use spec
rember the matrix? we need drafts by feb 03 that can go into
that process.
Andy reading ahead to Apr 03 milestones, 'revise' -I thought this
meant like Erics core draft, something like that. can you clarify?
Ted IRIS is a use of the LDAP protocol. the difference here is we
aren't demanding a new protocol, we might be doing use of protocols.
both IRIS and LDAP both fall into this category its just a question
if you feel by Feb 03 you have a version to take into this process.
I'll check with ADs about charter updates, then back on list
Domain spec is also Feb 03 then.
given informal process, and has to be complete before proto spec
I think we have to give ourselves a little more time.
So, from Feb 03, how long?
Andy 2 months.
Ted too aggressive. By Vienna
Done at 21:50
----------
CRISP notes
Ted: Agenda bash. Ted asks if the milestones and charter review
should go at the end of the meeting.
Answer: Yes.
Ted: On to evaluation process. How many folks have been involved in a
working group with competing proposals? (a few hands [mrose, ted
hardie]).
Ted: Requirements document is the basis of evaluation, has protocol
and service requirements.
Ted: Hum for eliminating MUST MAY SHOULD for non-protocol
requirements. Does that make sense?
Comment: Some service requirements are required for interoperability?
(perhaps confusion between what is a protocol vs service requirements.
Some requirements start with "The service MUST...".
anewton: is a good idea, but ... (missed it, I think that he said that
the current document definitions are not clear with this
distinctions).
Hum: Yes
Ted: we are going to try to find a protocol that meets the protocol
requirements that best meet the service requirements. Does that make
sense? (seems so).
Ted: Strategies (see slides).
Comment: What means EXPERIMENTAL? thought it meant that an experiment
was going on, and when over a choice was made.
paf: doesn't have to be.
Ted: wants to use experimental status to help document how the wg got to where it did.
paf: sometimes use experimental because you don't really know if it
can become a standard.
Ted: midcom did a matrix, and some of the solutions dropped out, but
for the remaining solutions it was not good for selecting one.
Comment: dropping runner up and publishing as experimental can apply
to any strategy. There is a choice to be made at the end of any
strategy.
Ted: Do we have strong opinions on which strategy?
Bill Manning: Fuscha is a nice color.
Eric Hall: I like strategy 3 (informal matrix).
Mark Kosters: second was eric has said. We will find out more as we build.
Ted: Strat 1 requires a document editor, any volunteers?
Mark: this will all fall out.
Ted: Hum for strategy 3.
Hum: Yes.
Peter G: propose both as experimental, use both, then choose based on
experience. There is too much interest (advocacy?) to do this by
talking.
Rick Wesson: Advocate for doing informal matrix.
anewton: ditto. Would assume that the working group would decide.
Rick: volunteered to keep the matrix.
Ted: Up next, IRIS diffs.
anewton: (see slides) ... any question? (apparently not)
Eric Hall: LW diffs (see slides)
Rick Wesson: ACE-encoding for substring matching. Might have problems
with domain names portions, but not the other i18n stuff in the
service.
Rick Wesson: We don't have requirements for substring searches.
Should we have listed additional issues?
anewton: there is a requirement for partial name matches.
Eric Hall: have to use dc, and need to ACE-encode for that. Kurt
Zeilenga is trying to get an i18n domain component defined. But this
presents other problems. (sorry couldn't catch them).
anewton: would idc introduce a new matching rule?
Kurt: no (???) (sorry, couldn't hear him)
Eric: there are no extensible matches for domain names.
anewton: lw-core draft talks about permissions? Fear is that folks
will misconstrue as policy.
Rick Wession: does inetOrgPerson take anything other than 7-bit ascii?
Kurt: Yes.
Ted (as commenter): Policy stuff should be in "security
considerations" (quoting andy), and should talk about how you set
privacy stuff, but not what you set it to so much.
Marco Sanz: What does accurate mean? Must the data be accurate?
Kurt: How would the server know if the data was accurate (basically,
MUST not appropriate here).
Ted: Now go to Andy and the requirements draft discussion.
anewton: (see slides)
anewton: first going to go through the topics, then revisit each issue.
anewton: for Security Considerations, language to be added to talk
about preventing DDoS or unauth data mining.
Rick: option two is acceptable for me.
anewton: for domain info lookup, add requirement that arbitrary text.
Rick: both are ok.
Ted: Just pop up when you see something that is a problem (we don't
need to pick the text here). Mainly, are we ok with the change in
usage, and do we thing the text matches.
Rick: Explain DNS Label referencing
anewton: means we use federated system of DNS to find the
authoritative server. As opposed to using another protocol to pass
around where to go.
anewton: Eric and somebody else that the official scribe got
volunteered to help with text.
anewton: abusive users...
Rick: could you add something about acceptable use policies.
Ted: Service providers define abusive policy.
Ted: Hum for ... (gack! missed it.)
Hum: intended (I think).
anewton: escrow support...
Rick: escrow introduces a different set of requirements that should
not be addressed here.
anewton: is talking about serialization support better?
Rick: yes (I think).
Ted: Hum if this change is OK.
John Klensen: Has general ietf concern that folks are punting more and
more. Shouldn't be remove it and forget it.
Leslie: Do we feel that we have enough of and idea of what the escrow
requirements might be to deal with this?
Rick: We've talk to third party escrowers, but I cannot pull them out
off the top of the head.
Andy: hairy ones?
Rick: escrows talk about deltas, we talk about documents (??? had a
hard time understanding what was going on here).
Ted: ...story from SRI days about data backups being trapped in an unusable format.
Ted: change serialization support to saying that serialization might be part of escrow.
Cathy, Mark, and Ted had a conversation about the MAY and MUSTs of serialization support.
Rick Huber: The SHOULD about serialization should be a MUST.
Ted: Hum for changing to MUST.
Hum: yes.
anewton: query of access levels. Make the ability to query for level
of access a policy decision.
Ted: There is a protocol requirement because there must be an error
code. Rework the paragraph to call out the protocol requirement, and
put that on the list.
Leslie: Text onscreen is not terribly clear.
Some discussion followed about the meaning and clarity of the text by
Leslie, Rick Wesson, anewton and Ted.
anewton: document was not meant to imply only two levels of access.
Eric: in context of LW, trying to define access levels is undoable.
Favor rewording this.
anewton: authentication distribution. Here is some rewording.
John K: some of this stuff is over the line between protocol and
policy (I think, missed a lot of the meat of what he said).
Ted: this is a lot of wordsmithing. We don't really need to do that,
since everything has to go the list, but we are trying to get to the
meat of what needs to be done.
Ted: We need to clearly separate the protocol requirements from the
service requirments, but we still need to describe what a cross
registy information service looks like.
John K.: strongly agree with Ted.
anewton: domain registrant search.
Rick: explains his problem with domain registrant search. 10% of the
servers in the mesh have 90% of the information, but to do these
searches correctly, 90% of the server have to shoulder the same load
as the top 10%, which is a problem.
Leslie: what does the language mean in option 3?
anewton: ... (didn't catch it)
(scribe powers....fading...can't hold on...)
Ted and Andy try to explain option 3 (see the slides)
Leslie: we should either be talking about mechanisms for query distributions or not.
Rick: that would require an update to the charter.
Leslie: option 3 is not baked, more discussion is needed on list.
Ted: there are serious objection to all of the proposed objects, so no humming on this.
Ted: is the first paragraph of this is OK (first paragraph does not
talk about query distributions). Suggest that we move this
requirement into two: one about the server alone, the second about
what is done when a query is to be applied to multiple servers. I am
afraid of losing the first unobjectionable part in a discussion on the
second part.
Ted: Hum if it is ok to split these things apart.
Hum: yep.
anewton: nameserver search.
Rick: if I had the option to turn this off, I would.
anewton: isn't this true of all queries?
anewton: query settlements.
Ted: why make a distinction between queries against multiple servers
and queries against a single server? If we do this it should be able
to go all the way to the end user. The way the requirement was cast
implies inter-provider only. This is limiting. If we are going to
use tokens, then we need to create a requirment that says -- this
pushes out into implementation.
Rick: one option is that we come back with a more fully baked idea
that will allow somebody to may or may not do query settlements.
Ted: Do we need an interoperable way to deal with query settlements
against a single service.
Eric: separate protocol
anewton: disagree. this will have implications against what we are doing here.
Eric: there are any number of technologies that can do this, so
defining anything seems out of scope.
Rick: the intent was to address the needs of the small provider that
would have to answer "I don't have anything" too much.
Eric: since we agreed to work on the query distribution stuff, we
should table this discussion.
Ted: Hum if you agree we should table this question.
Hum: yes (near race between out-of-memory and yes).
anewton: any other requirements missed?
Rick: I would like to see the i18n requirements part have more words, I will write some.
Ted: back to milestones. We are late on some of the milestones. (ted reboots his laptop)
Ted: move requirements doc to Jan 03
Hum: yes
Ted: move protocol docs to Feb 03
anewton: clarify what document is what?
Ted & anewton come to an agreement that the Feb 03 documents are the
core drafts updated to match the requirments document.
Ted: I'll check with the area directors to see if we can't change the
milestone language.
Anewton and Eric Hall agree to Feb 03.
Ted: Since we have to do analysis, this [to submit as proposed
standard] will take more time.
Ted: How about by Vienna?
Ted: Hum on Vienna.
Hum: yes.
Ted: We are done.
George: we finished early! Way to go!