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