Provreg minutes from London

Edward Lewis <lewis@tislabs.com> Wed, 05 September 2001 16:10 UTC

Return-Path: <owner-ietf-provreg@cafax.se>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.0.Gamma0/8.12.0.Gamma0) with ESMTP id f85GASjs004116 for <ietf-provreg-outgoing@nic.cafax.se>; Wed, 5 Sep 2001 18:10:28 +0200 (MEST)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.0.Gamma0/8.12.0.Beta17) id f85GAR3i004115 for ietf-provreg-outgoing; Wed, 5 Sep 2001 18:10:27 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-ietf-provreg@cafax.se using -f
Received: from naptop.autonomica.se (naptop.autonomica.se [213.89.0.71]) by nic.cafax.se (8.12.0.Gamma0/8.12.0.Gamma0) with ESMTP id f85GACjs004107 for <ietf-provreg@cafax.se>; Wed, 5 Sep 2001 18:10:12 +0200 (MEST)
Received: from localhost (localhost [[UNIX: localhost]]) by naptop.autonomica.se (8.12.0.Beta1/8.12.0.Beta1) id f85GAHU7001972 for ietf-provreg@cafax.se; Wed, 5 Sep 2001 18:10:17 +0200 (MEST)
Received: from sentry.gw.tislabs.com (relay.hq.tis.com [192.94.214.100] (may be forged)) by nic.cafax.se (8.12.0.Gamma0/8.12.0.Gamma0) with ESMTP id f85Fs2js003993 for <ietf-provreg@cafax.se>; Wed, 5 Sep 2001 17:54:02 +0200 (MEST)
Received: by sentry.gw.tislabs.com; id LAA12170; Wed, 5 Sep 2001 11:58:23 -0400 (EDT)
Received: from unknown(199.171.39.33) by sentry.gw.tislabs.com via smap (V5.5) id xma012152; Wed, 5 Sep 01 11:57:47 -0400
X-Sender: lewis@pop.tislabs.com
Message-Id: <v03130309b7bbe934d4dc@[199.171.39.33]>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="============_-1212417275==_============"
Date: Wed, 05 Sep 2001 11:53:38 -0400
To: ietf-provreg@cafax.se, minutes@ietf.org
From: Edward Lewis <lewis@tislabs.com>
Subject: Provreg minutes from London
Cc: lewis@tislabs.com, jaap@sidn.nl
Sender: owner-ietf-provreg@cafax.se
Precedence: bulk

The official version...any further amendments will remain in the list archives.
------

Provreg Meeting Minutes
8-8-01, London England
Thanks to the primary note taker... Tom McGarry.

1. Agenda bashing - Ed Lewis
The "slides":
=============================================================================
Provisioning Registry Protocol WG (provreg)

Mailing list: ietf-provreg@cafax.se
Charter: http://www.ietf.org/html.charters/provreg-charter.html
Web Page: http://www.cafax.se/ietf-provreg

Wednesday, August 08 at 1530-1730 (3:30pm-5:30pm)
=================================================

CHAIRS:	Jaap Akkerhuis <jaap@sidn.nl>
		Ed Lewis <lewis@tislabs.com>

AGENDA:

The usual: bashing (the agenda) & document/wg status.........15 minutes
     Minute taker (http://www.ietf.org/instructions/minutes.html)
     Blue Sheets

OPP draft, comparison w/EPP and GRRP (James).................25 minutes
     draft-jseng-provreg-opp-00.txt

Discussion on Data Collection Requirements (Scott)...........20 minutes
     draft-ietf-provreg-grrp-reqs-02.txt
     http://www.cafax.se/ietf-provreg/maillist/2001-07/msg00002.html

EPP drafts, outside deadlines (Scott) ........................5 minutes
     http://www.ietf.org/internet-drafts/draft-ietf-provreg-epp-04.txt
     http://www.ietf.org/internet-drafts/draft-ietf-provreg-epp-*-02.txt

XRP draft, comparison w/EPP and GRRP (Eric)..................25 minutes
     http://www.ietf.org/internet-drafts/draft-brunner-xrp-00.txt

RIR comments on Provreg (Cathy, others?).....................15 minutes

Implementation-to-date commentary (?)........................15 minutes
     Discussion: comments are sought on the state of implementations of
     the proposals.  (Volunteers sought.)
                                                            ============
                                                               2 hours

Other Items that may creep into the agenda (but haven't been allotted time:

     The Definitions document
     draft-ietf-provreg-dn-defn-01.txt

>From the charter page:
Milestones

 Feb 2001 WG agreement on functional requirements for protocol
 Apr 2001 Initial specification of provreg protocol
 Jun 2001 Second draft specification
 Sep 2001 Submit draft for standards track

Internet-Drafts:
Domain Name and Related Definitions (17681 bytes)
Generic Registry-Registrar Protocol Requirements (46677 bytes)
Extensible Provisioning Protocol (111132 bytes)
Extensible Provisioning Protocol Contact Mapping (62792 bytes)
Extensible Provisioning Protocol Domain Name Mapping (62561 bytes)
Extensible Provisioning Protocol Host Mapping (43321 bytes)
Extensible Provisioning Protocol Transport Over TCP (12703 bytes)

NON-WG docs:
OPP: draft-jseng-provreg-opp-00.txt
XRP: draft-brunner-xrp-00.txt
=============================================================================
Review of milestones
EL - Original milestones were too aggressive.  Second draft was too loose.
New milestones are set to meet the groups needs, so we need to make sure to
keep pressing with the dates in mind.
Review of draft status
EL - Requirements draft is close to RFC, Core EPP draft has some proposed
changes, and other EPP extensions drafts have not yet been reviewed.
Two new non-wg docs; OPP and XRP

2. OPP Presentation - James Sang
Slides unavailable.
Mark Nottingham - Did you use existing XML protocol rather than develop a
new DTD?  JS - Other author needs to answer.  MN -I'll bring it to the list
Dave Crocker - What within EPP does not meet the needs of China?  JS - EPP
is a 2 entity protocol, does not support communications btwn other nodes
(r'ant-r'ar, r'ar-r'ar, etc.).  (Ask Dave.)
Eric Brunner-Williams - What kind of graph is OPP?  JS -
Rich Shockey - How will you maintain transactional intergrity btwn the
nodes?  JS - Every request is signed by each node.  RS - Do you prefer any
transport protocol?  JS - No we are transport agnostic.
Dave Crocker - Clarification
Jordyn Buchanan - Can't EPP meet your needs if we added the requirements
for signatures btwn nodes?
Mark Nottingham Guy - Do you plan on using XML schema rather than new DTD
Dan Manly - How do you make sure proper security is in each node?
Rich Shockey - What application would require coordination btwn four nodes?
Jordyn Buchanan - R'ant need to authenticate with a r'y, discussed on the
list and has been desire of some ccTLDs.  JS - Multiple tiered phone
companies.  Scott Hollenbeck response to JB, current EPP draft doesn't
provide this capability, but there's o reason why it couldn't be updated or
extension added.

EL - Should the WG accept the document?
Dave Crocker - Not good to have two protocol documents but we could try to
address the needs met in the document by integrating it into EPP documents.

EL - It may be best for JS to get the document where he wants it before
accepting it.
George Ballotsky - Process is too rushed to get a good protocol.
EL - We'll take the question to the list.
(Document has since been withdrawn from consideration.)

4.	Data Collection Policy Requirement - Scott Hollenbeck
Slides attached.
Dave Crocker - You can keep the rqmt knowing that it can't be resolved
right now.
Dan Manly - There can be a preference hierarchy.
Eric Brunner-Williams - I've addressed the suggested changes on the list.
R'ys need to distinguish btwn social and technical data.  Policy
announcement by R'ys is the problem that needs to be solved.  P3P is used
as a starting point because it exists, there's no suggestion that Provreg
follow P3P policies or procedures.  SH - What is the information that you
want presented?  EBW - Current policy at the time of the transaction.
Jordyn Buchanan - There are instances where r'ants may want to pick a
policy but r'y contracts dictate what the r'y does.  EBW - R'ars or r'ys
may request data that is above and beyond what is necessary and not
required by the contracts.
Dan Manly - R'ys can provide that information on their websites or by other
means.
Jordyn Buchanan - It would be good to hear from non-gTLDs.
Dave Crocker - It's an important issue and should be addressed, but it's
notin the critical path of ths group.  EBW - It's been done so this is not
a
Paul Kane - There are rqmts similar to this in some countries.
EL - Straw pole; As is - a few, Changed - none, Deferred - more than as is.
Dan Manly - Does deferring this break any laws in any countries?  Many
Yes's shouted out, no No's.

5.	EPP Status - Scott Hollenbeck

6.	XRP - Eric Brunner-Williams
Slides attached.
Jordyn Buchanan - I prefer distinct documents.  Is it possible to separate
BEEP from Push?  EBW - Yes.
Scott Hollenbeck - I support separate documents.  Push has some problems if
client is off.  Messages need to Que.  I support including it and moving
forward.
Dan Manly - Experience shows that r'ars are having a problem understanding
EPP.  Further extensions would only add to the confusion.
Dave Crocker - I originally thought that polling was the est solution
however the internet comunty has ot had allot of experience with
transaction models the more I learn about it the more I believe that there
are great performance benefits in push.
Jordyn Buchanan - There should be consistency with the event model.
Bruce Tonkin - R'ants should expect different models from different r'ys.
I support push as an option of the core protocol.
Rich Shockey - I support Bruce and disagree with Jordyn.  Let's not
preclude features that support other (non-domain name) r'ys.
Scott Hollenbeck - Push could create push-storms to the r'ars.
Dave Crocker - Queing problems could be solved out of the protocol such and
email.

7.  Notes on GRRP/EPP from an RIR - Cathy Murphy (ARIN)

Presentation Notes:
===========================================================================
ProvReg

Focus: How the drafts might or might not relate to the RIR's (mostly not)

* Current drafts are okay, but definitely domain centric, focus
  on relationships that can be seen with domain registrations

Commonalities:
- do registration of some kind of information at a basic level
- some user scenarios are the same (many ISPs act as re-sellers/brokers)
- similar registration of nameserver information (in-addr.arpa)
- similar registration of contact information (Whois)

Differences/Issues:

*1* fundamental difference: any "rights" of usage of domain name
    ends up with the registrant versus IP control is fundamentally
    hierarchical
    - end-user subject to upstream, whether an ISP, NIR, LIR or RIR
    - IP "transfer" is a top-down, not bottom-up, process
    - IP registration request is not for a specific, identifiable object
      like a domain name; rather, it describes an amount (/18), which they
      might or might not receive.

*2* Most domain registrations (GRRP) tend to be session-oriented, versus
    RIR registration process, which is longer and may extend over several
    days/weeks.
    - EPP 2.0 "All EPP commands are atomic and idempotent."
    - XRP 2.3 "XRP supports four major types of services  ...
      Each of these services is atomic in nature and identifies a logical
      transaction. Each of the requests is idempotent, either succeeding
      completely or failing completely and producing predictable results
      in case of repeated execution."
    - GRRP provides near immediate registration; RIR has a whole analysis
      review period (comparable to if domain registry were required to
      perform research for the other "IP", i.e., intellectual property
      and/or trademark research, and confirm application information)

    * first contact with RIR is more like an application, not registration

*3* RIRs don't have the volume
    - IP and AS Regs: 500 p/wk (max)
    - SWIP's/3000-5000K per day
    - transfers: 2 week minimum to process
    - routing registrations -- "IRR" -- different beast for ARIN; couldn't
      tell you the numbers

*4* Contact info is "technical" versus "social"

SUMMARY:

Suggest that ProvReg change Generic Registry Registrar Protocol (GRRP) to
Generic Domain Registry Registrar Protocol (GDRRP); save GRRP term if and
until there is a core protocol that does speak to registration objects
other than domain names.
===========================================================================
Domains have rights of the name holder.  IP addresses are different.
RIRs don't get requests for specific names.
EPP protocols are connection oriented.  IP addresses are not.  The
processes take longer.
RIRs do not receive the volume of requests DNS R'ys do.  500 in a week
would be allot.
Contact information is technical in nature and not social, there's a rqmt
to disclose it.
EPP needs to go a layer below.
EBW - Are you aware of anyone selling contact databases?  CM - No.
Mark Kosters - There is social data collected by RIRs.  They will need to
be concerned about privacy rights.
EBW - Can GRRP be saved or would you prefer it not be intended for RIRs?
CM - I prefer that it get changed to met RIR needs, but I understand that
there is a time issue here with the gTLD r'ys.
Scott Hollenbeck - Draft and WG goals are specific to domain names.  We
could have a new rqmts for RIRs.
Greg Someone Telnic - Some registries may be required

8.  XRP vs EPP
Poll - WG preference is to hammer the two into one protocol.
Scott Hollenbeck - The XRP extensions can be included as extensions.
Patrick Falstrom - Is it a problem if there were two models?  JB - If we
try it will fail.
Dave Crocker - Worry about long term and high performance.
Scott Hollenbeck - There is interest in writing an SCTP transport.  I don't
want to be forced to implement BEEP right now even though I believe it is a
good thing n the long term.
Mark Nottingham - W3C is also addressing this issue.
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                NAI Labs
Phone: +1 443-259-2352                      Email: lewis@tislabs.com

You fly too often when ... the airport taxi is on speed-dial.

Opinions expressed are property of my evil twin, not my employer.