[ietf-provreg] provreg @ ietf56

[Edward Lewis <edlewis@arin.net>]

Overhead slides and jabber log for provreg meeting, IETF 56 in San Francisco,
California, US, March 2003.  (Note that these notes were not passed 
before the group before submission.  Apologies to speakers for 
misrecording of statements.)

Provisioning Registry Protocol (provreg)

0. Scribe: Kim Davies - thanks
    Jabber: Andrew Newton - thanks

1. Agenda Bashing - few minutes

2. State of the Group (where the docs are) - few minutes

3. Privacy "bull" session - until exhaustion

4. Extensions Document - few minutes

5. Host Objects - few minutes

6. Other obstacles to Proposed Standard - few minutes

Abstract: Group is struggling with one remaining issue.

When (if) we get resolution, only one document remains in the WG.

Proposed future - just solve this one problem, get to
Prop Std on base specs, and to Informational on remaining
document and shutdown this group.
(New group when needed to advance to Draft Std.)

Core Documents (proposed standard):
   Extensible Provisioning Protocol
   Extensible Provisioning Protocol Contact Mapping
   Extensible Provisioning Protocol Domain Name Mapping
   Extensible Provisioning Protocol Host Mapping
   Extensible Provisioning Protocol Transport Over TCP

Answers to IESG comments:
   http://www.cafax.se/ietf-provreg/maillist/2003-03/msg00067.html
   Comments?

Remaining Document (informational):
   Guidelines for Extending the Extensible Provisioning Protocol

Other documents:
   Individual submissions exist, not WG candidates now
   Nothing is stopping experimentation
   Why are docs being discouraged?  Track record is that no document
   has gathered general interest in some time.

Milestones (mail list, not on charter page):

MAR 03 Respond to the IESG Comments (for Proposed)
MAR 03 Submit Guidelines for Extending the EPP to IESG (Informational)
propose ---> APR 03
APR 03 Decision on Alternate Transports

Likely to drop these:
SEP 03 Perform Interoperability Tests
OCT 03 Submit Interoperability Report to IESG (Informational)
OCT 03 Submit Extensible Provisioning Protocol to IESG (Draft)
OCT 03 Submit EPP Contact Mapping to IESG (Draft)
OCT 03 Submit EPP Domain Name Mapping to IESG (Draft)
OCT 03 Submit EPP Host Mapping to IESG (Draft)
OCT 03 Submit EPP Transport Over TCP to IESG (Draft)

Abstract: DISCUSS a compromise to the problem, PROPOSE this on the list.

Problem:

      We have a way for registry to tell registrar about privacy for a session

      We don't have a way for a registrar to tell registry about
      privacy concerns for pieces of data.

      IESG comment:
      > why do domain/contact/.. not have granular information about
      > privacy?

      So - we need to address domain and contact mapping (at least)

Questions to IESG:

      We don't have the privacy draft from Blaze, et.al., yet - will
      it hold up our documents?  I.e., should we be rushing if it will
      stall us anyway?

      Tough question: why engineer to legal requirements?  (Unlike way
      back when - IPsec.)  (This is a rat hole, but what's the justification?)

Questions for all:

      What's wrong with "dnd"?  Do Not Disclose to anyone in anyway,
      other than to sponsoring registrar.  "Existence of domain name?"

      What happens if the registry is legally coerced to disclose anyway?

no slides
Abstract: Murmurs in the hall: Folks not happy with host objects.

Complaint: EPP requires a series of actions by reg'r if reg'y does
not maintain hosts.

Proposal: alter Domain Mapping to let name servers be added instead
of reference.

Rebuttal: ?
Abstract: A few issues flare up

Discussion has not been sustained until closure

Fine, I can understand frustration w/slow process

But - now we are potentially to success - last time to speak

Jabber log of meeting...

Logs for provreg@conference.ietf.jabber.com
ed: agenda bashing
agenda 0 - Scribe Kim Davies Jabber Andrew Newton
agenda 1 - agenda basing - few minutes
agenda 2 - state of the group (where the docs are) - few minutes
agenda 3 - privacy "bull' session - until exhaustion
agenda 4 - extension document - few minutes
agenda 5 - host objects - few minutes
agenda 6 - other obstacles to proposed standard - few minutes
no objects to the agenda
ed: state of the group
ed: group has been stalled since Atlanta. One doc left in WG after this stall.
ed: discussing EPP documents
ed: proposed future - just solve this one problem, get to proposed std on
     base specs, and to informational on remaining docs and shutdown group
ed: IESG comments 
http:/www.cafax.se/ietf-provreg/maillist/2003-03/msg00067.html
ed: remaining doc is Extensions doc - to be informational
ed: other docs - individual submissions exist, not WG candidates now.  Nothing
     stops experimentation. Track record is that no doc has gathered interest.
ed: onto milestones
ed: mar 03 - respond to iesg - submit guidelines to extending epp
ed: apr 03 - decision on alternate transports
ed: likely to drop other milestones for going to draft standard
rick: it doesn't seem like we have no interest in doing extensions
ed: there doesn't seem interest in doing extensions
rick: there are no milestones for it. you are not allowing those questions
       to be asked
ed: yes, the track record so far as not been good
ed: why would the WG spend time discussing just one person's concerns?
     (In the sense that only one person cared.)
jaap: we have no seen drafts too
scott: my drafts are not of interest to this WG but to other WG's.
jaap: said something about extensions (i didn't get it)
rick: you can make us not talk about it
ed: not trying to squelch extensions, but nothing has come in for us to handle.
ed: we will have a better chance of doing our job with we have better focus
ed: we don't have a history of doing this
rick: only way an ext. gets documented is via individual submission?
ed: yes
andy: if it is info, can you just got to the rfc editor
ed: depends on whether iesg says it needs wg review
ed: we are not trying to stop experimentation, but we have not had a 
successful history of handling extensions.
jk: are you addressing i18n issues or are you assuming idna.
scott: what are the issues?
jk: is everything strictly idna and there are no i18n issues, or do 
you need to know character sets and other standard issues.
scott: we do the first case now.
scott: if it can be pointed out that the other cases need to be 
addressed, they would be candidates for an extension.
ed: time frame of two months

now on to privacy
ted: addressing privacy brought up by randy bush
ed: pulling up scott's message regarding issues with iesg
ted: the one remaining issue is the privacy issue raised by randy bush
scott: #8
ted: describing registry/registrar/registrant use case
ted: dcp tells the registrar from registry about privacy
ted: if registrant has privacy parameters, the registrar checks against
      the registry and rejects the registration
ted: in this model, the registrar is handling the intersection between
      the registrant and registry
ted: what randy has asked for is a case where the registry handles this.
ted: in this case, randy wants a mechanism where this is possible.
ted: mechanism allows registrar to give registrants parameters to registry
ted: randy wants it at the per element granularity on social data
ted: didn't need to imply the syntax, just semantics (attributes per element
      vs. blob)
ted: is that unclear
richard: everybody wants to do something likes this, but it is too
      complicated requiring rewrite of contracts between registries and
      registrars and ICANN.
richard: this is a protocol burden that may not be legally possible
ted: if their current agreement doesn't cover this, it does not need to
      be turned on.
ted: are you saying that just having this will cause something
ted: this is not a silly state item, you do one or the other.
richard: it is about implied contracts
ted: not dnp and other mechanism
ed: we are being asked to make the protocol general enough for this
randy: mandatory to implement, not to use
ricK: if this were used to today, it would violate our contracts with ICANN
randy: that is your contract problem
ricK: it should not be mandatory to use
richard: we are trying to do the right thing, but there are practical
          issues here.
richard: if a registry sends to a registrar these flags and the registry
          ignores that, it is a problem
randy: reject the data
jk: if ICANN changes the rules, you have to change the contracts.
jk: reject the registration if you don't agree with the flags.
jk: the important thing is that the protocol can be used when the policy
     changes
ed: this is the first time I've heard this argument clear enough to
     understand the issue
randy: it could be that the registrar/registry support a policy that the
     registrar doesn't offer.
jaap: some registrars may say they will not deal with opt-out policies
     because it is too much work.
ted: the critical thing is not to get into using both sets (mechanisms).
ted: either use dcp and not dnp
randy: there are many points in the protocol where if there is wrong
     data it gets thrown away.
rick: are they mutually exclusive
ted: is dcp mandatory if dnp is not used
randy: dcp is aggregated dnp
ted: you are ok with dcp not being mandatory in the presence of dnp
randy: no problem
ed: do not publish?
randy: blob vs attribute tag, doesn't matter
ed: per session?
ed: there are three levels of time interaction here.
rick: i do not like educated the AD's on these topics and then negotiating
       it in front of us
rick: i don't like doing this... the implementors and group members should
       have a say
rick: i would like dnp per object not per session
randy: i don't care
ed: how does this apply to social data or technical data... host mapping,
     domain mapping
rick: privacy is about social information
ed: just getting clarification
richard: yes, social info or person id info and nothing else
randy: or organizational
richard: same thing
richard: what is not clear about personal id info
randy: because it says "person"... need to include "org"
scott: paf says we can't narrow it down to contact info because that
        is a policy decision
randy: i don't find that interesting
randy: is there a gray area
scott: not that we can see
rick: this about ted's comments about silly states
rick: having dnp on hosts should generate errors
unknown: what level is the purpose for
rick: there is no purpose
randy: don't go there
randy: just a bit, how it applies to whois or whatever is about culture
        and contact
george: implement the feature and pursue the social policy issue later
richard: if the feature is implemented, whether it is used implies behavior
          in contracts
richard: this is a legal rat hole
jaap: law is not enforced by protocol
ed: are we trying to engineer  to legal requirements
randy: no
richard: disagrees
ed: we have been designing protocols for years without legal guidelines
ed: have process question
ed: we don't have the smarts to design the protocol with legal knowledge
richard: disagrees. we need to understand the protocol implications
          on the legality of the contracts
richard: lawyers will sue
ed: we don't know enough about the law in this room
rick: i agree with richard, but let's talk about the technical issue
rick: i like these bits/flags. would like to see proposal
rick: would like it on a per object basis
ted: you do not have to wait for the privacy draft from Blaze
ted: all other issues have been dealt with in the current doc
ed: was worrying if the blaze draft would have implications about this work
ted: no
george: the feeling of the group is that if we don't do this, then the
         IESG will not pass it on
richard: if it is mandatory to implement, the lawyers will use it
rick: what richard is saying is that just because it is there, we will
       be required to use it.
rick: we will all have to use it
randy: not all (referring to ccTLDs)
rick: but we need to suck it up and do this
ed: i hear one voice against this
rick: what is this?
richard: it is a good idea, I just want options
ed: does anybody else feel we shouldn't go here
rick: we have been told to go here
yan: among technical people on privacy, there is not much support for
      mandatory to implement. i saw support for dcp per session
unknown: does it have to be core or extension?
room: core
jan: there are a lot of marginal cases... i see no problem marginal cases in
      extensions
ed: what we are looking for is a basic of way doing it... extensions can
     be used for exotic cases
ed: this is up for proposed standard, if it turns out that nobody uses it,
     this feature will go away before draft
jan: implementors may pay lip service to core features, but will always use
      their own extensions
ed: our standardization process also for understanding when the features are
     not used before going to draft standard
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
richard: extensions
jk: no, you need it for interoperability purposes
jk: if you are doing business around the world, you will have to do
     extensions for each jurisdiction
jk: this is better for interoperability.
jk: if extensions are not standardized, it hurts everybody
richard: want standard core set of extensions
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.
ted: i want to make sure the room has a common understanding of the
      technical requirement
ted: do we agree on a mechanism for a registrar to registry do not
      publish or do not disclose on a per element basis?
george: we could do it per session
ted: registrar tell registry on per element basis which elements are
      dnp... does not mean syntactically on a per element basis
jan: this sounds like a particular syntax
ted: no
jan: i would like to see a requirement
ed: we are talking just about moving the enforcement point
jan: the requirement should say that the registrar should define to
      registry the privacy policy
jan: i disagree on this definition of privacy
ed: for this peace of information, you cannot disclose to anybody else
jan: but that has different meanings
ed: we don't want to spend time discussing what do not disclose means
jan: I want to know the real requirement... this is not a requirement, but
      a solution
jan: my impression is that a solution is being proposed as a requirement
george: but this might not be sufficient granularity
ed: I think you misinterpreted what I was saying
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.
ted: i am not trying to suggest a solution but a needed semantic, it is
      just difficult to do without discussing syntax.
ted: provide the basic binary functionality
ted: I agree with jk on going down the extensions path
ted: asks scott to write a mechanism to do this
scott: one was already proposed?
ed: I'd like to send to this list what we have discussed today.
ed: we also want to define something that is simple.
rick: I want to leave this room with the technical requirement in a
       few sentences
george: it would be a useful exercise on which elements it does not apply to
george: per elements mean on the set of elements it would apply to
jan: yes, and certain elements do not make sense based on the update
      command and the info command
unknown: we are not convinced that this cannot be achieved with extension
rick: yes
ed: procedurally it has problems with getting docs published
rick: we have been told by the IESG not to do extension
rick: we don't have a concrete problem statement
george: what you have on the screen can be made into the problem statement
ed: on prob. statement:
             1- granularity
             2-movement of enforcement
             3-mandatory to implement
             4-data unacceptable to registry
             4-setting method a or b is by receiver
             5 - not accepting data
             6- all data vs identifying info
rick: per session or per object?
scott: expresses concern that per session and per object could conflict
george: describes how he thinks about it for addresses
scott: what do you define a session
george: your session is my transaction
rick: are people backing off the per session issue?
room: silence
jan: per request not per session
rick: i think we agree
george: per element is only on those elements it would make sense to use
         on, not all elements in the protocol
rick: only social, not all
ed: per object/element/data facet
ed: do we want to try use an older archive proposal?
rick: can you solve that problem statement?
scott: looking in the archives
scott: pulling up message from archive
scott: describes blob solution
george: this would permit distinction between technical and abuse contacts
scott: yes
scott: at what level of granularity do we want
rick: i'm looking for clarification on how this works
scott: there was a friendly amendment to it... trying to pull it up
jan: wants disclose yes/no for an update
rick: this is for updates
scott: we need an update for this
scott: should the info command spit back the dnp preferences
rick: yes
scott: yes
unknown: what about getting back which elements you can disclose
ed: what would the registry refuse to let you change?
ed: does dcp do this?
scott: it doesn't have that granularity
ed: you want a failure code about not being able to set a dnp
scott & ed: multiple errors could be dealt with out of band
scott: agrees with this amendment
ed: we'll document this in one email
george: costs to implement should be documented
jan: I have made an argument for a simple syntax
jan: registry should have flexibility for default values
ted: dnd flag should be discussed to be yes for everything or no for everything
ed: we have discussed that before
ted: it should be done to be all uniform for the default
edmund: are we only talking about contact. what about domain.
ed: we are talking about domain and contact
edmund: domain is important across registries
edmund: they would use the same contact object
edmund: is there a per domain proposal for on/off on different elements
ed: I thought we were talking about any kind of object... no wait, just
     social data
scott: that would only be contact info
ed: this goes back to paf's statement. domain mapping?
ed: we'll make it clear in the list
ed: we will go to the list with proposal to see if it is agreed it will
     solve the IESG request

ed: on to extensions doc
ed: the ext doc exists to help people to figure out how to write epp
     extension documents
scott: new doc soon
ed: asks room to review the new doc

ed: on to host objects
ed: issues are coming up on the list, but we are not coming to closure on
     any of them.
ed: want to know epp is requiring host objects is causing issues with
     doing registrations?
ed: asks to see if anybody wants to volunteer info about this discussion
suzanne: we will implement what registries want
ed: I've heard this complaint from openReg. Would like the list of open steps.
frederico: what is the real reason for a host object?
frederico: is it because we need a way to change host names
scott: it was there originally for historical reason, but some do it
        differently.
scott: there are bulk operations where the object based models makes the
        process much more efficient... like address and name changes.
frederico: when you are talking about strictly needed for glue records
frederico: it could be handled in other parts of the protocol. host
            object only there for host name changes
frederico: has some security implications for registries with different models
frederico: how do you know that the people putting this info in you
            database are authoritative for it
frederico: enforcing this in the protocol is keeping a model that causes
            problems
scott: the issue of authority is addressed in either object or attribute models
frederico: but we have another mechanism for doing host checks
scott: why can't you use it?
scott: accepting the registration has nothing to do of whether it is an
        object or an attribute
frederico: it makes more sense to be attributes of the domain
joeng: we've had this discussion many times. the epp basic protocol
        and some kind of mappings
joeng: epp defines an environment to setup new mappings
joeng: a lot of ccTLD do not fit in the standard mappings and use extensions
joeng: you can define your own domain objects
rick: we made a decision on this.
rick: there is an issue where a domain can be deleted because of a host
       underneath it.
rick: there may be ways to get it to work if we go down this road
rick: there are trade-offs with both ways
rick: I think looking at this is reasonable and in scope for the group
rick: we made a choice, but we are now discovering a number of use cases
       where it causes issues
ed: we are now getting a wider range of review, and this is probably why
     we are seeing this issue now.
scott: that very proposal was discussed in the past
rick: but that proposal was either or
scott: no, it wasn't and the proposal was shot down
unknown: there has been a move to a uniform model since epp. we use to do
          non object method, but are now doing it.
frederico: has anguish over writing extensions for basic operations

ed: on to other flare up issues
ed: anyone here want to speak about roid or other issues.
ed: what about last verified? where did rick go?
rick: you said it was consensus, but only person said they wanted it that
       way (last verified as ext.)
ed: do you have anything to make us change our mind?
rick: no

ed: any other topics?
room: silence
ed: we are done

rick: what are the action items?
ed: take privacy problem to list.
scott: what is the mechanism to do that?
ed: I'll send out a summary
rick: can you simply state the problem in 3/4 sentences so that it sticks out.
ed: showing early discussion point on the projector
rick: I can help you word-smith it
ed: the problem and the approach are different things
ted: you sending both in the same message?
ed: separate messages.
ted: it is up to you, but the room seems to want the approach might help
      gel consensus.
ed: ok, that would provide more context
ed: action item 2: look at the old approach and ask if it is acceptable
ed: action item 3: send it to the IESG
ed: action item 4: ted buys us beer
ed: this will go out early next week
ed: a period of month... well before Vienna.
scott: what should I do with the 09 version of the core protocol.
rick: there are registries preparing to come out with implementations
       of the latest drafts.
scott: would rather hold of on real -9
ed: let's talk about that on the list
scott: but we know it doesn't answer the problems the IESG has
ed: let's ask it on the list
rick: I think we know now it will not meet that requirement, so we can say
       that now.
ed: you are right.
ted: you might want to hold off.
ed: are we done?
room: leaving

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

"I'm sorry, sir, your flight is delayed for maintenance.  We are
pounding out the dents from the last landing."