Subject: [Ietf-not43] IRIS updates/adds

From: ehall at ehsco.com (Eric A. Hall)
Date: Wed Aug 27 22:39:15 2003

I don't see any discussion on in-band modifications to the data-store.
There doesn't appear to be any definition of the necessary verbs nor any
discussion on update responses (record exists, attribute missing, etc) or
anything else.

I know the requirements state that updates are out-of-scope, but a
read-only directory service won't be useful in the long run (dynamic
registration is going to be critical to many layered services). I guess
I'm guessing what your plan is here.

Also, in light of the dual-mode i18n approach, updates would need to
modify the separate ASCII and UTF-8 indexes|stores simultaneously as part
of a single update/add operation.

-- 
Eric A. Hall                                        http://www.ehsco.com/
Internet Core Protocols          http://www.oreilly.com/catalog/coreprot/

---

From: wessorh at ar.com (Rick Wesson)
Date: Thu Aug 28 00:03:49 2003

not a problem, its an implementation issue. just as whois  is served from
many different types data stores (mkdb, ldap, sql, gigabase) they all
implement the same publishing protocol.

CRISP isn't about updating its about publishing, updating is for the
implementations not IRIS.

-rick

On Wed, 27 Aug 2003, Eric A. Hall wrote:

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

---

From: ehall at ehsco.com (Eric A. Hall)
Date: Thu Aug 28 00:37:59 2003

on 8/27/2003 11:03 PM Rick Wesson wrote:

> not a problem, its an implementation issue. just as whois  is served
> from many different types data stores (mkdb, ldap, sql, gigabase) they
> all implement the same publishing protocol.
> 

I'm specifically referring to in-line updates. EG, user is the
verified/authenticated owner of the resource in question and needs to
change the phone number. This will require protocol support at the same
level as lookup and search.

It's not an implementation issue anyway -- that would mean having
different verbs and syntaxes for every server.

---

From: kent at songbird.com ([email-masked])
Date: Thu Aug 28 03:07:50 2003

On Wed, Aug 27, 2003 at 11:37:53PM -0500, Eric A. Hall wrote:
> I'm specifically referring to in-line updates.

As I understand Rick's point, support of updates, in-line or not, is not
a requirement, and, I suspect, lack of that ability is actually a
desirable feature.  Whois, and presumably it's replacement, is purely a
publishing mechanism.  If you add update mechanisms you inevitably
complicate the protocol far past what is either required or desired. 

-- 
Kent Crispin                               "Be good, and you will be
[email-masked],[email-masked]         lonesome."
p: +1 310 823 9358  f: +1 310 823 8649               -- Mark Twain

---

From: shane at ripe.net (Shane Kerr)
Date: Thu Aug 28 04:28:01 2003

> complicate the protocol far past what is either required or desired. 

I'll go further and say this is an anti-requirement for us.

-- 
Shane Kerr
RIPE NCC

---

From: ehall at ehsco.com (Eric A. Hall)
Date: Thu Aug 28 08:06:14 2003

> As I understand Rick's point, support of updates, in-line or not, is
> not a requirement, and, I suspect, lack of that ability is actually a 
> publishing mechanism.

There's a scale here.

Allowing the registry data for ~com to be updated is probably not
desirable. However, registrars should be able to do whatever they want,
including mail-from, https, or updates via CRISP if they want to offer
that option. The current requirements don't make that distinction.

Also, the current requirements are for domains and not the service as a
whole. Other uses in a directory service -- which is what we're going
after -- will absolutely have other requirements. EG, SIP phones need to
be able to update my profile in the directory once I authenticate is an
example of mandatory read-write support.

So like I said the first time, I'm curious what the plan is. At the very
least, read-write support should be an option for the registrars and
operators of domains, and its going to be mandatory anyway eventually.

---

From: anewton at ecotroph.net (Andrew Newton)
Date: Thu Aug 28 09:54:50 2003

From the charter:

> Provisioning of data into registry or registrar
> systems is likewise out of scope -- CRISP provides a uniform
> access to and view of data that may be held in disparate backend
> servers.

-andy

---

From: ehall at ehsco.com (Eric A. Hall)
Date: Thu Aug 28 10:04:29 2003

>>access to and view of data that may be held in disparate backend

Perhaps the charter and the IRIS specs need to s/directory/query

Directories are read-mostly, not read-only