Amicus Comment on Answers to Supplemental Quesiton #9 to NeuStar

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

Subject: Amicus Comment on Answers to Supplemental Quesiton #9 to NeuStar

Three NeuStar claims of error relative to the Gartner "evaluation" were
identified by ICANN:

	o "fluency" with the protocol subject matter, item [a],
	o "evolution" of the protocol extension framework, item [b], and
	o "important experience" of its technical contributors, item [c].

The third claim, item [c], has been corrected (abandoned) by NeuStar. The
remaining two claims were reasserted in NeuStar's Response to Question 9.


Comments on Response to [a]

NeuStar claims that:

	NeuStar has authored two drafts of the EPP protocol in the Provreg
	Working Group, the IETF Working Group responsible for EPP, and has
	participated in the crafting of all of the drafts produced in the
	working group.

	This work was not given proper consideration in evaluating NeuStar's
	fluency with registry-registrar protocols.

This refers to two possible sets of drafts:

	draft-ietf-provreg-epp-container-*.txt
	draft-ietf-provreg-epp-beep-*.txt

or

	draft-liu-epp-pa-notify-00.txt
	draft-liu-epp-ustld-00.txt

There were three authors of the first two drafts when they were accepted for
IETF change control. One remains in NeuStar's employ. It is a trivial matter
to search the PROVREG list archive to determine the participation of the set
of authors.

The merits of the third draft were discussed previously.

The fourth draft, draft-liu-epp-pa-notify-00.txt, was discussed extensively
by Scott Hollenbeck in his capacity as editor of the core PROVREG WG drafts,
in the PROVREG WG mailing list. It contains no new protocol requirement
statement, and proposed no general solution for any existing protocol
requirement.

Individual contributors to the PROVREG WG and still affiliated with NeuStar
have made the following substantive proposals in the current year:

	o adding reverse ip lookup (February 26, 2002)

	  [rejected: ip addresses not guaranteed to be unique,
		     object lookup using object attribute as key not in scope
		     (see "whois" et al for registry search),
		     potential to promote spam]

	o adding a command response code, a host status value, and a general
	  status value (February 27, 2002)

	  [accepted: already present in the .au and the .coop registries]

	o using the high-order bit in a header of the TCP mapping to signal
	  "push" (June 28, 2002)

	  [rejected: silent corruption of very large transfers via TCP,
		     application-layer semantics in TCL mapping is a layer
		     violation,
		     Area Director (IESG) comment: not in transport binding]

	o adding asychronous execution (July 18, 2002)

	  [rejected: Area Director (IESG) comment: protocol redesign required]

This summary is not exhaustive. It is representative of the contributions made
by individuals still affiliated with NeuStar to PROVREG, and is germane to the
question of evaluating NeuStar's "fluency" with registry-registrar protocols.

In sum, these NeuStar contributions were also astonishingly technically naive,
careless or unconscious of synchronous provisioning (not search) design goals,
abandoning transport-independence and layering, and indifferent to silent data
corruption.


Comments on Response to [b]

NeuStar asserts that:

	... we are in the process of modifying it to be consistent with
	the evolving concepts by which extensions to the EPP protocol
	are documented and implemented.

No part of the EPP extension framework is "evolving", or has changed in any
substantive form since DOMREG 2, IETF-49, December, 2000. At no point after
DOMREG 1 has IETF work advanced a key value syntax for a DOMREG protocol.

The DOMREG 1 was held at IETF-43, in Orlando. Dave Crocker, Kent Crispin,
Roberto Gaetano, and Sylvan Langois (authors) presented a draft. Notes for
this BOF were taken by Eric Bruner-Williams.

The protocol proposed in draft-crispin-srs-00.txt (later CORE SRS) used
key value pair syntax.

See: http://www.ietf.org/proceedings/98dec/index.html, Section 2.1.15,
Domain Registration Protocol (drp) bof.

The DOMREG 2 was held at IETF-49, in San Diego. Scott Hollenbeck (author)
presented a generic requirements draft and a protocol draft, these were
draft-hollenbeck-grrp-reqs-05.txt, and draft-hollenbeck-epp-00.txt, resp.

From: www.ietf.org/proceedings/00dec/slides/DOMREG-1/sld004.htm

			EPP Goals

	o Generic: Suitable for use in diverse registry-registrar
	  environments
	o Extensible: Extend the provisioning model WITHOUT CHANGING THE
	  BASE PROTCOL

The participants adopted a charter, and these initial documents. This is
the point of origin of the PROVREG WG, and of the documents under IETF
change control.

From: draft-hollenbeck-epp-00.txt, abstract

   This document describes a connection-oriented, application layer
   client-server protocol for the provisioning and management of objects
   stored in a shared central repository. Specified in XML, the protocol
   defines generic object management operations and an extensible framework
   that maps protocol operations to objects. 

The entire text of draft-hollenbeck-epp-00.txt may be found at the following
URL: http://www.watersprings.org/pub/id/draft-hollenbeck-epp-00.txt.

Section 2. Protocol Description (paragraph 2)

> Specifiecription in XML, EPP provides four basic service elements: a
> greeting, commands, responses, and an extension framework that
> supports future definition of managed objects and the relationship of
> protocol requests and responses to those objects.

The choice of syntatic representation (XML), and an extension framework,
were present.

2.5 Protocol Extension Framework (entire subsection)

> EPP provides an extensible object management framework that defines
> the syntax and semantics of protocol operations applied to a managed
> object.  This framework pushes the definition of each protocol
> operation into the context of a specific object, providing the ability
> to add mappings for new objects without having to modify the base
> protocol.
>
> Protocol elements that contain data specific to objects are identified
> using XML namespace notation with a reference to an XML schema that
> defines the namespace.  The schema for EPP supports use of dynamic
> object schemas on a per-command and per-response basis.  For example,
> the start of an object-specific command element would be described in
> generic terms as follows:
>
> C:<EPP-command-name>
> C:  <object:command xmlns:object="urn:iana:xmlns:object"
> C:   xsi:schemaLocation="urn:iana:xmlns:object object.xsd">
> C:    <!-- One or more object-specific command elements. -->
> C:  </object:command>
> C:</EPP-command-name>
>
> An object-specific response element would be described similarly:
>
> S:<response-data>
> S:  <object:response-data xmlns:object="urn:iana:xmlns:object"
> S:   xsi:schemaLocation="urn:iana:xmlns:object object.xsd">
> S:    <!-- One or more object-specific response elements. -->
> S:  </object:response-data>
> S:</response-data>

> This document does not define mappings for specific objects.  The
> mapping of EPP to an object MUST be described in separate documents
> that specifically address each command and response in the context of
> the object.  A suggested object mapping outline is included as an
> appendix to this document.

Present in the subsection for each EPP command is a discussion of child
(unspecified extension) elements and the extension framework.

Section 4. Formal Syntax

> EPP is specified in XML Schema notation.  The formal syntax presented
> here is a complete schema representation of EPP suitable for automated
> validation of EPP XML instances.

  ...

> <!--
> Human-readable text returned to a client may be in a language other
> than English.  This type allows specification of alternative languages.
> -->
>   <complexType name="clientTextType" content="textOnly"
>     base="string" derivedBy="extension">
>     <minLength value="3"/>
>     <maxLength value="80"/>
>     <attribute name="lang" type="language"
>      use="default" value="en-US"/>
>   </complexType>


The corresponding formal syntax from draft-ietf-provreg-epp-07.txt is:

  <!--
  Human-readable text may be expressed in languages other than English.
  -->
    <complexType name="msgType">       
      <simpleContent>
        <extension base="normalizedString">
          <attribute name="lang" type="language"
           default="en"/>
        </extension>  
      </simpleContent>
    </complexType>

Clearly no substantive change to the extension framework has been adopted.
Superficial simplifications of basic types have been made by the working
group from the author's original text.

Comments on Response to [c]

Correction of claim (relative technical competency) noted.

Summary:

	NeuStar's modified claim of "fluency" with the protocol subject
	matter (item [a]), is false.
	NeuStar's modified claim of "evolution" of the protocol extension
	framework (item [b]), is false.

Eric Brunner
General Manager, Wampumpeag, LLC