Subject: [Ietf-not43] IRIS Open Issues

From: andy at hxr.us (Andrew Newton)
Date: Thu Nov 13 11:37:37 2003

The following are the items from the IRIS open issues presentation given
Wednesday during the working group meeting.  Please provide comments if
you have them.

AREG
o AREG has only been updated according to a couple of directed comments
on the list.
o Does not yet attempt to conform to
draft-ietf-crisp-internet-resource-number-req
     - Just a time/bandwidth issue

Resolutio Methods
o DREG
     - Defines top-down and bottom-up DNS tree walking
     - Good enough?
o AREG
     - Top-down and bottom-up reverse DNS tree walking
     - Given that reverse DNS tree does not always accurately represent
network boundaries, should we think about others?

Misc. Changes
o Side-effects of comments on -03
     - <iris:serializedEntity> goes away due to redefinition of 
<iris:entity>
     - Replaced by <iris:entity> with null 'authority' attribute content
o According to RFC 2396, IETF assigned URI's cannot have dashes
     - Therefore ?iris-beep? URI scheme is now ?iris.beep? according to
common practice

Host in DREG
o One implementer has noticed that the ipv4/v6 address elements are the
only ones inside a container.
o This is not consistent with the rest of <dreg:host> children.

Status in Domain
o New change to <sequence> forces server to sort them before sending them.
o Maybe it should be <choice minOccurs='0' maxOccurs='unbounded'>
     - With the addition of a boolean valued 'current' attribute on
<appliedDate>, this allows servers to convey the history of the domain
if they want.
     - Or simply specify that only one type of status element be used
(must be expressed in words... not possible in XML Schema).

(NOTE: I'll try to cover this in more detail in a separate email since
it is really asking for a choice.)

Draft Mechanics
o All four drafts need to have references split into normative/informative.
o Proper registration for the URN's in the 'ietf' NID.
o Otherwise ID-nits compliant.

-andy

---

From: davidb at verisignlabs.com (David Blacka)
Date: Thu Nov 13 12:02:26 2003

> o New change to <sequence> forces server to sort them before sending them.

This isn't a show-stopper.  It is just annoying.

> <appliedDate>, this allows servers to convey the history of the domain

Nothing else in CRISP has pointed toward using it to see historical data 
about a registration object.  I would be somewhat reluctant to start with 
this.

> (must be expressed in words... not possible in XML Schema).

To be clear, the way you represent an "unordered set" in XMLSchema is to 
create a sequence of choices.  When you do that, you make it impossible to 
enforce the property of uniqueness.  So you could have:

  <dreg:status>
     <dreg:active>some date</dreg:active>
     <dreg:registrarHold>some date</dreg:registrarHold>
     <dreg:active>some other date</dreg:active>
  </dreg:status>

-- 
David Blacka    <[email-masked]> 
Sr. Engineer    Verisign Applied Research

---

From: andy at hxr.us (Andrew Newton)
Date: Thu Nov 13 12:08:27 2003

> about a registration object.  I would be somewhat reluctant to start with 

Agreed.  I'm just throwing it out as a possible thing that could be done 
due to this change.  I'm not convinced of its usefulness.

> enforce the property of uniqueness.  So you could have:

Hence the use of RFC 2119 language to formalize it.

-andy

---

From: ggm at apnic.net (George Michaelson)
Date: Thu Nov 13 12:54:47 2003

> due to this change.  I'm not convinced of its usefulness.

In number registry space, it might help with people tracking potential hijacked
nets. We're considering some issues around mandatory change logging on top level
objects. Equally, this can be done offline, its more about information
management than lookup.

I think I have some problems conceptualizing what 'sort' means in some of these
contexts. If you mean 'by time' then the sort isn't on the status, its on the
date of the status. If there are other more complex sort orders, why isn't that
being done in the client?

-George