Subject: [Ietf-not43] minutes

From: [email-masked] (Ted Hardie)
Date: 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 <[email-masked]>
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 <[email-masked]>

Cross Registry Information Service Protocol WG (crisp)

Tuesday, November 19 at 1930-2200
=================================

CHAIR:	Ted Hardie <[email-masked]>

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!

---

From: [email-masked] (Andrew Newton)
Date: Wed, 11 Dec 2002 18:08:15 -0500

This is a MIME-formatted message.  If you see this text it means that your
E-mail software does not support MIME-formatted messages.

--=_zak-18831-1039648041-0001-2
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

My thanks to George, David, and Ted.  That was serious amount of stuff.

-andy

--=_zak-18831-1039648041-0001-2
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

--=_zak-18831-1039648041-0001-2--

---

From: [email-masked] (Leslie Daigle)
Date: Fri, 13 Dec 2002 16:46:17 -0500

Just one question/clarification:

> DNS to discover the appropriate CRISP servers.

Michael who? This is the first reference to a Michael.

[snip]
>   Michael Sands? from DENIC? 
[snip]
>   Eric and Michael from DENIC volunteered to help redraft the paragraph

Whereas:
[other notes:]
[snip]
> Marco Sanz: What does accurate mean?  Must the data be accurate?

Leslie.

-- 

-------------------------------------------------------------------
"An essential element of a successful journey
    is recognizing when you have arrived."
       -- ThinkingCat (c.1983 - 2002)

Leslie Daigle
[email-masked]
-------------------------------------------------------------------

---

From: [email-masked] (Ted Hardie)
Date: Fri, 13 Dec 2002 14:52:49 -0800 (PST)

> And, is it really "Michael":

Michael is Marcos Sanz from DENIC; he sent me a correction earlier
on this point, which I thought had been cc:ed to the list.  I'll
forward it for the record.

Thanks for the careful reading,
				Ted