[ietf-provreg] For the archives, full minutes of the meeting in SF

[Edward Lewis <edlewis@arin.net>]

For one reason or another, the minutes for the SF meeting have taken 
a long time to appear.  The Jabber logs were used for the official 
minutes that were due two weeks ago.  In the "better late than never" 
category, here are the other minutes taken by Kim Davies.  This is 
the first posting of them, please take time to review them to see if 
1) they are accurate and 2) if there are questions about the 
discussions.

  - - - -

IETF 56 - Provisioning Registry Protcol (provreg)

Administrivia:
     - Chairs: Ed Lewis (EL) and Jaap Akkerhuis (JA)
     - Scribe: Kim Davies; Jabber: Andrew Newton

Agenda Bashing:
     - Agenda has been revised recently due to recent developments.
     - For bull session, need to firstly identify what needs to be
       solved - work out what the IESG comment means - and also address
       the concerns people have about building to that requirement.

State of the Group:
     - Group hinged on one issue that is causing many problems.
     - Answers to IESG comments
         - www.cafax.se/ietf-provreg/maillist/2003-03/msg00067.html
     - Core Documents (proposed standards):
         - EPP
         - EPP Contact Mapping
         - EPP Domain Name Mapping
         - EPP Host Mapping
         - EPP Transport over TCP
     - Remainign Document (informational):
         - Guidelines for Extending the Extensible Provisiong Protocol
     - Other documents exist as individual submissions, not working group
       candidates now.
     - Nothing stops experimentation.
         - Why are documents being discouraged? Track record is that
           no documents has gathered general interest in some time.
     - Aim to shutdown the group once core documents and 1 informational
       document is published.
     - Milestones:
         - March 2003: Respond to IESG Comments, Submit Guidelines for
           extending EPP.
         - April 2003: Decision on Alternative Transports
         - Likely to drop the remaining for September/October 2003
           (Perform interoperability tests, submit reports and revised
           specifications to IESG). If people really want to do this,
           to bring documents to Draft Standard, could reconvene later.

     - Rick Wesson (RW): Should we be evaluating extensions?

     - EL: The track record is that nothing has come along that
       was a good example of what we want to do. If someone wants
       to do something themselves there is no interoperability
       considerations - so why would the WG need to look at it.
       Also - we have not seen any drafts to describe them.

     - Scott Hollenbeck: Some of the extensions I have seen are not
       of interest to this WG, but of interest to others.

     - RW: We should have the opportunity to discuss it.

     - EL: We haven't seen a reason to justify the groups existence
       based on what has come in. We dont want to have the group
       constituted based on what may or may not come. Any extensions
       so far have not needed WG review.

     - RW: So the only way an extension gets documents is through an
       individual submission?

     - EL: Yes, we have to see enough support from the group to
       bring it in to the group.

     - AN: If it is being published as informational it could just
       go directly to the RFC Editor.

     - John Klensin: Are you going to address I18N issues or just assume
       everything is IDNA?

     - SH: If the issues are significant enough to warrant protocol
       changes that is suitable for an extension. The protocol already
       supports Unicode.

Privacy "bull" session:

     - Ted Hardie: I believe I can represent Randy Bush and Patrick
       Faltstrom's opinions on this. Scott has explained each IESG
       comment and its resolution. I believe Allison's comments have
       been resolved by these. I believe you are correct that the one
       remaining issue is the privacy issue raised by Randy Bush.
       "Why do domain/contact/.. not have granular information about
       privacy?" The suggestion was making the existing DCP element
       mandatory. I quoted this to Randy. All we are talking about
       is the registry-registrar part of it. DCP handles the registry
       telling the registrar the privacy policy of the registry. It
       is inheriting parts from EPP. In that case, when the registry
       and registrar have agreed on the way privacy is that if the
       registrant expresses privacy concerns to the registrar, the
       registrar evaluates the preference against the registry policy
       and if they dont match rejects the registration.
       Randy has said, OK, lets assume the registry handles these
       preferences and the registrar passes through the registrants
       privacy needs as expressed. He would like to see a standard
       mechanism available so the registrant and registry can make
       that decision too.

       This is not a mechanism that must be turned on, it just needs to exist
       in the protocol. He put it as per-element granularity for social data.
       The way I put this to Scott accidentally implied a particular syntax,
       which was wrong. He believes the protocol needs the registry and
       registrar to agree that it is the registry who will handle the
       decision rather than the registrar.
       Is that clear?

     - Rich Shockey: Everyone would like to do this but it adds
       complication. It could require a rewrite of contracts between
       registries and registrars, and registries and ICANN. A protocol
       burden being placed on registries and registrars that may not be
       able to be accomplished in a legal environment.

     - TH: I get no sense that this needs to be turned on in any
       bilateral agreement. If they can't do it, it does not need
       to be turned on. By creating a protocol mechanism, you believe
       it is going to imply something about the R-R relationship?

     - EL: We are being asked to make the protocol allow to do this?

     - RB: It must be mandatory to implement, optional to use.

     - RW: If these things were used today, it would violate our ICANN
       contracts.

     - RB: That is your problem.

     - RW: I agree we need to ignore these things and move it through. It is
       up to ICANN to mandate it.

     - RS: We want to do the right thing. When it is mandatory to implement
       and optional to use that is relatively OK. But what happens if the
       registrar sends the flags "do not use" and we ignore that, that
       causes a rat hole. If we dont accept the data it is a rejection of
       the registration which we cant do either.

     - JK: With all due respect I think this is a red herring. If
       we accept this is true. If you think it is a contract problem
       then you should not accept registrations with the wrong bits.

     - EL: One of the questions I have here for the IESG was about laws and
       protocols. This is the first time I have seen this argument clearly.
       I didn't see now the issue was anything more than privacy.

     - RB: Our job as protocol designers is simply to make sure the
       mechanisms are there.

     - TH: One thing I have inferred from Randy. We dont want to get into
       silly states where one party sends one state, and another sends
       another; and we dont want a sitation of arbiting the intersection.
       In a particular R-R mapping, only one is in use, so a registry using
       a DCP model can drop the request on the floor if it doesn't match.
       You can either use DND or DCP. I can then take my individual privacy
       policies and figure if they match it.

     - RB: Yes, there are many aspects of this protocol where if you
       dont like it you can throw it away.

     - TH: We had said DCP was mandatory. If they have made the decision to
       have the registry forward the information, if they use that can they
       not use DCP?

     - RB: DCP is aggregated DND in one sense.

     - TH: DCP is the glob that expresses privacy policy.

     - EL: DNP? Do not publish?

     - EL: Should it be per session?

     - RW: I have a real problem that we have to educate the ADs on these
       topics. As an implementor I have a particular view I would like to
       express with AD's negotiating their position before I express my
       point of view. I would like the DNP as a per object container, not
       per session.

     - RS: I consider this only applying to social information - personal
       information. I would make it explicit that we are referring to this.

     - SH: I had some conversations with patrick to get clarification on
       this information. He said we cant narrow this down to social
       information as that is a policy decision. SO it needs to be
       supported for all elements.. IP addresses etc.

     - RB: Are there any grey areas?

     - SH: Not that we know about.

     - RW: Talking about silly states. If someone marks their IP address
       as do-not-disclose, it should just return an error.

     - Edmon Chung: How does one disclose for what it can not be disclosed?

     - TH: A registrar talking to a registry needs to know about that
       bilaterial exchange.

     - George Michaelson: Randy is making a case for work being done to the
       protocol, and we are discussing policy issues. These areas are at right
       angles. Implement the feature, and pursue the social policy issues
       later. If we don't support it we are making a policy decision we don't
       want to support this behaviour.

     - RS: The adverse argument, if the feature is implemented, our
       courts might read that the feature is there and not being uses
       implies a behaviour. If it is there implies a kind of mandatory
       use. This is a rat-hole of legal issues.

     - EL: One of my questions before I saw this as a technical problem,
       it seems as if we are engineering to legal requirements. Some people
       falt it this way. I think it is clear now with this situation is
       we are trying to shift where an algorithm decision is made.

     - RB: We just want to give a protocol mechanism to allow people to
       do this. In different cultures it can be handled differently.

     - RS: I have to play Lessig - Code is Law at some times. What we do
       has legal implications we have to live with.
       The fact it is mandatory to implement, lawyers will start to sue on
       these kinds of things.

     - EL: I know enough about the law to know that I know nothing.
       We are here as engineers. We should stick to that and not worry
       about the law unless we know there is an empirical reason not to
       do this.

     - RW: I agree with RS there are legal trickle down problems, but I want
       to bring this back tot he technical. I want to see a proposal on how
       to do this. I want to do this on a per-registration basis. I dont know
       if they can be submitted on a per update basis. Per object I would like
       to describe what bits get set on each element. The legal issues will
       get us nowhere.

     - TH: You do not need to wait for the privacy draft from Blaze. My
       presumption is the protocol mechanism will allow expressing preference
       to the registry. Once it is reviewed by the IESG who had issue with
       this, it should move forward as this was the only outstanding issue.

     - EL: People seem to think this is a reasonable issue to solve.

     - Janusz Sientiewicz: There seems to be little support for "mandatory
       to implement, optional to use". Many support DCP per session. Any
       practical server implementation will only support a very limited
       subset for privacy options. There is cost in implementing things
       that are only optional.  Why should everyone be burdened with the
       cost that no-one will use.

     - EL: If it turns out no-one uses this feature, it will go away if
       we go to Draft Standard. We want to stop debating about this and
       start testing it. We can't wait for the perfect protocol - we need
       to test and refine.

     - JK: Looking at this from another perspective, ignoring the IESG.
       The likelihood of someone making a law against this protocol is somewhere
       near zero. The likelihood of a law that says you can't have this
       protocol without privacy issues, is very high given world events.
       So the make this mandatory to implement, optional to use is very
       pragmatic. So I disagree with RS.

     - RS: Extensions.

     - JK: No, for interoperability it needs to be in the core.

     - RS: I have strong objection to the fact the IESG has mandated that
       this has been done. I would rather this have been a core extensions
       that is mandatory to implement.

     - TH: I am not a lawyer, and I think this is an engineering question.
       I want to make sure the room has a common understanding of the eng.
       requirement that has been expressed. I want to check there is no
       confusion on the expectation here. Can we get a hum? Are we looking
       for a protocol mech. that allows a registrar to express to a registry
       at a binary level, a do-not-publish or do-not-disclose that applies
       on a per element basis - however it is done syntactically?

     - GW: It could be done per session though.

     - EL: The question is not yet complete...

     - TH: My understanding is, A mechanism to allow the registrar to tell
       the registry on a per element basis which elements it requires not
       be distributed or published. It doesn't mean it is syntactically on
       a per element.

     - JS: I want us to define privacy here, we should define which elements
       on the protocol level.

     - RW: There are different requirements... registry enforcement,
       registrar enforcement, per session, per object. We need a solution
       that suits all.

     - SH: I think one of the previous proposals already meets all the
       requirements expressed. [[so no extra work is needed]]

     - GM: I think we should enumerate which elements for which we consider
       the constraints should apply to identify what we consider to be the
       social data.

     - EC: Why can't this be in extensions?

     - EL: Procedurally, if we use extensions, we delay things. Plus the
       IESG would not accept it.

     - EL: Rick's request was something concrete to supply to the list.

     - RW: We dont have a concrete problem statement.

     - EL: OK:

           Want to allow "movement of enforcement point" between
           the registry and registrar. It should be mandatory to
           implement and option to use, and allow granularity of
           meta-data. It should be per element or per session.

     - RW: Another req. is that it could be expressed on a per object
       or per session basis.

     - SH: What does that mean? When a registrar creates a session they
       express parameters for the entire session. In my experience,
       no-one will want to express "every object i manipulate in this
       session i dont want you to publish"

     - RW: strike per session.

     - GM: It is only "per element" that qualifies as a social element.

     - RW: per object? per element? per facet? per value?

     - SH: See www.cafax.se/ietf-provreg/maillist/2002-12/asg00093.html
       and www.cafax.se/ietf-provreg/maillist/2002-12/msg00102.html

Extensions Document:

     - EL: Something the working group asked for a while ago. People trying to
       write extensions would come to Scott and asked if it was right. There
       was no guidance on how to do an extension to EPP. A few weeks short
       of 6 months ago. no other comments.

Host Objects:

     - EL: The one thing discussed with me in the last few weeks is the host
       objects. Hopefully someone with an issue with these will say something
       here. Scott thinks this problem is solved if you think of EPP in a
       different way. The other thing I hope to hear here is an explanation
       of EPP requiring host objects is causing people problems in doing
       registration. In Apricot I saw someone stand up and say what bad things
       EPP does to them. Hopefully someone can speak to what they said.
       Does anyone want to volunteer information about this recent discussion?

     - RW: What discussion?

     - Suzanne Woolf: We have expressions of concern from some registries.
       They should express them.

     - Frederico Neves (.br): What is the real reason to have a host object? It
       is only because of the historical model of gTLDs?

     - SH: I'll admit it started because it is the model I am familiar with.
       We have talked about this at great length on the list. I know .DE
       does this a little differently. There are bulk operations that typically
       happen in some registries that makes the object model much more
       efficient. That is why they are still there. Such as address changes,
       name changes.

     - FN: If you talk about address changes, you are only talking about
       glue records. You are only talking domains where the ns is under
       that domain. This is the only place. I only see host objects here
       handling host name changes. I see problems with registries with
       different security models. We saw on the mailing list many times
       people wondering about hostname registration by registries that dont
       have authority of the tld of that host. This is a security problem
       to have this data in your database. How do you authenticate this
       information to be put in your database and how do you know the
       people putting this information in your database is actually
       responsible or authoritative for this infomation. We know that
       there is a lot of deadlocks in this dfatabase because of this
       problems. I am just  trying to point that enforicng this in the
       protocol it is probably maintaing a model that is causing
       problems in the past.

     - SH: If I want to delegate a domain to ns1.foo.bar, whether I refer
       to that as an object or a name has no security problems.

     - Jorg Bauer: There are good reasons to use object, but there are reasons
       not to do it. We are talking here about a default mapping. It just
       defined an environment to set up a regitry. the problem comes with
       an old registry that have special policies. alot of these registries
       dont fit in this model, so they have to make a decision to either
       create new basic object and define them, or working with extensions,
       or a mixture. i think this leads us nowhere. everytime we have
       this discussion we get nowhere.

     - RW: We made a decision and we knew the implications. One problem we
       have is we cant delete a host object because it is being used by
       other domains. That is part of the trade-off. We could structure
       EPP to allow either/or... we could solve this with either functionality
       if we choose to go down that road. There is tradeoff with moth ways.
       I don't see that we cant figure out a way to integreate both, but
       what i hear is people are upset or disgruntled about using this,
       but they don't see either... a complete change. we have to do one
       or another.

     - EL: Document that is was a design choice and the rationale

     - RW: Need to find a way, now that we have more use cases, to allow
       these other uses.

     - EL: People come in late in the case, and dont want to rock the boat.

     - SH: Check the archives, discussed in the past with a proposal.
       It allows either/or. It was shot down on the list.

     - ??: another interesting thing in Australia.. we weren't using host
       objects and we are now. epp in encouraging a move to a uniform model.

     - FN: we have to write extensions to support something so basic like
       do a delegation. this is a protocol for domain delegations. this is
       a problem.

     - EL: I was hoping to hear from Joe Abley who had a good list.

Other obstacles to Proposed Standard:

     - There are a bunch of issues, like ROID, I haven't listed. Anyone
       want to speak about that. If not, we will just pass over this.
       This is one of the issues. Another issue from RW was the last
       verified in Atlanta we dicded to add as an extension.

     - RW: You say concensus and only one proposed that.

     - EL: Well there were a few. It fit the extensions solution. Now
       instead of arguing about the process. Is there anything you want
       to say about that to make us change our name?

     - RW: I will be a good person.

     - EL: Any other topics? We have the privacy stuff, and a better idea
       of the problem but not optimistic that we have a solution. If that
       works we have the proposed standard documents. SO I am grovelling
       for any other reasons to have something else said about the docs?
       If not, we're done.

       OK, so we are done. Thanks for showing up.

       Actions are to take privacy problem to mailing list. I will send
       out a summary.

       RW: Succinctly state the problem in 3-4 sentences when sent to the
       list, indented a few spaces.

       Message will go out early next week, when I get home. After a week
       after that, will send out solutions. Period of a month? Well before
       Vienna.

     - SH: What to do with the _09 draft? The queue was closed. That makes
       the DCP mandatory. I hear today that is not where we are going and
       there is no risk of expiry
     - RW: and people implement these drafts if he says DCP is mandatory it
       will end up in implementations.

     - EL: That question should go to the mailing list. some people said
       if the IESG agrees to this they agree. as that is not enough we
       have to reask this.
     - RW: We can say now we know this does not fulfil their requirements.
       Nothing is going to change that statement.

     - EL: I admit I wasn't thinking that way during the discussion.

     - TH: If you are expecting implementations that might do the wrong
       thing then we should probably hold off.

     - EL: OK.

End of Meeting.

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                            +1-703-227-9854
ARIN Research Engineer

It's true, my last college class really was "Introduction to Ada."