Interim meeting minutes

[Edward Lewis <lewis@tislabs.com>]

Thanks to our scribe, Paul George.

IETF provreg meeting
Location: 	Washington Dulles International Airport Marriott
Date:		Feb 20, 2001
Start Time:	10:00 AM EST
End Time:	3:00 PM EST

Chairs present

Ed Lewis
Jaap Akkerhuis

Minutes

Agenda review
	- requests to add items to agenda
		* nameservers as objects
		* namespaces
		* alternate transport strategies
		* BEEP
		* Security - authentication/PGP

State of the WG
	- Neustar's proposal side note
	- Slide: WG Documents
	- Slide: WG vs Milestones

Begin Requirements Discussion

Handle Issues
	- ability to reference objects in other registries
	  specifically: Contacts
	- move to a more general approach
	- a global namespace for object storage for each registry
	- privacy issues were brought up.
	- Decided that there is no reason NOT to use it (But shouldn't be in
          this protocol - only the ability to do it should be in the protocol)
	- Still an open issue

Transport Issues (BEEP, parsing at client)
  - statement made that transport alternatives are needed to improve
	  efficiency
  - suggestion made to specify that transport is a separate issue (agreement
    that it already is).
	- BEEP Protocol (short background)
		* Performance issues were brought up.
		* Suggestion to possibly move the transport, authentication and
		  security out of the protocol to simplify it.
		* Noted: the need to discuss the needs of domain lookups vs
all
		  other activities.
		* Decided that this is not critical for Requirements Document
		* Decision to move this discussion to the mailing list.

Data Collection Issues
	- data flows defined as technical vs social.
	- Identification of 4 data flow/collection properties:
		* Purpose
		* Recipients
		* Retention
		* Access
	- Issue: who announces their data collection policy and how do they
	  announce it (How to communicate data flow/collection policies)
	- It was brought up that this is distinct from security
	- Was suggested that this need arises when there are too many
	  relationships to track "out-of-band"
	- Decision to continue discussion on mailing list
	- Agreement that there should be a data collection section in the
	  requirements doc for the protocol

Security Issues
	- Discussion of the use of PGP certs for accessing data
	- Ability for the protocol to provide other solutions (from registries
	  and registrars)
	- The need to id a request by the Registrant all the way to the
Registry
	- The need to provide a second (or multiple) access points.
	- Agreement to change "Authentication ID" to "Authentication Info"
	- Discussion of the types of Contacts
		* Note that "billing", "tech" and "Admin" are considered
		  placeholders for the time being.

Lunch

NameServers as objects
	- nameserver roles:
		1 - attributes of domains
		2 - object in their own right
	- object would give the ability to lookup data with a handle at the
	  registry and protocol level.
	- Consensus that NameServers should be represented as objects in the
	  protocol.

I18N
	- discussion about whether or not we should reference either UTF8,
1646,
	  or 2277 as a requirement in the protocol
	- note that 2277 was already referenced
	- Decided that this was good enough.

Neustar XRP Proposal
	- Note that this document should be considered Neustar's view of
the RRP
	- Recognition that it is very similar to Hollenbeck's draft and noted
	  differences:
		* Uses BEEP explicitly
	- Neustar does not consider this to be in competition with Scott's
draft
	- Recognized the need to further ID differences between the two
          documents
	- Comments on XRP
		* Uses IP objects for notification of possible intellectual
                  property violations

	- Remain discussion centered around the PRESALES query and the fact
that
	  it represents 80-90% of all traffic load on a Registry's servers.
		* Possibly isolate the presale process into a different
protocol
		* Discussion of if the presale process belongs in the protocol
			- Check commands could be moved to another box
                          (implementation problem)
		* A note about making the check command contain optional
		  authentication, which then was noted: optional auth
results in
		  optionally robust data
		* Discussion about the point of separating the functionality
		  between two protocols
		* Discussion about using BEEP (for short time to market
		  considerations)

	- It was decided that a separate protocol is not yet necessary and
that
 	  this protocol should try to make the presales lookup as
lightweight as
	  possible in the current protocol.
  	* Assuming that the check domain functionality is actually a check
  	  object.

Design Teams
	- expected outcome of design teams
		* an in-depth study as to what needs to be included in the
 		  protocol spec.
		* Concentrates on part of the draft -or- design protocol while
 		  evaluating candidate protocols
	- Noted the need for multiple design teams
		* 1st  team looking at the base protocol
		* 2nd team looking at the transport mechanisms/issues
		* 3rd team looking at security
	- recognition of the need for multiple transport mechanisms because of
 	  email
	- Note that April is still the deadline for the initial requirements
          spec
	- Design teams work all through March
	- Deadline - end of week (Feb 23) for design team formation (5-7
people)
	- Note to make the next IETF meeting the deadline for the first
	  deliverable:
		* 1st deliverable: Issues and trade-offs w/ possible strategy
		  suggestions from each team.

Email addresses used as unique identifier
	- decided that it was not a good thing for now
	- Discussion moved to mailing list


Discussion : Security - transport security vs. information security
	- Security Design team should:
		* List threats
		* Suggest how to handle them
		* Perhaps categorize the threats and determine which of the
two
		  other teams should address the threat.

Discussion of IETF RFC creation process

Discussion of an Implementors Group to discuss design/protocol
implementation issues

Discussion of time-to-market for new registries

Discussion of group collusion issues/problems

Discussion of consummating the collution effort
	- Having a "commercial Implmentors consortium
	- Interoperability testing
	- Load testing
	- Rich Shockey volunteered to start Implementors group
		* Email to rich.shockey@neustar.com to join mailing list

Scott said he will submit a new provreg 00 soon.


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