Subject: [Ietf-not43] any more comments for the requirements

From: [email-masked] (Andrew Newton)
Date: Fri, 13 Sep 2002 18:43:44 -0400

I'm looking to turn around another revision of the requirements draft. 
Are there any more comments on it?

-andy

---

From: [email-masked] (Rick Wesson)
Date: Sun, 22 Sep 2002 22:47:03 -0700 (PDT)

I have a requirement I would like to see in your next draft.

Object Terminology, words that talk about domains, contacts etc, and
status codes will be derived from the EPP Protocol Documents.

thanks,

-rick

On Fri, 13 Sep 2002, Andrew Newton wrote:

> _______________________________________________
> Ietf-not43 mailing list
> [email-masked]
> http://lists.verisignlabs.com/mailman/listinfo/ietf-not43
>

---

From: [email-masked] (Ted Hardie)
Date: Mon, 23 Sep 2002 09:48:31 -0700 (PDT)

Rick,
	It's a little unclear to me what you're asking for.  Are you
asking that the language in the requirements draft that talks about
domains etc. reference the provreg documents, or you asking that we
require that protocol documents reference that language?  If it's the
former and there are specific cases where you feel that the language
does not match, a citation would be helpful to me and I'm sure to
others as well.
	Also, I'm not sure why language around status codes would fit
into this group.  The status codes themselves would not be shared
between the two protocols.  The whole range of <update> comands from
EPP will not exist in CRISP, to give a quick example, and the status
codes would thus not make sense in the CRISP context.  If you
can clarify the proposed requirement here, I'd appreciate it.
			thanks,
				Ted

---

From: [email-masked] (Rick Wesson)
Date: Mon, 23 Sep 2002 10:22:43 -0700 (PDT)

The facts that EPP and CRISP both deal with the same objects I hope we can
use the same or simular language in the drafts to explain those objects.
If CRISP is to accurately publish information of those objects the terms
of the attributes and values SHOULD be as consitstant as possable.

In piticular status values used in EPP status commands SHOULD be a subset
of the potential status values in the CRISP protocol.

My request stems from http://lists.verisignlabs.com/pipermail/ietf-not43/2002-September/000238.html
and  http://lists.verisignlabs.com/pipermail/ietf-not43/2002-September/000239.html

-rick

---

From: [email-masked] (Andrew Newton)
Date: Mon, 23 Sep 2002 14:23:01 -0400

This is a MIME-formatted message.  If you see this text it means that your
E-mail software does not support MIME-formatted messages.

--=_zark-32447-1032806191-0001-2
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

So, something like:

Domains in this service MUST be capable of representing attributes and 
values of the domain objects in EPP.  Contacts in this service MUST be 
capable of representing attributes and values of the contact objects in 
EPP.  The status values indicating the state of a domain MUST be an 
equivalent set or superset to the status values indicating the state of 
a domain in EPP.

Perhaps a little more massaged, but is that towards what you are after?

-andy

>>>>Are there any more comments on it?

--=_zark-32447-1032806191-0001-2
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

--=_zark-32447-1032806191-0001-2--

---

From: [email-masked] (Rick Wesson)
Date: Mon, 23 Sep 2002 12:04:31 -0700 (PDT)

andy,

sure that sounds like a reasonable requirement.

-rick

---

From: [email-masked] (Edward Lewis)
Date: Mon, 23 Sep 2002 15:28:41 -0400

I think you need a much more specifically worded requirement.  EPP 
(as an element of PROVREG) is chartered to handle more than domain 
names - although all of the work to date has been towards that goal. 
Also, EPP has yet to appear in RFC's and when it will it will be a 
proposed standard and hence subject to more revision.  And finally, 
it is important to make the distinction between EPP and CRISP plain 
to see, the two bodies of work are trying to solve issues for 
different sets of people.

EPP is designed to be the interface between registrars and 
registries, a kind of "in office" communication device.  Besides (the 
anomaly that is) the check command, EPP will see a net data flow from 
client to server. If I recall correctly, CRISP is exposed to the open 
Internet, with a net flow from the server to the clients.  I think 
that that is just the beginning of the differences.

EPP is currently before the IESG.  Besides the non-determinism of the 
passage of the set of documents, some implementation experience is 
being gained that will need to be included in the next round of 
documents.  It would be irresponsible to try and guess when other 
protocol specifications should be able to rely on EPP's definition.

Finally, at the chartering there was a direction to expand the early 
EPP proposal to cover more than domain names.  Up to now, the 
expertise to do so hasn't been participating in the process (it's not 
like we asked and they snubbed us) so all you see in the documents 
are domain names.  This may change in the future, so CRISP shouldn't 
expect to represent *every*thing that's in EPP.

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                          +1-703-227-9854
ARIN Research Engineer

---

From: [email-masked] (Stephane Bortzmeyer)
Date: Tue, 24 Sep 2002 14:04:24 +0200

On Mon, Sep 23, 2002 at 02:23:01PM -0400,
 Andrew Newton <[email-masked]> wrote 
 a message of 166 lines which said:

> values of the domain objects in EPP. 

Let's replace "EPP" by "EPP (official?) domain and contact mappings" and I vote
yes.

---

From: [email-masked] (Stephane Bortzmeyer)
Date: Tue, 24 Sep 2002 14:05:27 +0200

On Mon, Sep 23, 2002 at 03:28:41PM -0400,
 Edward Lewis <[email-masked]> wrote 
 a message of 58 lines which said:

> names 

Yes, see my patch (specifying we talk about the "official" domain
mapping of EPP, not about the EPP protocol core).