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 want 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 characteristics

Jaap: There should be an email transport as well. A lot of the TLDs (such as ccTLDs) are already using email for registration (with ot without templates). An email tranport mechanism will also be a nice transition mechanism for registries who want to upgrade to a standard protocol such as the proposed epp.

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 on document
- -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.

You are viewing proxied material from ftp.icm.edu.pl. The copyright of proxied material belongs to its original authors. Any comments or complaints in relation to proxied material should be directed to the original authors of the content concerned. Please see the disclaimer for more details.