Amicus Comment on Supplemental Quesiton #9 to NeuStar

[Eric Brunner-Williams in Portland Maine <brunner@xxxxxxxxxxx>]

Amicus Comment on Supplemental Quesiton #9 to NeuStar

Question [a]

Part 1. Authorships of record:

Individual submissions by Scott Hollenbeck (Verisign) germane to this point
are on record:

	Extensible Provisioning Protocol DNS Security Extensions Mapping
	<draft-hollenbeck-epp-secdns-00.txt> (February 12, 2002)
	<draft-hollenbeck-epp-secdns-01.txt> (June 12, 2002)

	Extensible Provisioning Protocol E.164 Number Mapping
	<draft-ietf-enum-epp-e164-01.txt> (August 22, 2002)
	(this originally appeared as draft-hollenbeck-epp-e164, August 2001)

	NB. A NeuStar employee chairs the IETF ENUM WG, and commented on the
	    draft-hollenbeck-epp-e164 in the IETF PROVREG WG on August 23rd,
	    2001, and invited the author to submit the draft to the ENUM WG
	    on Sep 12, 2001.

Part 2. Implementations of record:

The word "extension" (... and implemented an extension ...) when used in the
context of NeuStar's claim is a misnomer. See Question [b], below.

Assertions of extension implementation germane to this point are also on
record:

	Daniel Manley's note to the PROVREG WG list of 19 Sep 2001, on the
	success the Liberty/Afilias extension, which had the technical fault
	of breaking protocol idempotency, but only during land-rush/sunrise
	registration, when automated processing was expected to give rise
	to exceptions, and use of EPP was generally _not_ assumed to be even
	possible in the time constraints of the .info registry deplyoment.

	Eric Brunner-Williams' note to the PROVREG WG list of 10 June 2001,
	Wampumpeag's implementation of transport over BEEP, see
	draft-ietf-provreg-epp-beep-02.txt (expired).

	Bruce Tonkin's note to the PROVREG WG list of 12 June 2002, on the
	specific extensions that have been added for policy information for
	the .AU ccTLD.

Each of these implementors is associated with a current proposal to ICANN.

Additionally, the following assertions of extension implementation also exist
and their authors may also be associated with a current proposal to ICANN:

	Roger Castillo Cortazar's note to the PROVREG WG list of 17 April,
	on digital signatures for object transform commands, and the 13 to
	19 August, 2002, concerning result codes for handling protocol
	extension-related errors.

	Patrick' (no last name) note to the PROVREG WG list of 11 June 2002,
	on the meta-extension (valid processing of epp-2, epp-4, and epp-5
	schemas.


Question [b] 

An individual submission authored by employees of NeuStar was discussed in
the PROVREG WG mailing list subsequent to a request by made by co-Chair Ed
Lewis on 2/19/02, for agenda items for the pending (3/20/02) face-to-face
meeting of the Working Group.

The proposal contained in draft-liu-epp-ustld-00.txt, published the previos
day, is to use name value pairs in strings to provide a mechanism for some
particular policy.

The following issues were raised:

	o the use of invalid Schemas (name value pairs) would violate the
	  protocol syntax, and cause validating parsers to generate errors.

	  see Extensible Provisioning Protocol, Section 4, Formal Syntax,
	  first paragraph (unnumbered).
	
	  see Generic Registry-Registrar Protocol Requirements, Section 6.1,
	      Standards Compliance, sub para [1].

	  NB. The syntax for CORE's SRS is name-value pairs.
	  NB. The syntax for Verisign's RRP is ABNF.

	o the non-use of an extensible Schema would violate the protocol
	  extension framework, specifically the object management framework
	  that defines the syntax and semantics of protocol operations
	  applied to a managed object. 

	  see Extensible Provisioning Protocol, Section 2.6.2. 

	o the intended application the proposal is specific to NeuStar, and
	  no functional interoperability issues were identified.

	o the proposal contained no new protocol requirement statement, and
	  proposed no general solution for any existing protocol requirement.

In sum, the NeuStar draft was astonishingly technically naive, abandoning
automated validation as a core design goal, and abandoning the IETF's own
tradition of "best practices" and protocol designs which anticipate future
extension without "flag day" transitions.

	o NeuStar made no further efforts to advance this draft in PROVREG,
	  it was not accepted by the PROVREG WG. 

	o Scott Hollenbeck publically undertook to write a draft, explaining
	  how extensions to EPP can be made consistent with EPP.

	  see Guidelines for Extending the Extensible Provisioning Protocol,
	   <draft-hollenbeck-epp-ext-00.txt>, (Aug 19, 2002)

Question [c]

Verisign, Afilias/Liberty, TuCows, GNR, PopTel, CORE, Gandi, NIC-Mexico,
IMS/ISC, MelbourneIT, and Wampumpeag, all show implementation technical
competency or contribute to the PROVREG WG record, comperable to, or superior
to that of NeuStar. 

Summary:

	NeuStar's assertion of unique accomplishment(s) (item [a]) is false
	and misleading.
	NeuStar's assertion of standards advocacy (item [b]) is false and
	misleading.
	NeuStar's assertion of relative technical expertise (item [c]) is
	false.

Personal end-note.

The following appears in the Internet Standards Process, RFC 2026:

      ********************************************************
      *                                                      *
      *   Under no circumstances should an Internet-Draft    *
      *   be referenced by any paper, report, or Request-    *
      *   for-Proposal, nor should a vendor claim compliance *
      *   with an Internet-Draft.                            *
      *                                                      *
      ********************************************************

The IETF is not a marketing instrument for sharp operators. Unlike Gartner,
it isn't some venue to be gamed, the stakes are far too high.

I contribute to the PROVREG WG.

Eric Brunner
General Manager, Wampumpeag, LLC
(Senior Technical Industry Liaison, NeuStar, January 2001 to January 2002)