provreg@conference.ietf.jabber.com - 2003/03/20
[08:45] %% logger has arrived.
[10:07] %% andy has arrived.
[10:21] %% mrose has arrived.
[10:21] <andy> ed: agenda bashing
[10:22] <andy> agenda 0 - Scribe Kim Davies Jabber Andrew Newton
[10:22] <andy> agenda 1 - agenda basing - few minutes
[10:22] <andy> agenda 2 - state of the group (where the docs are) - few minutes
[10:23] <andy> agenda 3 - privacy "bull' session - until exhaustion
[10:23] <andy> agenda 4 - extension document - few minutes
[10:23] <andy> agenda 5 - host objects - few minutes
[10:23] %% yone has arrived.
[10:23] <andy> agenda 6 - other obstacles to proposed standard - few minutes
[10:24] <andy> no objects to the agenda
[10:25] <andy> ed: state of the group
[10:25] <andy> ed: group has been stalled since Atlanta. One doc left in WG after this stall.
[10:25] <andy> ed: discussing EPP documents
[10:26] <andy> ed: proposed future - just solve this one problem, get to proposed std on base specs, and to
[10:26] <andy> informational on remaning docs and shutdown group
[10:27] <andy> ed: IESG comments http:/www.cafax.se/ietf-provreg/maillist/2003-03/msg00067.html
[10:27] <andy> ed: remaining doc is Extensions doc - to be informational
[10:28] <andy> ed: other docs - individual submissions exist, not WG candidates now. Nothing stops experimentation. Track record is that no doc has gathered interest.
[10:28] <andy> ed: on milestones
[10:29] <andy> ed: mar 03 - respond to iesg - submit guidlnes to extending ep
[10:29] <andy> ed: apr 03 - decision on alternate transports
[10:30] <andy> ed: likely to drop other milestones for going to draft standard
[10:31] <andy> rick: it doesn't seem like we have no interest in doing extensions
[10:31] <andy> ed: there doesn't seem interest in doing extensions
[10:32] <andy> rick: there are no milestones for it. you are not allowing those questions to be asked
[10:32] <andy> ed: yes, the track record so far as not been good
[10:32] <andy> ed: why would the WG spend time discussing just one persons ...
[10:32] <andy> jaap: we have no seen drafts too
[10:33] <andy> scott: my drafts are not of interest to this WG but to other WG's.
[10:33] <andy> jaap: said something about extensions (i didn't get it)
[10:33] <andy> rick: you can make us not talk about it
[10:34] <andy> ed: not trying to squelch extensions, but nothing has come in for us to handle.
[10:34] <andy> ed: we will have a better chance of doing our job with we have better focus
[10:35] <andy> ed: we don't have a history of doing this
[10:35] <andy> rick: only way an ext. gets documented is via individual submission?
[10:35] <andy> ed: yes
[10:37] <andy> andy: if it is info, can you just got ot the rfc editor
[10:37] <andy> ed: depends on whether iesg says it needs wg review
[10:37] <andy> ed: we are not trying to stop experimentation, but we have not had a successful history of handling extensions.
[10:38] <andy> jk: are you addressing i18n issues or are you assuming idna.
[10:38] <andy> scott: what are the issues?
[10:38] <andy> jk: is everything strictly idna and there are no i18n issues, or do you need to know character sets and other standard issues.
[10:39] <andy> scott: we do the first case now.
[10:39] <andy> scott: if it can be pointed out that the other cases need to be addressed, they would be candidates for an extension.
[10:40] <andy> ed: time frame of two months
[10:40] <andy> now on privacy
[10:40] <andy> ted: addressing privacy brought up by randy bush
[10:41] <andy> ed: pulling up scotts message regarding issues with iesg
[10:42] <andy> ted: the one remaining issue is the privacy issue raised by randy bush
[10:42] <andy> scott: #8
[10:43] <andy> ted: describing registry/registrar/registrant use case
[10:43] <andy> ted: dcp tells the registrar from registry about privacy
[10:44] <andy> ted: if registrant has privacy parameters, the registrar checks against the registry and rejects the registration
[10:44] <andy> ted: in this model, the registrar is handling the intersection between the registrant and registry
[10:44] <andy> ted: what randy has asked for is a case where the registry handles this.
[10:45] <andy> ted: in this case, randy wants a mechanism where this is possible.
[10:45] <andy> ted: mechanism allows registrar to give registrants parameters to registry
[10:46] <andy> ted: randy wants it at the per element granularity on social data
[10:46] <andy> ted: didn't need to imply the syntax, just semantics (attributes per element vs. blob)
[10:47] <andy> ted: is that unclear
[10:47] <andy> richard: everybody wants to do something likes this, but it is too complicated requiring rewrite of contracts between registries and registrars and ICANN.
[10:48] <andy> richard: this is a protocol burden that may not be legally possible
[10:48] <andy> ted: if their current agreement doesn't cover this, it does not need to be turned on.
[10:48] <andy> ted: are you saying that just having this will cause something
[10:49] <andy> ted: this is not a silly state item, you do one or the other.
[10:49] <andy> richard: it is about implied contracts
[10:49] <andy> ted: not dnp and other mechanism
[10:50] <andy> ed: we are being asked to make the protocol general enough for this
[10:50] <andy> randy: manditory to implement, not to use
[10:50] <andy> ricK: if this were used to today, it would violate our contracts with ICANN
[10:50] <andy> randy: that is your contract problem
[10:51] <andy> ricK: it should not be manditory to use
[10:51] <andy> richard: we are trying to do the right thing, but there are practical issues here.
[10:52] <andy> richard: if a registry sends to a registrar these flags and the registry ignores that, it is a problem
[10:52] <andy> randy: reject the data
[10:52] <andy> jk: if ICANN changes the rules, you have to change the contracts.
[10:53] <andy> jk: reject the registration if you don't agree with the flags.
[10:53] <andy> jk: the important thing is that the protocol can be used when the policy changes
[10:54] <andy> ed: this is the first time I've heard this argument clear enough to understand the issue
[10:54] <andy> randy: it could be that the registrar/registry support a policy that the registrar doesn't offer.
[10:54] <andy> jaap: some registrars may say they will not deal with opt-out policies because it is too much work.
[10:55] <andy> ted: the critical thing is not to get into using both sets (mechanisms).
[10:56] <andy> ted: either use dcp and not dnp
[10:57] <andy> randy: there are many points in the protocol where if there is wrong data it gets thrown away.
[10:57] <andy> rick: are they mutually exclusive
[10:57] <andy> ted: is dcp mandatory if dnp is not used
[10:57] <andy> randy: dcp is aggregated dnp
[10:58] <andy> ted: you are ok with dcp not being mandatory in the pressense of dnp
[10:58] <andy> randy: no problem
[10:58] <andy> ed: do not publish?
[10:58] <andy> randy: blob vs attribute tag, doesn't matter
[10:58] <andy> ed: per session?
[10:59] <andy> ed: there are three levels of time interaction here.
[10:59] <andy> rick: i do not like educated the AD's on these topics and then negotiating it in front of us
[11:00] <andy> ricK: i don't like doing this... the implementors and group members should have a say
[11:00] <andy> rick: i would like dnp per object not per session
[11:01] <andy> randy: i don't care
[11:02] <andy> ed: how does this apply to social data or technical data... host mapping, domain mapping
[11:02] <andy> rick: privacy is about social information
[11:02] <andy> ed: just getting clarification
[11:02] <andy> richard: yes, social info or person id info and nothing else
[11:03] <andy> randy: or organizational
[11:03] <andy> richard: same thing
[11:03] <andy> richard: what is not clear about personal id info
[11:03] <andy> randy: because it says "person"... need to include "org"
[11:04] <andy> scott: paf says we can't narrow it down to contact info because that is a policy decision
[11:04] <andy> randy: i don't find that interesting
[11:04] <andy> randy: is there a gray area
[11:04] <andy> scott: not that we can see
[11:05] <andy> rick: this about ted's comments about silly states
[11:05] <andy> rick: having dnp on hosts should generate errors
[11:06] <andy> ??: what level is the purpose for
[11:06] <andy> rick: there is no purpose
[11:06] <andy> randy: don't go there
[11:06] <andy> randy: just a bit, how it applies to whois or whatever is about culture and contact
[11:08] <andy> george: implement the feature and persue the social policy issue later
[11:08] %% ogud has arrived.
[11:09] <andy> richard: if the feature is implemented, whether it is used implies behaviour in contracts
[11:09] <andy> richard: this is a legal rathole
[11:09] <andy> jaap: law is not enforced by protocol
[11:10] <andy> ed: are we trying to engineer legal requiremetns
[11:10] <andy> randy: no
[11:10] <andy> richard: disagrees
[11:11] <andy> ed: we have been designing protocols for years without legal guidelines
[11:11] <andy> ed: have process question
[11:11] <andy> ed: we don't have the smarts to design the protocol with legal knowledge
[11:12] <andy> richard: disagress. we need to understand the protocol implications on the legality of the contracts
[11:12] <andy> richard: lawyers will sue
[11:12] <andy> ed: we don't know enough about the law in this room
[11:13] <andy> rick: i agree with richard, but let's talk about the technical issue
[11:13] <andy> rick: i like these bits/flags. would like to see proposal
[11:13] <andy> rick: would like it on a per object basis
[11:14] <andy> ted: you do not have to wait for the privacy draft from Blaze
[11:15] <andy> ted: all other issues have been dealt with in the current doc
[11:15] <andy> ed: was worrying if the blaze draft would have implications about this work
[11:15] <andy> ted: no
[11:16] <andy> george: the feeling of the group is that if we don't do this, then the IESG will not pass it on
[11:17] <andy> richard: if it is mandatory to implement, the lawyers will use it
[11:17] <andy> rick: what richard is saying is that just because it is there, we will be required to use it.
[11:18] <andy> rick: we will all have to use it
[11:18] <andy> randy: not all (referring to ccTLDs)
[11:18] <andy> rick: but we need to suck it up and do this
[11:18] <andy> ed: i hear one voice against this
[11:18] <andy> rick: what is this?
[11:19] <andy> richard: it is a good idea, I just want options
[11:19] <andy> ed: does anybody else feel we shouldn't go here
[11:19] <andy> rick: we have been told to go here
[11:20] <andy> yan: among technical people on privacy, there is not much support for mandatory to implement. i saw support for dcp per session
[11:21] <andy> ??: does it have to be core or extension
[11:21] <andy> room: core
[11:21] <andy> jan: there are a lot of marginal cases... i see no problem marginal cases in extensions
[11:22] <andy> ed: what we are looking for is a basic of way doing it... extensions can be used for exotic cases
[11:22] <andy> ed: this is up for proposed standard, if it turns out that nobody uses it, this feature will go away before draft
[11:23] <andy> jan: implementors may pay lip service to core features, but will always use their own extensions
[11:23] <andy> ed: our standardization process also for understanding when the features are not used before going to draft standarad
[11:24] %% ogud has left.
[11:25] <andy> jk: ignore the iesg policy, the likelihood of law against using this feature is near zero. the likelihood of the opposite is pretty high. therefore having them is the pragmatic option
[11:25] <andy> richard: extensions
[11:26] <andy> jk: no, you need it for interoperability purposes
[11:26] <andy> jk: if you are doing business around the world, you will have to do extensions for each jurisdiction
[11:26] <andy> jk: this is better for interoperability.
[11:27] <andy> jk: if extensions are not standardized, it hurts everybody
[11:27] <andy> richard: want standard core set of extensions
[11:28] <andy> richard: mandatory to implement but optional to use is probably the best we can do. I object to the way the IESG has forced this on us.
[11:29] <andy> ted: i want to make sure the room has a common understanding of the technical requirement
[11:29] <andy> ted: do we agree on a mechanism for a registrar to registry do not publish or do not disclose on a per element basis?
[11:30] <andy> george: we could do it per session
[11:31] <andy> ted: registrar tell registry on per element basis which elements are dnp... does not mean syntactically on a per element basis
[11:31] <andy> jan: this sounds like a particular syntax
[11:31] <andy> ted: no
[11:31] <andy> jan: i would like to see a requirement
[11:32] <andy> ed: we are talking just about moving the enforcement point
[11:32] <andy> jan: the requirement should say that the registrar should define to registry the privacy policy
[11:33] <andy> jan: i disagree on this definition of privacy
[11:33] <andy> ed: for this peace of information, you cannot disclose to anybody else
[11:33] <andy> jan: but that has different meanings
[11:34] <andy> ed: we don't want to spend time discussing what do not disclose means
[11:34] <andy> jan: I want to know the real requirement... this is not a requirement, but a solution
[11:35] <andy> jan: my impression is that a solution is being proposed as a requirement
[11:35] <andy> george: but this might not be sufficient granularity
[11:35] <andy> ed: I think you misinterpretted what I was saying
[11:36] <andy> rick: we are not agreeing and have different needs, per object vs per session, registry enforced and registrar enforced. all of these options are valid and we need to find a solution that addresses all for of those.
[11:37] <andy> ted: i am not trying to suggest a solution but a needed semantic, it is just difficult to do without discussing syntax.
[11:38] <andy> ted: provide the basic binary functionality
[11:38] <andy> ted: I agree with jk on going down the extensions path
[11:39] <andy> ted: asks scott to write a mechanism to do this
[11:39] <andy> scott: one was already proposed?
[11:39] <andy> ed: I'd like to send to this list what we have discussed today.
[11:40] <andy> ed: we also want to define something that is simple.
[11:41] <andy> rick: I want to leave this room with the technical requirement in a few sentences
[11:41] <andy> george: it would be a useful exercise on which elements it does not apply to
[11:41] <andy> george: per elements mean on the set of elements it would apply to
[11:42] <andy> jan: yes, and certain elements do not make sense based on the update command and the info command
[11:43] <andy> ??: we are not convinced that this cannot be achieved with extension
[11:43] <andy> rick: yes
[11:44] <andy> ed: procedurally it has problems with getting docs published
[11:44] <andy> rick: we have been told by the IESG not to do extension
[11:45] <andy> rick: we don't have a concrete problem statement
[11:46] <andy> george: what you have on the screen can be made into the problem statement
[11:48] <andy> ed: on prob. statement: 1- granularity 2-movement of enforcement 3-mandatory to implement 4-data unnacceptable to registry 4-setting method a or be is by receiver 5 - not accepting data 6- all data vs identifiying info
[11:48] <andy> rick: per sesion or per object?
[11:48] <andy> scott: expresses concern that per session and per object could conflict
[11:49] <andy> george: describes how he thinks about it for addresses
[11:49] <andy> scott: what do you define a session
[11:49] <andy> george: your session is my transaction
[11:50] <andy> rick: are people backing off the per session issue?
[11:50] <andy> room: silence
[11:50] <andy> jan: per request not per session
[11:50] <andy> rick: i think we agree
[11:51] <andy> george: per element is only on those elements it would make sense to use on, not all elements in the protocol
[11:51] <andy> rick: only social, not all
[11:52] <andy> ed: per object/element/data facet
[11:53] <andy> ed: do we want to try use an older archive proposal?
[11:53] <andy> rick: can you solve that problem statement?
[11:54] <andy> scott: looking in the archives
[11:55] <andy> scott: pulling up message from archive
[11:56] <andy> scott: descibes blob solution
[11:57] <andy> george: this would permit distinction between technical and abuse contacts
[11:57] <andy> scott: yes
[11:57] <andy> scott: at what level of granularity do we want
[11:58] <andy> rick: i'm looking for clarification on how this works
[11:59] <andy> scott: there was a friendly amendment to it... trying to pull it up
[11:59] <andy> jan: wants disclose yes/no for an update
[12:00] <andy> rick: this is for updates
[12:00] <andy> scott: we need an update for this
[12:00] <andy> scott: should the info command spit back the dnp preferences
[12:00] <andy> rick: yes
[12:00] <andy> scott: yes
[12:01] <andy> ??: what about getting back which elements you can disclose
[12:01] <andy> ed: what would the registry refuse to let you change?
[12:02] <andy> ed: does dcp do this?
[12:02] <andy> scott: it doesn't have that granularity
[12:02] <andy> ed: you want a failure code about not being able to set a dnp
[12:03] <andy> scott & ed: multiple errors could be dealt with out of band
[12:04] <andy> scott: agrees with this amendment
[12:04] <andy> ed: we'll document this in one email
[12:05] <andy> george: costs to implement should be documented
[12:06] <andy> jan: I have made an arguement for a simple syntax
[12:06] <andy> jan: registry should have flexibility for default values
[12:07] <andy> ted: dnd flag should be discussed to be yes for everything or no for everything
[12:07] <andy> ed: we have discussed that before
[12:07] <andy> ted: it should be done to be all uniform for the default
[12:08] <andy> edmund: are we only talking about contact. what about domain.
[12:08] <andy> ed: we are talking about domain and contact
[12:08] <andy> edmund: domain is important across registries
[12:09] <andy> edmund: they would use the same contact object
[12:09] <andy> edmund: is there a per domain proposal for on/off on different elements
[12:10] <andy> ed: I thought we were talking about any kind of object... no wait, just social data
[12:10] <andy> scott: that would only be contact info
[12:10] <andy> ed: this goes back to paf's statement. domain mapping?
[12:10] <andy> ed: we'll make it clear in the list
[12:11] <andy> ed: we will go to the list with proposal to see if it is agreed it will solve the IESG request
[12:11] <andy> ed: on to extensions doc
[12:12] <andy> ed: the ext doc exists to help people to figure out how to write epp extension documents
[12:13] <andy> scott: new doc soon
[12:13] <andy> ed: asks room to review the new doc
[12:13] <andy> ed: on to host objects
[12:14] <andy> ed: issues are coming up on the list, but we are not coming to closure on any of them.
[12:15] <andy> ed: want to know epp is requiring host objects is causing issues with doing registrations?
[12:15] <andy> ed: asks to see if anybody wants to volunteer info about this discussion
[12:16] <andy> suzanne: we will implement what registries want
[12:16] <andy> ed: I've heard this complaint from openReg. Would like the list of open steps.
[12:16] <andy> frederico: what is the real reason for a host object?
[12:17] <andy> frederico: is it because we need a way to change host names
[12:17] <andy> scott: it was there originally for historical reason, but some do it differently.
[12:18] <andy> scott: there are bulk operations where the object based models makes the process much more efficient... like address and name changes.
[12:19] <andy> frederico: when you are talking about strictly needed for glue records
[12:19] <andy> frederico: it could be handled in other parts of the protocol. host object only there for host name changes
[12:19] <andy> frederico: has some security implications for registries with different models
[12:21] <andy> frederico: how do you know that the people putting this info in you database are authoritative for it
[12:21] <andy> frederico: enforcing this in the protocol is keeping a model that causes problems
[12:22] <andy> scott: the issue of authority is addressed in either object or attribute models
[12:22] <andy> frederico: but we have another mechanism for doing host checks
[12:22] <andy> scott: why can't you use it?
[12:23] <andy> scott: accepting the registration has nothing to do of whether it is an object or an attribute
[12:23] <andy> frederico: it makes more sense to be attributes of the domain
[12:24] <andy> joeng: we've had this discussion many times. the epp basic protocol and some kind of mappings
[12:24] <andy> joeng: epp defines an environment to setup new mappings
[12:24] %% kcrispin has arrived.
[12:24] <andy> joeng: a lot of ccTLD do not fit in the standard mappings and use extensions
[12:25] <andy> joeng: you can define your own domain objects
[12:25] <andy> rick: we made a decision on this.
[12:25] <andy> rick: there is an issue where a domain can be deleted because of a host underneath it.
[12:25] <andy> rick: there may be ways to get it to work if we go down this road
[12:26] <andy> rick: there are trade-offs with both ways
[12:26] <andy> rick: I think looking at this is reasonable and in scope for the group
[12:27] <andy> rick: we made a choice, but we are now discovering a number of use cases where it causes issues
[12:27] <andy> ed: we are now getting a wider range of review, and this is probably why we are seeing this issue now.
[12:28] <andy> scott: that very proposal was discussed in the past
[12:28] <andy> rick: but that proposal was either or
[12:28] <andy> scott: no, it wasn't and the proposal was shot down
[12:29] <andy> ??: there has been a move to a uniform model since epp. we use to do non object method, but are now doing it.
[12:29] <andy> frederico: has anquish over writing extensions for basic operations
[12:30] <andy> ed: on to other flare up issues
[12:30] <andy> ed: anyone here want to speak about roid or other issues.
[12:31] <andy> ed: what about last verified? where did rick go?
[12:31] %% mrose has left.
[12:32] <andy> rick: you said it was consensus, but only person said they wanted it that way (last verified as ext.)
[12:32] <andy> ed: do you have anything to make us change our mind?
[12:32] <andy> rick: no
[12:32] <andy> ed: any other topics?
[12:33] <andy> room: silence
[12:33] <andy> ed: we are done
[12:33] <andy> rick: what are the action items
[12:33] <andy> ed: take privacy problem to list.
[12:33] <andy> scott: what is the mechanism to do that?
[12:34] <andy> ed: I'll send out a summary
[12:34] <andy> rick: can you simply state the problem in 3/4 sentences so that it sticks out.
[12:35] <andy> ed: showing early discussion point on the projector
[12:35] <andy> rick: I can help you wordsmith it
[12:36] <andy> ed: the problem and the approach are different things
[12:36] <andy> ted: you sending both in the same message?
[12:36] <andy> ed: separate messages.
[12:37] <andy> ted: it is up to you, but the room seems to want the approach might help gel consensus.
[12:37] <andy> ed: ok, that would provide more context
[12:37] <andy> ed: action item 2: look at the old approach and ask if it is acceptable
[12:37] <andy> ed: action item 3: send it to the IESG
[12:38] <andy> ed: action item 4: ted buys us beer
[12:38] <andy> ed: this will go out early next week
[12:38] <andy> ed: a period of month... well before Vienna.
[12:39] <andy> scott: what should I do with the 09 version of the core protocol.
[12:40] <andy> rick: there are registries preparing to come out with implementations of the latest drafts.
[12:40] <andy> scott: would rather hold of on real -9
[12:40] <andy> ed: let's talk about that on the list
[12:40] <andy> scott: but we know it doesn't answer the problems the IESG has
[12:40] <andy> ed: let's ask it on the list
[12:41] <andy> rick: I think we know now it will not meet that requirement, so we can say that now.
[12:41] <andy> ed: you are right.
[12:41] <andy> ted: you might want to hold off.
[12:42] <andy> ed: are we done?
[12:42] %% yone has left.
[12:42] <andy> room: leaving
[12:42] %% andy has left.
[12:53] %% kcrispin has left.