Minutes of our Minneapolis Meetings (rough cut)

[Edward Lewis <lewis@tislabs.com>]

These are the merged minutes taken by James Seng and Olafur Gudmundsson.
(Thanks.)

Please send in your comments on this real soon before this becomes part of
the "permanent record:"

ProvReg Working Group/21st March 2001 Tuesday 3:45pm.
http://www.ietf.org/html.charters/provreg-charter.html

Agenda:
- Agenda bashing
- WG Status (Interim meeting etc.)
- WG Document Status
- Design teams presentations (Protocol, Transport, Securty)
- GRRP requirements DOC
- XRP Proposal
- AOB

WG Status - Edward Lewis
- requirements, defination doc
- hopefully to finish within a year
- 3 design team - protocol, transport, security
  - not binding, just focus
- 2 current proposal, epp and xrp. xrp is slightly different

Protocol Design Team - Scott Hollenback
- design team members intro
- new requirements issues
  - authid for all object updates
  - pass-thru element
  - common to all objects (aka handle)
  - make registration period and period unit optional
  - idenfification data purpose?
- base protocol design issues
  - client-server vs peer-to-peer (don't preclude client-server)
  - ping command?
    = Bill Manning: Ping has overloaded use
    + room consensus to change 'ping' to 'check'
  - query feature to pull notification
  - client hello for connectionless transport e.g. smtp, pipelining
  - command/response pipelining
    = James: isn't this it is a transport problem?
    = Scott: It may impact how to protocol
    = George: Large number of transaction.
    = Rick: Async transaction? Good or bad?
  - renew command vs update option
    - should recombine renew and transfer into update? no answer.
  - auth id for transfer vs other updates
    - non-sponsor use only for transfer request.
  - object relationship queries
    - good or bad in a provision protocol
- common object design issues
  - globally unique ROID for all objects
    - <local part>-<globally unique part>
    - registry part - local, iana? - globally
  - Non-Unicode charset identification
    - May need to store non-Unicode identifiers
    = Rick: Since we are dealing with XML and UTF-8 is the charset,
            would it be more appriopriate
    = James: strong suggest to use only one charset, e.g UTF-8.
             See CNRP on how it done properly.
- domain object design issues
  - Status flag per registry prolicy or protocol. No consensus
- contact object design issues
  - Add extension attribute for E164 numbers
  - Data purpose definition - no proposal
  - Dual charset representation - TDB

= Sheer: there is an original thing in EPP. There is something sending
  back TransID from server to client. is it still inside?
= Scott: No. Client can get back lost ID from servers.

Transport Design Team - Jordyn Buchanan
- Goals of the Design Team
  - identify issues relating to the movmeent of data between registr*s
  - recommend specific transport mechanisms
  - creates I-D to describe the use of the transport
- Issues
  - Transactional integrity is needed
    - How to provide it?
    - How do participants recover from loss of association
  - Need for two types of transport
    - "real-time" with high volumne of transactions
    - "email-based" with low volumne of transactions
- Options for Real-Time
  - BEEP
    - provides standardized framework
    - concern about overhead and lack of operational experience
  - TLS
  - Various "non-literal" transport
    = involves mapping base provreg to over-the-wire format
    = provide better network efficieny and reduce computation
    = Rick: can give an example of "non-literal"?
    = Bill: Fax? Can you handle this?
    = Jordyn: actually consider binary representation of XML
    = Eric: clarify about email-based?
    = Jordyn: yes, no consensus
    = Rick: request a poll on if this is what transport need to do?
    = Dave: already reach a consensus for completeness but wont proposal
    = George: consider total-paper base transport
    = Sheer: try look at volumne of XML over over-the-wire?
    = Jordyn: no operation data yet.
    = Daren: TLS and BEEP are interoperate...why two choice?
  - HTTP
  - UDP - not viable
- Ongoing Strategy
  - quantitative analysis of various options
    - ideally from ops experience, alt. computation based on known char'ics

Jaap: I dont mind Email template.

Security Design Team - Bill Manning
- ProvReg A&I, Authentication and Integrity - not security, no privacy
= Rick: Privacy over the connection is an important issues
- Security is a nebulous phrase
  - Items of real interest are: authenticity and integrity
  - Who does what where? - lots of prior (black) art
  - Provide guidance to other teams
= William: take encryption as an implication of privacy
= Bill: Privacy are really local manner. Those who decide has to make sure
  that protocol does not get into the way.
= William: Privacy needed on transport
= Edward: Just in case we run out of time, we will remeet at 2:00pm after
  the IDN WG. IDN WG may have 1 hour free for us.

XRP - Eric William-Brunner
- not a competiting proposal. It is an internal design doc of Neulevel.
- some comments received
- -01 was submit but bounced. intent to submit end of the week.
- diff from epp: BEEP is the explicit transport mechanism

Requirements Draft - Edward Lewis
- "We are really close now." so we thought
- Past month have steady stream of comments so not sure if it is ready
  for Last Call. Anyone have any other concern.
= Eric: Still concern that we have only client initiation.
= Rick: suggest protocol designer go thru requirements one by one.
= Scott: Yes for EPP. But the Protocol Design Team should do it again.
= Edward: Requirements extensibility

= Eric: Suggest next meeting to get larger block of meeting time.
= Rick: Privacy is something that seem to get cut-off
= Bill: What is about privacy that protocol need to take care.
= Rick: there are some info which only known by the registrant and registry
        and that needs to be take into consideration.
= Bill: the use of encryption to protect privacy is fine. but have not seen
        all the design team document to make any comment.
= Dave: encryption can ensure integrity violation is not perfect.
        protocol privacy and database privacy is different.
= Bill: Privacy is a sensitive word as bad as security.
= Eric: Policy for data-collection as a separate issue from privacy /
encryption
= Zhuyu: Why is UDP ruled-out for transport?
= Jordyn: provreg protocol payload is likely to exceed datagram, many services
          like traffic congestion need to be re-invented.

Resumed 22nd March 2001 2:30pm

= Edward: worried that different teams may overlap each another,
  e.g. Protocol and Security cross
= Jordyn: weekly digest be publish so they can check
= Edward: by next friday, can every design team put something up
= Edward: what if transport does not provide the same security as the
          protocol design team expect?
= Jordyn: hope to see nothing we do now will preclude what future users
          may use this protocol
= Sheer: there is no way to treat security on transport generally,
         e.g. security over email very different
= Edward: Security - what is it we trying to protect?
= Sheer: privacy refers to maintain data integrity, not privacy as data
         privacy in data
= Edward: just want to scope this out and doc it it down
= Dave: did u say privacy = data integrity?
= Sheer: yes
= James: feels we still focus too much on domain. while that is a short
         term goal, strongly support a design team or someone to lead
         the effort. also we should continue to try to get other registry
         more involved in this wg.
= Edward: unique handle issues...a lot of discussion on mailing list.
= Scott: a lot of requirements posted and will be captured in the reqs
= Sheer: has consideration been taken that unique handle may be refer
         object outside the registry?
= Edward: reqs may be ready for last call after one more revision.
          but some concern over defs. maybe we should put back defs
          into reqs and send it in.
= Scott: okay, next week or so.
= Edward: next step until London. In a week of half, hopefully status
          report. feel free to comment on the result of the design team.
          design team is not final.
= Sheer: should we post weekly digest to the mailing list?
= room: no..yes..no..yes..chuckle
= Edward: I think we have consensus. weekly is good.


-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                NAI Labs
Phone: +1 443-259-2352                      Email: lewis@tislabs.com

Dilbert is an optimist.

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