From davidb at verisignlabs.com Thu Oct 2 15:23:19 2003 From: davidb at verisignlabs.com (David Blacka) Date: Thu Oct 2 15:23:22 2003 Subject: [Ietf-not43] [ANN] new IRIS/DREG command line client available. Message-ID: <200310021523.19026.davidb@verisignlabs.com> I've written a command line client for IRIS/DREG in perl. It should be a bit easier to use and start faster than Pimmit's command line stuff. To get an idea of what it looks like, see the manpage: -- David Blacka Sr. Engineer Verisign Applied Research From April.Marine at nominum.com Thu Oct 2 17:26:31 2003 From: April.Marine at nominum.com (April Marine) Date: Thu Oct 2 17:26:34 2003 Subject: [Ietf-not43] Please welcome George! Message-ID: <20031002141940.V10372@shell-ng.nominum.com> I am very pleased to announce that CRISP has a new co-chair: George Michaelson. Ted Hardie will leave that role and take on the role of our Area Advisor in the IESG. I'm not sure this reduces the number of hats he wears, but possibly he'll have fewer dots on his badge. Many thanks to Ted for sheparding this group from its inception. There will of course be a transition period and Ted will never fully be free. Many thanks to George for agreeing to come on board! April CRISP Co-chair From anewton at ecotroph.net Thu Oct 9 16:17:55 2003 From: anewton at ecotroph.net (Andrew Newton) Date: Thu Oct 9 15:44:45 2003 Subject: [Ietf-not43] Moving forward to -04 Message-ID: <3F85C273.2070801@ecotroph.net> In the interest of moving the IRIS drafts to -04, the chairs have asked me to put together a list of the items that came from the discussions during the consensus period. This enumeration will allow a closer re-examination of some the proposed changes that may not have been possible during the heat of the consensus period. I will be sending 3 separate emails for the purposes of discussion threads. The topics will be: items proposed with no objections, item discussed with consensus, and items discussed with no consensus. If you find that I have miscategorized an item, misstated a proposal, or even omitted anything, please let it be known. -andy From anewton at ecotroph.net Thu Oct 9 16:19:17 2003 From: anewton at ecotroph.net (Andrew Newton) Date: Thu Oct 9 15:46:08 2003 Subject: [Ietf-not43] towards -04: Changes With No Consensus Message-ID: <3F85C2C5.4080703@ecotroph.net> 1) A generic query syntax. 2) Handles that are universal in and of themselves (such as a universsal email-like syntax). 3) Suggestion that the protocol should use a single UTF-8 syntax for all domain-related queries. 4) Per attribute fetches. From anewton at ecotroph.net Thu Oct 9 16:22:36 2003 From: anewton at ecotroph.net (Andrew Newton) Date: Thu Oct 9 15:49:28 2003 Subject: [Ietf-not43] towards -04: Changes Where Consensus Was Found Message-ID: <3F85C38C.1070709@ecotroph.net> 1) should specify that the input is to be nameprepped and this search should include an exact-match feature. 2) Add an entity class for IDN's and specify that the expected input is nameprepped. 3) Change the number of email addresses, phone numbers, and fax numbers to unbouned. 4) Add a sip address (also unbounded). 5) Add a that can focus on a contacts role. Here's a question. We already have . Should we merge the two is consideration that a registrant is just another type of role against a domain? 6) Specify that domain parts of email addresses should be namepreppred. 7) Offer an element allowing UTF-8 representations of email addresses (also to be unbounded, I assume). 8) Add an appendix in DREG for guidelines on localization. 9) Collapse the objects into the objects and allow for same-type references (in other words, a element inside that points to one or more objects). 10) Change the status codes in the following way: - They are contained within a parent element. - Add a and status values. - Allow the status elements to have an optional child. - Make it a sequence and not a choice allowing the registry to define the mutual exclusion of status values. From anewton at ecotroph.net Thu Oct 9 16:26:01 2003 From: anewton at ecotroph.net (Andrew Newton) Date: Thu Oct 9 15:52:51 2003 Subject: [Ietf-not43] towards -04: Changes With No Objection Message-ID: <3F85C459.3050705@ecotroph.net> 1) Add elements in object to hold a list of base domains. This better aids the user in understanding the responsibilities of a registry/registrar. 2) Create an attribute group to hold privacy attributes to satisfy the new privacy tagging requirement. 3) Add an to the object. 4) Place the element in the search set before the element. This allows servers doing event driven parsing (such as SAX) the ability to evaluate the bag and take appropriate action before executing the query. 5) Place the element in the response as a peer to so that they may be normalized across all result sets, not just results in a particular result set. 6) Change the control/reaction interactions to be passed in/out with the queries and results. The separate protocol interaction causes the server to keep state above the transport layer. This also simplifies the code paths on the server. 7) Relax the TLS server authentication rules to be more like those found in RFC 2595. This will allow the reuse of certificates purchased/acquired for other services. 8) Change the element so that it is identified by a 'referantType' attribute instead of the element name. This allows a server to suggest to the client what type of object to expect when following the reference, and allows derivation of the element so that the role is the element name (the benefit being that a client doesn't have to look to the parent element to determine the role). From chris.ambler at enom.com Mon Oct 13 19:56:12 2003 From: chris.ambler at enom.com (Chris Ambler) Date: Mon Oct 13 19:56:17 2003 Subject: [Ietf-not43] Using element for WHOIS implementation Message-ID: I'm working on a SOAP client for eNom's WHOIS implementation. At Rick Wesson's encouragement, we're going to use the element in IRIS-dreg as the standard XML return type. The problem I'm having, however, is in determining what to return when a WHOIS query has an error, either because of an internal failure, or the domain doesn't exist. Since our SOAP output is strongly typed, I have to return a element - but there doesn't seem to be a facility for returning an error. I could, of course, declare myself a new element that contains both error information and a single element, but that's breaking the spirit of using an established element, so I'd prefer to avoid that. Any suggestions? Am I overlooking something obvious again? :-) Christopher -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.verisignlabs.com/pipermail/ietf-not43/attachments/20031013/4da08e28/attachment.htm From anewton at ecotroph.net Mon Oct 13 20:13:25 2003 From: anewton at ecotroph.net (Andrew Newton) Date: Mon Oct 13 20:23:06 2003 Subject: [Ietf-not43] Using element for WHOIS implementation In-Reply-To: References: Message-ID: <3F8B3FA5.5020508@ecotroph.net> The errors are in the IRIS core schema. > name="insufficientResources" > type="iris:codeType" /> > name="invalidName" > type="iris:codeType" /> > name="invalidSearch" > type="iris:codeType" /> > name="limitExceeded" > type="iris:codeType" /> > name="nameNotFound" > type="iris:codeType" /> > name="permissionDenied" > type="iris:codeType" /> > name="bagUnrecognized" > type="iris:codeType" /> > name="bagUnacceptable" > type="iris:codeType" /> > name="bagRefused" > type="iris:codeType" /> > ref="iris:genericCode"/> -andy Chris Ambler wrote: > I?m working on a SOAP client for eNom?s WHOIS implementation. At Rick > Wesson?s encouragement, we?re going to use the element in > IRIS-dreg as the standard XML return type. > > > > The problem I?m having, however, is in determining what to return when a > WHOIS query has an error, either because of an internal failure, or the > domain doesn?t exist. Since our SOAP output is strongly typed, I have to > return a element ? but there doesn?t seem to be a facility for > returning an error. > > > > I could, of course, declare myself a new element that contains both > error information and a single element, but that?s breaking the > spirit of using an established element, so I?d prefer to avoid that. > > > > Any suggestions? Am I overlooking something obvious again? J > > > > Christopher > > > ------------------------------------------------------------------------ > > _______________________________________________ > Ietf-not43 mailing list > Ietf-not43@lists.verisignlabs.com > https://lists.verisignlabs.com/mailman/listinfo/ietf-not43 From chris.ambler at enom.com Mon Oct 13 20:26:05 2003 From: chris.ambler at enom.com (Chris Ambler) Date: Mon Oct 13 20:26:09 2003 Subject: [Ietf-not43] RE: chris.ambler@enom.com - Email found in subject - Re: [Ietf-no t43] Using element for WHOIS implementation Message-ID: Right, I saw that. But let me reiterate - since I'm using SOAP, my return value is strongly-typed to be of the element. Not any of the error elements. I can't choose which one to return. I have to return a element every time. So I can return a element and set the element to some known invalid value, such as "eW-err::[error code]/[error description]" or some such, and leave the rest nil. But I was hoping that there might be some way to return an error in the tag for those programs that return strongly-typed elements. Christopher >---------- >From: Andrew Newton[SMTP:ANEWTON@ECOTROPH.NET] >Sent: Monday, October 13, 2003 5:13:25 PM >To: Chris Ambler >Cc: ietf-not43@lists.verisignlabs.com >Subject: chris.ambler@enom.com - Email found in subject - Re: [Ietf-not43] Using element for WHOIS implementation >Auto forwarded by a Rule > The errors are in the IRIS core schema. > name="insufficientResources" > type="iris:codeType" /> > name="invalidName" > type="iris:codeType" /> > name="invalidSearch" > type="iris:codeType" /> > name="limitExceeded" > type="iris:codeType" /> > name="nameNotFound" > type="iris:codeType" /> > name="permissionDenied" > type="iris:codeType" /> > name="bagUnrecognized" > type="iris:codeType" /> > name="bagUnacceptable" > type="iris:codeType" /> > name="bagRefused" > type="iris:codeType" /> > ref="iris:genericCode"/> -andy Chris Ambler wrote: > I'm working on a SOAP client for eNom's WHOIS implementation. At Rick > Wesson's encouragement, we're going to use the element in > IRIS-dreg as the standard XML return type. > > > > The problem I'm having, however, is in determining what to return when a > WHOIS query has an error, either because of an internal failure, or the > domain doesn't exist. Since our SOAP output is strongly typed, I have to > return a element - but there doesn't seem to be a facility for > returning an error. > > > > I could, of course, declare myself a new element that contains both > error information and a single element, but that's breaking the > spirit of using an established element, so I'd prefer to avoid that. > > > > Any suggestions? Am I overlooking something obvious again? J > > > > Christopher > > > ------------------------------------------------------------------------ > > _______________________________________________ > Ietf-not43 mailing list > Ietf-not43@lists.verisignlabs.com > https://lists.verisignlabs.com/mailman/listinfo/ietf-not43 From wessorh at ar.com Mon Oct 13 20:42:38 2003 From: wessorh at ar.com (Rick Wesson) Date: Mon Oct 13 20:43:42 2003 Subject: [Ietf-not43] RE: chris.ambler@enom.com - Email found in subject - Re: [Ietf-no t43] Using element for WHOIS implementation In-Reply-To: References: Message-ID: <20031013174238.508df31e.wessorh@ar.com> Chris, wouldn't another option be to return a SOAP exception? -rick On Mon, 13 Oct 2003 17:26:05 -0700 Chris Ambler wrote: > Right, I saw that. But let me reiterate - since I'm using SOAP, my return > value is strongly-typed to be of the element. Not any of the error > elements. I can't choose which one to return. I have to return a > element every time. > > So I can return a element and set the element to some > known invalid value, such as "eW-err::[error code]/[error description]" or > some such, and leave the rest nil. But I was hoping that there might be some > way to return an error in the tag for those programs that return > strongly-typed elements. > > Christopher > > > >---------- > >From: Andrew Newton[SMTP:ANEWTON@ECOTROPH.NET] > >Sent: Monday, October 13, 2003 5:13:25 PM > >To: Chris Ambler > >Cc: ietf-not43@lists.verisignlabs.com > >Subject: chris.ambler@enom.com - Email found in subject - Re: > [Ietf-not43] Using element for WHOIS implementation > >Auto forwarded by a Rule > > > The errors are in the IRIS core schema. > > > > name="insufficientResources" > > type="iris:codeType" /> > > > name="invalidName" > > type="iris:codeType" /> > > > name="invalidSearch" > > type="iris:codeType" /> > > > name="limitExceeded" > > type="iris:codeType" /> > > > name="nameNotFound" > > type="iris:codeType" /> > > > name="permissionDenied" > > type="iris:codeType" /> > > > name="bagUnrecognized" > > type="iris:codeType" /> > > > name="bagUnacceptable" > > type="iris:codeType" /> > > > name="bagRefused" > > type="iris:codeType" /> > > > ref="iris:genericCode"/> > > -andy > > Chris Ambler wrote: > > I'm working on a SOAP client for eNom's WHOIS implementation. At Rick > > Wesson's encouragement, we're going to use the element in > > IRIS-dreg as the standard XML return type. > > > > > > > > The problem I'm having, however, is in determining what to return when a > > WHOIS query has an error, either because of an internal failure, or the > > domain doesn't exist. Since our SOAP output is strongly typed, I have to > > return a element - but there doesn't seem to be a facility for > > returning an error. > > > > > > > > I could, of course, declare myself a new element that contains both > > error information and a single element, but that's breaking the > > spirit of using an established element, so I'd prefer to avoid that. > > > > > > > > Any suggestions? Am I overlooking something obvious again? J > > > > > > > > Christopher > > > > > > ------------------------------------------------------------------------ > > > > _______________________________________________ > > Ietf-not43 mailing list > > Ietf-not43@lists.verisignlabs.com > > https://lists.verisignlabs.com/mailman/listinfo/ietf-not43 > > _______________________________________________ > Ietf-not43 mailing list > Ietf-not43@lists.verisignlabs.com > https://lists.verisignlabs.com/mailman/listinfo/ietf-not43 From anewton at ecotroph.net Mon Oct 13 20:40:44 2003 From: anewton at ecotroph.net (Andrew Newton) Date: Mon Oct 13 20:50:21 2003 Subject: [Ietf-not43] RE: chris.ambler@enom.com - Email found in subject - Re: [Ietf-no t43] Using element for WHOIS implementation In-Reply-To: References: Message-ID: <3F8B460C.5080302@ecotroph.net> Chris Ambler wrote: > So I can return a element and set the element to some > known invalid value, such as "eW-err::[error code]/[error description]" or > some such, and leave the rest nil. But I was hoping that there might be some > way to return an error in the tag for those programs that return > strongly-typed elements. That would work, but I guess it's not pretty. You could return an iris-core element. That would give you all the error codes and the normalization and data separation. If you wanted to narrow it down a little further, you could return an element of the type "resultSetType" (e.g. ) from iris-core. -andy From anewton at ecotroph.net Mon Oct 13 20:41:59 2003 From: anewton at ecotroph.net (Andrew Newton) Date: Mon Oct 13 20:51:35 2003 Subject: [Ietf-not43] RE: chris.ambler@enom.com - Email found in subject - Re: [Ietf-no t43] Using element for WHOIS implementation In-Reply-To: <20031013174238.508df31e.wessorh@ar.com> References: <20031013174238.508df31e.wessorh@ar.com> Message-ID: <3F8B4657.3040704@ecotroph.net> Rick Wesson wrote: > Chris, > > wouldn't another option be to return a SOAP exception? > > -rick Forget my suggestion, this sounds MUCH better. Thanks Rick. -andy From chris.ambler at enom.com Mon Oct 13 20:56:35 2003 From: chris.ambler at enom.com (Chris Ambler) Date: Mon Oct 13 20:56:42 2003 Subject: [Ietf-not43] RE: chris.ambler@enom.com - Email found in subje ct - Re: [Ietf-no t43] Using element for WHOIS implementation Message-ID: Absolutely. And I'd define an exception type to hold the data. Call it SOAPWHOISException, and publish the definition for those who would consume it. Christopher -----Original Message----- From: Rick Wesson [mailto:wessorh@ar.com] Sent: Monday, October 13, 2003 5:43 PM To: Chris Ambler Cc: ietf-not43@lists.verisignlabs.com Subject: Re: [Ietf-not43] RE: chris.ambler@enom.com - Email found in subject - Re: [Ietf-no t43] Using element for WHOIS implementation Chris, wouldn't another option be to return a SOAP exception? -rick On Mon, 13 Oct 2003 17:26:05 -0700 Chris Ambler wrote: > Right, I saw that. But let me reiterate - since I'm using SOAP, my return > value is strongly-typed to be of the element. Not any of the error > elements. I can't choose which one to return. I have to return a > element every time. > > So I can return a element and set the element to some > known invalid value, such as "eW-err::[error code]/[error description]" or > some such, and leave the rest nil. But I was hoping that there might be some > way to return an error in the tag for those programs that return > strongly-typed elements. > > Christopher > > > >---------- > >From: Andrew Newton[SMTP:ANEWTON@ECOTROPH.NET] > >Sent: Monday, October 13, 2003 5:13:25 PM > >To: Chris Ambler > >Cc: ietf-not43@lists.verisignlabs.com > >Subject: chris.ambler@enom.com - Email found in subject - Re: > [Ietf-not43] Using element for WHOIS implementation > >Auto forwarded by a Rule > > > The errors are in the IRIS core schema. > > > > name="insufficientResources" > > type="iris:codeType" /> > > > name="invalidName" > > type="iris:codeType" /> > > > name="invalidSearch" > > type="iris:codeType" /> > > > name="limitExceeded" > > type="iris:codeType" /> > > > name="nameNotFound" > > type="iris:codeType" /> > > > name="permissionDenied" > > type="iris:codeType" /> > > > name="bagUnrecognized" > > type="iris:codeType" /> > > > name="bagUnacceptable" > > type="iris:codeType" /> > > > name="bagRefused" > > type="iris:codeType" /> > > > ref="iris:genericCode"/> > > -andy > > Chris Ambler wrote: > > I'm working on a SOAP client for eNom's WHOIS implementation. At Rick > > Wesson's encouragement, we're going to use the element in > > IRIS-dreg as the standard XML return type. > > > > > > > > The problem I'm having, however, is in determining what to return when a > > WHOIS query has an error, either because of an internal failure, or the > > domain doesn't exist. Since our SOAP output is strongly typed, I have to > > return a element - but there doesn't seem to be a facility for > > returning an error. > > > > > > > > I could, of course, declare myself a new element that contains both > > error information and a single element, but that's breaking the > > spirit of using an established element, so I'd prefer to avoid that. > > > > > > > > Any suggestions? Am I overlooking something obvious again? J > > > > > > > > Christopher > > > > > > ------------------------------------------------------------------------ > > > > _______________________________________________ > > Ietf-not43 mailing list > > Ietf-not43@lists.verisignlabs.com > > https://lists.verisignlabs.com/mailman/listinfo/ietf-not43 > > _______________________________________________ > Ietf-not43 mailing list > Ietf-not43@lists.verisignlabs.com > https://lists.verisignlabs.com/mailman/listinfo/ietf-not43 From chris.ambler at enom.com Tue Oct 14 00:14:47 2003 From: chris.ambler at enom.com (Chris Ambler) Date: Tue Oct 14 00:15:01 2003 Subject: [Ietf-not43] Constructing an all-inclusive response Message-ID: One of the goals of the XML whois format project being developed is to be able to encapsulate all of the data needed for a WHOIS response into a single XML output. As such, the elements and arguments of the element in dreg are a superset of what we need. That's perfect, as we can leave those elements that we don't need either nil, or simply unspecified (where allowed). In looking at the specification, I note that entities are used for most items, like contacts, nameservers, and the like. They're specified using handles in the examples (in the entityName argument). In the WHOIS realm, these handles will be different for every registrar, if not completely nonexistent. What we need to do is be able to specify all entities within the response, in full, in a registrar-agnostic fashion. It appears to me that the only way to do this is to put those records within the element, which seems to eliminate the usefulness of elements like , and the like. It seems non-optimal to have an entity with the elements, specify an entityName attribute (using a registrar-specific handle or, in the case where one doesn't exist, generate a unique ID), and then have to make another query to resolve it. I note, in one of the examples, that such an entity is specified for a element, and then codified in a element within the element. Is this how it is supposed to be done when the return data needs to be complete? That adds a lot of processing on the consumer side. And in the same example, the entity elements for name servers and the element aren't supplied in full at all. Is one expected to make another query for them based on the contents of the entityName argument? For WHOIS, this isn't really an option. Why can't a (or any number of) element(s) be contained within or or other such elements? Why must one use elements when the more specific elements are expected? Once again, there is always the strong possibility that I'm missing the obvious in my haste to both grok the specification and code an implementation simultaneously. Christopher From anewton at ecotroph.net Tue Oct 14 08:00:35 2003 From: anewton at ecotroph.net (Andrew Newton) Date: Tue Oct 14 08:10:19 2003 Subject: [Ietf-not43] Constructing an all-inclusive response In-Reply-To: References: Message-ID: <3F8BE563.8010603@ecotroph.net> Chris Ambler wrote: > One of the goals of the XML whois format project being developed is to be > able to encapsulate all of the data needed for a WHOIS response into a > single XML output. As such, the elements and arguments of the > element in dreg are a superset of what we need. That's perfect, as we can > leave those elements that we don't need either nil, or simply unspecified > (where allowed). Is this a port 43 nicname/whois thing? Or are you using the term "whois" in a more general meaning (i.e. talking about as a service rather than a protocol)? > In looking at the specification, I note that entities are used for most > items, like contacts, nameservers, and the like. They're specified using > handles in the examples (in the entityName argument). In the WHOIS realm, > these handles will be different for every registrar, if not completely > nonexistent. What we need to do is be able to specify all entities within > the response, in full, in a registrar-agnostic fashion. Yes, the handles are most likely to be different for every registry and registrar. I'm not sure about non-existent. Most of the entities should have natural keys at the very least (i.e. domain name for and host name or IP address for ). Only seems to be lacking one, and there a simple synthetic key can be created. Section 3.4 lists the different entity classes that may be used. > It appears to me that the only way to do this is to put those records within > the element, which seems to eliminate the usefulness of > elements like , and the like. Population of the additional section is dependent on the operator. It is not required. When populated, it does stop a requery by the client. For the client, it gives the distinction between the data queried and the data referenced by the data queried. This is an important distinction when dealing with non-text UI's. > Why can't a (or any number of) element(s) be contained within > or or other such elements? Why must one use > elements when the more specific elements are expected? It is done primarily for normalization reasons. One of the early versions of IRIS (probably -00) did exactly this, and I quickly discovered what a pain it was to deal with denormalized entities on the client side. I got to strip out a lot of code for -03 because of this. Admittedly, this may seem non-obvious at first. But when you get into cases where one contact object is referenced by multiple domains or where the data must be juggled in the UI (such as in a tree widget), this is extremely beneficial and stops the client from having to intuit the return values. -andy From chris.ambler at enom.com Tue Oct 14 12:10:05 2003 From: chris.ambler at enom.com (Chris Ambler) Date: Tue Oct 14 12:10:09 2003 Subject: [Ietf-not43] Constructing an all-inclusive response Message-ID: Andrew Newton Said... >Is this a port 43 nicname/whois thing? Or are you using the term >"whois" in a more general meaning (i.e. talking about as a service >rather than a protocol)? It's a port 43 thing, but more. In essence, we're standardizing on the element as an inter-registrar format for exchanging WHOIS data to facilitate transfers. We're making that available, on a whitelisted basis, to other registrars. Some of us are implementing a /xml switch in our port 43, and some of us are also making the data available via SOAP web services. As part of this, at least here at eNom, we're also making all of our public interfaces consume the web service as a central point of data before reformatting the output. So, for example, our old port 43 code had lots of database calls to gather WHOIS data. Now, it simply calls a SOAP web service and takes the XML output, routes it through an XSLT and spits it out. Much more efficient, and much easier to maintain. So the key is that all data needed must be encapsulated in the element without the need for another trip to the service. Hence, the issue. I hope that gives you a clear idea of what we're doing. >Yes, the handles are most likely to be different for every registry and >registrar. I'm not sure about non-existent. The point being that they're irrelevant for WHOIS output. We want to output the actual data, not the handles. Sure, we might include the handle for completeness' sake, but that's additional. >> It appears to me that the only way to do this is to put those records >within >> the element, which seems to eliminate the usefulness of >> elements like , and the like. > >Population of the additional section is dependent on the operator. It >is not required. When populated, it does stop a requery by the client. Which is the goal, yes. So it seems to me that what I need to do is include the entities as codified, but then also include the actual data in the element, and then write my consumption code such that the entity is used simply to identify which element in the area I should use for the data. The unfortunate part is that this creates a lot of extra work for this particular application (which is a non-trivial use of the standard). Would it be possible to define a schema whereby entities can be replaced by the actual elements that they would reference? An "I promise that there are no circular references and you need not go back to the service for more data" schema, if you will? Perhaps an attribute on the tag called "self-contained" or some such? Failing that, could anyone hack an example of a self-contained return? How would that be constructed? Christopher From anewton at ecotroph.net Tue Oct 14 13:03:55 2003 From: anewton at ecotroph.net (Andrew Newton) Date: Tue Oct 14 12:30:09 2003 Subject: [Ietf-not43] Constructing an all-inclusive response In-Reply-To: References: Message-ID: <3F8C2C7B.7090201@ecotroph.net> Chris Ambler wrote: > The unfortunate part is that this creates a lot of extra work for this > particular application (which is a non-trivial use of the standard). It seems fairly trivial to use entity-class + entity-name (or some combination of authority + registry-type + ... depending on your scope) as a key for a hash table of the entities. > Would it be possible to define a schema whereby entities can be replaced by > the actual elements that they would reference? An "I promise that there are > no circular references and you need not go back to the service for more > data" schema, if you will? In my opinion, this is not a good direction. Database practices generally tells us that normalization is a good thing. What you are suggesting makes the relationships less clear when an entity appears multiple times in a response. -andy From chris.ambler at enom.com Tue Oct 14 12:34:51 2003 From: chris.ambler at enom.com (Chris Ambler) Date: Tue Oct 14 12:35:01 2003 Subject: [Ietf-not43] Constructing an all-inclusive response Message-ID: >It seems fairly trivial to use entity-class + entity-name (or some >combination of authority + registry-type + ... depending on your scope) >as a key for a hash table of the entities. Could I trouble you for an example? I'm unclear on how this would look. >> Would it be possible to define a schema whereby entities can be replaced >by >> the actual elements that they would reference? An "I promise that there >are >> no circular references and you need not go back to the service for more >> data" schema, if you will? > >In my opinion, this is not a good direction. Database practices >generally tells us that normalization is a good thing. What you are >suggesting makes the relationships less clear when an entity appears >multiple times in a response. I agree, of course. I'm looking towards simplicity over form. Indeed, the same entity is very often used for multiple contacts. So it would be very simple to just inject duplicate elements. But yes, that's not properly normalized, so I can't argue with you. But then that means that I put the entity references in there as expected, use actual or contrived IDs (which will be used solely to reference the actual data), and include the actual data as part of the payload. That's where I'm somewhat unclear. I don't fully grok how or where to properly include the actual data so that a element returned is fully-self-contained. Adult supervision? Christopher From chris.ambler at enom.com Tue Oct 14 19:10:09 2003 From: chris.ambler at enom.com (Chris Ambler) Date: Tue Oct 14 19:10:14 2003 Subject: [Ietf-not43] From answer to domain Message-ID: I don't see how one gets a element inside of an element. I see that the element has an entity array, but that array is for entities, not their values. would be a value, and I can't see where it would be inserted. Yet the examples have within What am I missing? Christopher -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.verisignlabs.com/pipermail/ietf-not43/attachments/20031014/1cf5e8c0/attachment.htm From anewton at ecotroph.net Tue Oct 14 20:50:27 2003 From: anewton at ecotroph.net (Andrew Newton) Date: Tue Oct 14 20:47:41 2003 Subject: [Ietf-not43] From answer to domain In-Reply-To: References: Message-ID: <3F8C99D3.1070102@ecotroph.net> It is actually : > name="domain" > type="dreg:domainType" > substitutionGroup="iris:result" /> is a derivation of . Keep in mind that xsd's are only the formal definition of the schema. Implementations are free to use other validation methods so long as they accomplish the same task. -andy Chris Ambler wrote: > I don?t see how one gets a element inside of an > element. I see that the element has an entity array, but that > array is for entities, not their values. would be a value, > and I can?t see where it would be inserted. > > > > Yet the examples have within > > > > What am I missing? > > > > Christopher > > > ------------------------------------------------------------------------ > > _______________________________________________ > Ietf-not43 mailing list > Ietf-not43@lists.verisignlabs.com > https://lists.verisignlabs.com/mailman/listinfo/ietf-not43 From chris.ambler at enom.com Wed Oct 15 13:08:48 2003 From: chris.ambler at enom.com (Chris Ambler) Date: Wed Oct 15 13:08:58 2003 Subject: [Ietf-not43] From answer to domain Message-ID: > is a derivation of . > >Keep in mind that xsd's are only the formal definition of the schema. >Implementations are free to use other validation methods so long as they >accomplish the same task. Ah, that makes more sense. So, in the XSD, it is codified that the Item element of the answer element, being of type resultType, may be serialized as a simpleEntityType, limitsType or serviceIdentificationType. I added the allowance such that it could also be serialized as a domainType, and all works well. Now, let's make sure I have this clear: Once I fill in the domain element with all of my entities, I then put the actual elements that the entities reference in the additional element, ensuring that the entityName fields match. Correct? Heretical question: if the XSD is just a suggestion, as you intimate, what prevents me from breaking normalization and adding the allowance that, for example, the technicalContacts element of the domain element may contain, in addition to an iris:entity element, a contact element? Okay, let's say I don't do that (because your objection will be, "yes, that breaks normalization, and we'd prefer that not happen), but put the actual element in the additional element... is there a procedure whereby I can push my XSD back out as the "official XSD for using the dreg:domain inside of an answer element for the purpose of registrar WHOIS transmission?" or some such? The goal being to publish that XSD as well as my sample code when we're all done so other registrars can participate (yes, I just got the OK from eNom to push the code and spec for this out into the public once it's working). Christopher From davidb at verisignlabs.com Wed Oct 15 14:04:37 2003 From: davidb at verisignlabs.com (David Blacka) Date: Wed Oct 15 14:04:42 2003 Subject: [Ietf-not43] From answer to domain In-Reply-To: Message-ID: <0A2870C6-FF3A-11D7-B24F-003065E054B6@verisignlabs.com> On Wednesday, October 15, 2003, at 01:08 PM, Chris Ambler wrote: > Heretical question: if the XSD is just a suggestion, as you intimate, > what > prevents me from breaking normalization and adding the allowance that, > for > example, the technicalContacts element of the domain element may > contain, in > addition to an iris:entity element, a contact element? > > Okay, let's say I don't do that (because your objection will be, "yes, > that > breaks normalization, and we'd prefer that not happen), but put the > actual > element in the additional element... is there a procedure whereby I > can push > my XSD back out as the "official XSD for using the dreg:domain inside > of an > answer element for the purpose of registrar WHOIS transmission?" or > some > such? I might be misunderstanding this whole conversation, but it seems to me that you are trying to use the IRIS/DREG1 schema for some non-IRIS/DREG1 purpose, and that you are having some difficulties because of this. Is the goal to create a WHOIS interchange format that will interoperate with CRISP, or is this an independent effort? (By interoperate, I am thinking that there may be a desire for a registrar to use one of these files as the data source for an IRIS/DREG1 server). If this is an independent effort, then you should just be using the DREG1 schema as a starting point. The DREG1 schema was designed in the context of the IRIS architecture. If that architecture isn't there, then the schema isn't going to be ideal. In that case, you may as well as create your own (albeit similar) schema. If it isn't an independent effort, then we need to make sure we understand how your efforts and IRIS need to interoperate. The schemas are not set in stone, but we need to understand the problems before we can judge what changes (if any) need to be made to the schemas. -- David Blacka Sr. Engineer Verisign Applied Research From chris.ambler at enom.com Wed Oct 15 14:25:12 2003 From: chris.ambler at enom.com (Chris Ambler) Date: Wed Oct 15 14:25:21 2003 Subject: [Ietf-not43] From answer to domain Message-ID: A small bit of history - Rick Wesson published a draft a couple of years ago with a simple XML format for WHOIS exchange. Essentially, an XML encapsulation of all of the stuff you'd want to see in WHOIS output. I took that draft and changed it to support what we need today. Rick took a look at it and said, "Hey, dreg has all of this stuff - why not just use that rather than make a whole new format?" That made sense to me, as the dreg schema does, indeed, have everything we need. The solution is a constrained one. We want to just emit domain information, and we want to do it in a single transmission - no extra trips to the server to resolve IDs or handles. As such, the solution seems to be to emit a resultSet with an answer containing a single domain, and an additional element with the contacts and nameservers and such in the same resultSet. The goal here is to create a WHOIS interchange format. Period. At Rick's urging, we're using dreg instead of something new, simply because they'd be, essentially, the same thing. The only difficulty here is in getting the data into a single transmission, which is made slightly challenging because of the normalization issue. But including the elements in the additional element should solve this. So the fact that we don't re-invent the wheel should mean that this makes sense then and there. As for the future, it allows us to be open to more of the features for this and future projects, and to more easily integrate our WHOIS output with other, larger IRIS-based projects. No? Christopher -----Original Message----- From: David Blacka [mailto:davidb@verisignlabs.com] Sent: Wednesday, October 15, 2003 11:05 AM To: Chris Ambler Cc: ietf-not43@lists.verisignlabs.com Subject: Re: [Ietf-not43] From answer to domain On Wednesday, October 15, 2003, at 01:08 PM, Chris Ambler wrote: > Heretical question: if the XSD is just a suggestion, as you intimate, > what > prevents me from breaking normalization and adding the allowance that, > for > example, the technicalContacts element of the domain element may > contain, in > addition to an iris:entity element, a contact element? > > Okay, let's say I don't do that (because your objection will be, "yes, > that > breaks normalization, and we'd prefer that not happen), but put the > actual > element in the additional element... is there a procedure whereby I > can push > my XSD back out as the "official XSD for using the dreg:domain inside > of an > answer element for the purpose of registrar WHOIS transmission?" or > some > such? I might be misunderstanding this whole conversation, but it seems to me that you are trying to use the IRIS/DREG1 schema for some non-IRIS/DREG1 purpose, and that you are having some difficulties because of this. Is the goal to create a WHOIS interchange format that will interoperate with CRISP, or is this an independent effort? (By interoperate, I am thinking that there may be a desire for a registrar to use one of these files as the data source for an IRIS/DREG1 server). If this is an independent effort, then you should just be using the DREG1 schema as a starting point. The DREG1 schema was designed in the context of the IRIS architecture. If that architecture isn't there, then the schema isn't going to be ideal. In that case, you may as well as create your own (albeit similar) schema. If it isn't an independent effort, then we need to make sure we understand how your efforts and IRIS need to interoperate. The schemas are not set in stone, but we need to understand the problems before we can judge what changes (if any) need to be made to the schemas. -- David Blacka Sr. Engineer Verisign Applied Research From hardie at qualcomm.com Wed Oct 15 14:42:47 2003 From: hardie at qualcomm.com (hardie@qualcomm.com) Date: Wed Oct 15 14:42:56 2003 Subject: [Ietf-not43] From answer to domain In-Reply-To: References: Message-ID: As I read the charter, this work is out of scope for CRISP. Note this line in particular: "Backwards compatibility with existing administrative directory services such as WHOIS is not a goal of this effort." I recognize that what you are trying to do is a bit closer to "make WHOIS forward compatible with CRISP", but I think the same logic applies. The group has defined a set of requirements, and it is pretty clear that this work does not meet those requirements. This does not mean I want to discourage you from this work, but I would like you to distinguish it from CRISP. One way to do that might be to set up a separate mailing list and provide a pointer to this list describing the list's purpose; you might also wish to talk to the DREG schema authors directly. regards, Ted Hardie At 11:25 AM -0700 10/15/2003, Chris Ambler wrote: >A small bit of history - Rick Wesson published a draft a couple of years ago >with a simple XML format for WHOIS exchange. Essentially, an XML >encapsulation of all of the stuff you'd want to see in WHOIS output. I took >that draft and changed it to support what we need today. Rick took a look at >it and said, "Hey, dreg has all of this stuff - why not just use that rather >than make a whole new format?" That made sense to me, as the dreg schema >does, indeed, have everything we need. > >The solution is a constrained one. We want to just emit domain information, >and we want to do it in a single transmission - no extra trips to the server >to resolve IDs or handles. > >As such, the solution seems to be to emit a resultSet with an answer >containing a single domain, and an additional element with the contacts and >nameservers and such in the same resultSet. > >The goal here is to create a WHOIS interchange format. Period. At Rick's >urging, we're using dreg instead of something new, simply because they'd be, >essentially, the same thing. The only difficulty here is in getting the data >into a single transmission, which is made slightly challenging because of >the normalization issue. But including the elements in the additional >element should solve this. > >So the fact that we don't re-invent the wheel should mean that this makes >sense then and there. As for the future, it allows us to be open to more of >the features for this and future projects, and to more easily integrate our >WHOIS output with other, larger IRIS-based projects. No? > >Christopher > >-----Original Message----- >From: David Blacka [mailto:davidb@verisignlabs.com] >Sent: Wednesday, October 15, 2003 11:05 AM >To: Chris Ambler >Cc: ietf-not43@lists.verisignlabs.com >Subject: Re: [Ietf-not43] From answer to domain > > >On Wednesday, October 15, 2003, at 01:08 PM, Chris Ambler wrote: > >> Heretical question: if the XSD is just a suggestion, as you intimate, >> what >> prevents me from breaking normalization and adding the allowance that, >> for >> example, the technicalContacts element of the domain element may >> contain, in >> addition to an iris:entity element, a contact element? >> >> Okay, let's say I don't do that (because your objection will be, "yes, >> that >> breaks normalization, and we'd prefer that not happen), but put the >> actual >> element in the additional element... is there a procedure whereby I >> can push >> my XSD back out as the "official XSD for using the dreg:domain inside >> of an >> answer element for the purpose of registrar WHOIS transmission?" or >> some >> such? > >I might be misunderstanding this whole conversation, but it seems to me >that you are trying to use the IRIS/DREG1 schema for some >non-IRIS/DREG1 purpose, and that you are having some difficulties >because of this. > >Is the goal to create a WHOIS interchange format that will interoperate >with CRISP, or is this an independent effort? (By interoperate, I am >thinking that there may be a desire for a registrar to use one of these >files as the data source for an IRIS/DREG1 server). > >If this is an independent effort, then you should just be using the >DREG1 schema as a starting point. The DREG1 schema was designed in the >context of the IRIS architecture. If that architecture isn't there, >then the schema isn't going to be ideal. In that case, you may as well >as create your own (albeit similar) schema. > >If it isn't an independent effort, then we need to make sure we >understand how your efforts and IRIS need to interoperate. The schemas >are not set in stone, but we need to understand the problems before we >can judge what changes (if any) need to be made to the schemas. > >-- >David Blacka >Sr. Engineer Verisign Applied Research >_______________________________________________ >Ietf-not43 mailing list >Ietf-not43@lists.verisignlabs.com >https://lists.verisignlabs.com/mailman/listinfo/ietf-not43 From chris.ambler at enom.com Wed Oct 15 14:46:45 2003 From: chris.ambler at enom.com (Chris Ambler) Date: Wed Oct 15 14:46:50 2003 Subject: [Ietf-not43] From answer to domain Message-ID: And I'm more than happy to go this route if that's the consensus. Indeed, that was the original route, but I took to using dreg at Rick Wesson's urging (and, I should add, his argument was persuasive, seeing as dreg has all of the data we need). I'll defer to the logic of the group. Christopher -----Original Message----- From: hardie@qualcomm.com [mailto:hardie@qualcomm.com] Sent: Wednesday, October 15, 2003 11:43 AM To: Chris Ambler; David Blacka Cc: ietf-not43@lists.verisignlabs.com Subject: RE: [Ietf-not43] From answer to domain As I read the charter, this work is out of scope for CRISP. Note this line in particular: "Backwards compatibility with existing administrative directory services such as WHOIS is not a goal of this effort." I recognize that what you are trying to do is a bit closer to "make WHOIS forward compatible with CRISP", but I think the same logic applies. The group has defined a set of requirements, and it is pretty clear that this work does not meet those requirements. This does not mean I want to discourage you from this work, but I would like you to distinguish it from CRISP. One way to do that might be to set up a separate mailing list and provide a pointer to this list describing the list's purpose; you might also wish to talk to the DREG schema authors directly. regards, Ted Hardie From davidb at verisignlabs.com Wed Oct 15 14:50:38 2003 From: davidb at verisignlabs.com (David Blacka) Date: Wed Oct 15 14:50:42 2003 Subject: [Ietf-not43] From answer to domain In-Reply-To: References: Message-ID: <200310151450.38714.davidb@verisignlabs.com> On Wednesday 15 October 2003 02:25 pm, Chris Ambler wrote: > The goal here is to create a WHOIS interchange format. Period. At > Rick's urging, we're using dreg instead of something new, simply > because they'd be, essentially, the same thing. The only difficulty > here is in getting the data into a single transmission, which is > made slightly challenging because of the normalization issue. But > including the elements in the additional element should solve this. Perhaps you said earlier, but interchanging between what and what? I only ask because if you want a format for exchanging entire WHOIS data sets, you might want to look at the stuff described in the iris-core document. Otherwise, you are almost describing a limited IRIS server using a different transport. Not that there is necessarily anything wrong with that. -- David Blacka Sr. Engineer Verisign Applied Research From chris.ambler at enom.com Wed Oct 15 15:04:36 2003 From: chris.ambler at enom.com (Chris Ambler) Date: Wed Oct 15 15:04:41 2003 Subject: [Ietf-not43] From answer to domain Message-ID: Interchange between registrars. The impetus for this is the problem wherein registrars have to hit each other's port 43 systems and page scrape to verify registrant data for transfers. We're implementing a two-front solution consisting of a predictable format as well as an IP-whitelist to ensure access to the interface. Some registrars are emitting the XML in their port 43 systems and others are making SOAP web services available (or both). So, the simple solution appeared to be to return a single result containing a "domain" element and an "additional" element such that all data is available in a single payload transmission. I could write my own schema, or use dreg. It seemed logical to use dreg. And yes, this could be characterized not as "backwards compatibility with WHOIS," but the first step in "WHOIS forward compatibility" for what it's worth (perhaps not much :-)) Again, I'm open to consensus on this. Perhaps track dreg as the format, but be a separate effort, which would eliminate any crossover, yet provide for easier interoperability, should that come to pass? Christopher -----Original Message----- From: David Blacka [mailto:davidb@verisignlabs.com] Sent: Wednesday, October 15, 2003 11:51 AM To: ietf-not43@lists.verisignlabs.com Subject: Re: [Ietf-not43] From answer to domain On Wednesday 15 October 2003 02:25 pm, Chris Ambler wrote: > The goal here is to create a WHOIS interchange format. Period. At > Rick's urging, we're using dreg instead of something new, simply > because they'd be, essentially, the same thing. The only difficulty > here is in getting the data into a single transmission, which is > made slightly challenging because of the normalization issue. But > including the elements in the additional element should solve this. Perhaps you said earlier, but interchanging between what and what? I only ask because if you want a format for exchanging entire WHOIS data sets, you might want to look at the stuff described in the iris-core document. Otherwise, you are almost describing a limited IRIS server using a different transport. Not that there is necessarily anything wrong with that. -- David Blacka Sr. Engineer Verisign Applied Research _______________________________________________ Ietf-not43 mailing list Ietf-not43@lists.verisignlabs.com https://lists.verisignlabs.com/mailman/listinfo/ietf-not43 From wessorh at ar.com Wed Oct 15 15:55:55 2003 From: wessorh at ar.com (Rick Wesson) Date: Wed Oct 15 15:57:05 2003 Subject: [Ietf-not43] From answer to domain In-Reply-To: References: Message-ID: <20031015125555.46a818ca.wessorh@ar.com> Ted, thanks for the official disclaimer =) We are implementing a PRIVATE inter registrar data exchange using some of the IRIS structures. the feedback of early implementations might be of some benifit to the draft authors. So, I'd recomend allowing this little effort to continue here as its as close a review as anyone has attempted to date. -rick On Wed, 15 Oct 2003 11:42:47 -0700 hardie@qualcomm.com wrote: > As I read the charter, this work is out of scope for CRISP. Note > this line in particular: > > "Backwards compatibility with existing administrative directory services > such as WHOIS is not a goal of this effort." > > I recognize that what you are trying to do is a bit closer to "make WHOIS > forward compatible with CRISP", but I think the same logic applies. > The group has defined a set of requirements, and it is pretty clear > that this work does not meet those requirements. > > This does not mean I want to discourage you from this work, but I would > like you to distinguish it from CRISP. One way to do that might be to > set up a separate mailing list and provide a pointer to this list describing > the list's purpose; you might also wish to talk to the DREG schema authors > directly. > > regards, > Ted Hardie > > > At 11:25 AM -0700 10/15/2003, Chris Ambler wrote: > >A small bit of history - Rick Wesson published a draft a couple of years ago > >with a simple XML format for WHOIS exchange. Essentially, an XML > >encapsulation of all of the stuff you'd want to see in WHOIS output. I took > >that draft and changed it to support what we need today. Rick took a look at > >it and said, "Hey, dreg has all of this stuff - why not just use that rather > >than make a whole new format?" That made sense to me, as the dreg schema > >does, indeed, have everything we need. > > > >The solution is a constrained one. We want to just emit domain information, > >and we want to do it in a single transmission - no extra trips to the server > >to resolve IDs or handles. > > > >As such, the solution seems to be to emit a resultSet with an answer > >containing a single domain, and an additional element with the contacts and > >nameservers and such in the same resultSet. > > > >The goal here is to create a WHOIS interchange format. Period. At Rick's > >urging, we're using dreg instead of something new, simply because they'd be, > >essentially, the same thing. The only difficulty here is in getting the data > >into a single transmission, which is made slightly challenging because of > >the normalization issue. But including the elements in the additional > >element should solve this. > > > >So the fact that we don't re-invent the wheel should mean that this makes > >sense then and there. As for the future, it allows us to be open to more of > >the features for this and future projects, and to more easily integrate our > >WHOIS output with other, larger IRIS-based projects. No? > > > >Christopher > > > >-----Original Message----- > >From: David Blacka [mailto:davidb@verisignlabs.com] > >Sent: Wednesday, October 15, 2003 11:05 AM > >To: Chris Ambler > >Cc: ietf-not43@lists.verisignlabs.com > >Subject: Re: [Ietf-not43] From answer to domain > > > > > >On Wednesday, October 15, 2003, at 01:08 PM, Chris Ambler wrote: > > > >> Heretical question: if the XSD is just a suggestion, as you intimate, > >> what > >> prevents me from breaking normalization and adding the allowance that, > >> for > >> example, the technicalContacts element of the domain element may > >> contain, in > >> addition to an iris:entity element, a contact element? > >> > >> Okay, let's say I don't do that (because your objection will be, "yes, > >> that > >> breaks normalization, and we'd prefer that not happen), but put the > >> actual > >> element in the additional element... is there a procedure whereby I > >> can push > >> my XSD back out as the "official XSD for using the dreg:domain inside > >> of an > >> answer element for the purpose of registrar WHOIS transmission?" or > >> some > >> such? > > > >I might be misunderstanding this whole conversation, but it seems to me > >that you are trying to use the IRIS/DREG1 schema for some > >non-IRIS/DREG1 purpose, and that you are having some difficulties > >because of this. > > > >Is the goal to create a WHOIS interchange format that will interoperate > >with CRISP, or is this an independent effort? (By interoperate, I am > >thinking that there may be a desire for a registrar to use one of these > >files as the data source for an IRIS/DREG1 server). > > > >If this is an independent effort, then you should just be using the > >DREG1 schema as a starting point. The DREG1 schema was designed in the > >context of the IRIS architecture. If that architecture isn't there, > >then the schema isn't going to be ideal. In that case, you may as well > >as create your own (albeit similar) schema. > > > >If it isn't an independent effort, then we need to make sure we > >understand how your efforts and IRIS need to interoperate. The schemas > >are not set in stone, but we need to understand the problems before we > >can judge what changes (if any) need to be made to the schemas. > > > >-- > >David Blacka > >Sr. Engineer Verisign Applied Research > >_______________________________________________ > >Ietf-not43 mailing list > >Ietf-not43@lists.verisignlabs.com > >https://lists.verisignlabs.com/mailman/listinfo/ietf-not43 > > _______________________________________________ > Ietf-not43 mailing list > Ietf-not43@lists.verisignlabs.com > https://lists.verisignlabs.com/mailman/listinfo/ietf-not43 From wessorh at ar.com Wed Oct 15 15:57:29 2003 From: wessorh at ar.com (Rick Wesson) Date: Wed Oct 15 15:58:37 2003 Subject: [Ietf-not43] From answer to domain In-Reply-To: <200310151450.38714.davidb@verisignlabs.com> References: <200310151450.38714.davidb@verisignlabs.com> Message-ID: <20031015125729.5b16fe6a.wessorh@ar.com> This is exactly where chris is heading, using parts of IRIS over a diferent query mech and transport and that isn't out of scope for this group. -rick On Wed, 15 Oct 2003 14:50:38 -0400 David Blacka wrote: > On Wednesday 15 October 2003 02:25 pm, Chris Ambler wrote: > > > The goal here is to create a WHOIS interchange format. Period. At > > Rick's urging, we're using dreg instead of something new, simply > > because they'd be, essentially, the same thing. The only difficulty > > here is in getting the data into a single transmission, which is > > made slightly challenging because of the normalization issue. But > > including the elements in the additional element should solve this. > > Perhaps you said earlier, but interchanging between what and what? I > only ask because if you want a format for exchanging entire WHOIS data > sets, you might want to look at the stuff > described in the iris-core document. Otherwise, you are almost > describing a limited IRIS server using a different transport. Not > that there is necessarily anything wrong with that. > > -- > David Blacka > Sr. Engineer Verisign Applied Research > > _______________________________________________ > Ietf-not43 mailing list > Ietf-not43@lists.verisignlabs.com > https://lists.verisignlabs.com/mailman/listinfo/ietf-not43 From wessorh at ar.com Wed Oct 15 15:59:33 2003 From: wessorh at ar.com (Rick Wesson) Date: Wed Oct 15 16:00:45 2003 Subject: [Ietf-not43] From answer to domain In-Reply-To: References: Message-ID: <20031015125933.290d5124.wessorh@ar.com> On Wed, 15 Oct 2003 12:04:36 -0700 Chris Ambler wrote: > WHOIS," but the first step in "WHOIS forward compatibility" for what it's > worth (perhaps not much :-)) > > Again, I'm open to consensus on this. Perhaps track dreg as the format, but > be a separate effort, which would eliminate any crossover, yet provide for > easier interoperability, should that come to pass? no lets not have seporate efforts, lets get some feedback to the draft authors of what works in the real world. I'll be happy to help chris author a draft on his effort and get that back to this group as some inplementation feedback -rick From April.Marine at nominum.com Wed Oct 15 16:29:00 2003 From: April.Marine at nominum.com (April Marine) Date: Wed Oct 15 16:29:04 2003 Subject: [Ietf-not43] From answer to domain In-Reply-To: <20031015125933.290d5124.wessorh@ar.com> References: <20031015125933.290d5124.wessorh@ar.com> Message-ID: <20031015132242.V91545@shell-ng.nominum.com> I have to cry "focus!" here as co-chair. I think Chris's work is very interesting, but it is not CRISP. It is not an implementation of the IRIS protocol, which is not even fully defined. Defining that protocol is what the CRISP WG is tasked to do and what this list needs to focus on. It's hard enough to make progress on just ONE topic, so I really don't want to add more stuff, tangentially relevant as it may be. I'm sure we can find someone to host list for this effort and I'm sure many CRISPies would join and comment. But if we start going off on a tangent now, we won't finish our "real" work. This statement in no way is meant as a comment on the work going on here, just a comment on the fact that is should not be going on "here". :) Speaking of this WG's work, how about some comments on the discussion points Andy took the time to put together and post for us? thanks, April On Wed, 15 Oct 2003, Rick Wesson wrote: > > > > On Wed, 15 Oct 2003 12:04:36 -0700 > Chris Ambler wrote: > > > > WHOIS," but the first step in "WHOIS forward compatibility" for what it's > > worth (perhaps not much :-)) > > > > Again, I'm open to consensus on this. Perhaps track dreg as the format, but > > be a separate effort, which would eliminate any crossover, yet provide for > > easier interoperability, should that come to pass? > > no lets not have seporate efforts, lets get some feedback to the draft authors of what works in the real world. I'll be happy to help chris author a draft on his effort and get that back to this group as some inplementation feedback > > -rick > > _______________________________________________ > Ietf-not43 mailing list > Ietf-not43@lists.verisignlabs.com > https://lists.verisignlabs.com/mailman/listinfo/ietf-not43 > From wessorh at ar.com Wed Oct 15 16:47:19 2003 From: wessorh at ar.com (Rick Wesson) Date: Wed Oct 15 16:48:27 2003 Subject: [Ietf-not43] From answer to domain In-Reply-To: <20031015132242.V91545@shell-ng.nominum.com> References: <20031015125933.290d5124.wessorh@ar.com> <20031015132242.V91545@shell-ng.nominum.com> Message-ID: <20031015134719.6818b870.wessorh@ar.com> April, On Wed, 15 Oct 2003 13:29:00 -0700 (PDT) April Marine wrote: > I have to cry "focus!" here as co-chair. I think Chris's work is very > interesting, but it is not CRISP. It is not an implementation of the IRIS > protocol, which is not even fully defined. Defining that protocol is what > the CRISP WG is tasked to do and what this list needs to focus on. It's > hard enough to make progress on just ONE topic, so I really don't want to > add more stuff, tangentially relevant as it may be. I'd agree with you except chris already identified a critical point on refencing contacts. > I'm sure we can find someone to host list for this effort and I'm sure > many CRISPies would join and comment. But if we start going off on a > tangent now, we won't finish our "real" work. actually I feel this "feedback" is quite relivant and usefull. > This statement in no way is meant as a comment on the work going on here, > just a comment on the fact that is should not be going on "here". :) realy, I hadn't seend anything going on here and the debate one the ontent of the dreg spec is actuallu useful. > Speaking of this WG's work, how about some comments on the discussion > points Andy took the time to put together and post for us? yes, we will get to those.... -rick From chris.ambler at enom.com Wed Oct 15 16:50:24 2003 From: chris.ambler at enom.com (Chris Ambler) Date: Wed Oct 15 16:50:35 2003 Subject: [Ietf-not43] From answer to domain Message-ID: And I'd welcome the help and participation. Christopher -----Original Message----- From: Rick Wesson [mailto:wessorh@ar.com] Sent: Wednesday, October 15, 2003 1:00 PM To: Chris Ambler Cc: davidb@verisignlabs.com; ietf-not43@lists.verisignlabs.com Subject: Re: [Ietf-not43] From answer to domain no lets not have seporate efforts, lets get some feedback to the draft authors of what works in the real world. I'll be happy to help chris author a draft on his effort and get that back to this group as some inplementation feedback -rick From chris.ambler at enom.com Wed Oct 15 16:59:11 2003 From: chris.ambler at enom.com (Chris Ambler) Date: Wed Oct 15 16:59:26 2003 Subject: [Ietf-not43] From answer to domain Message-ID: That works - and I'd be happy to set up a list for anyone interested in this. We'd planned on announcing this effort on the GNSO Registrars list some time next week, so if anyone here is interested, but not a registrar (or on that list), let me know privately. If there is any specific feedback I can provide, or anything that anyone would like me to consider/comment while implementing this, do also let me know, and I'll be pleased to forward that on. With apologies to Moltke, "No protocol survives contact with an implementation" :-) Christopher -----Original Message----- From: April Marine [mailto:April.Marine@nominum.com] Sent: Wednesday, October 15, 2003 1:29 PM To: CRISP WG Subject: Re: [Ietf-not43] From answer to domain I have to cry "focus!" here as co-chair. I think Chris's work is very interesting, but it is not CRISP. It is not an implementation of the IRIS protocol, which is not even fully defined. Defining that protocol is what the CRISP WG is tasked to do and what this list needs to focus on. It's hard enough to make progress on just ONE topic, so I really don't want to add more stuff, tangentially relevant as it may be. I'm sure we can find someone to host list for this effort and I'm sure many CRISPies would join and comment. But if we start going off on a tangent now, we won't finish our "real" work. This statement in no way is meant as a comment on the work going on here, just a comment on the fact that is should not be going on "here". :) Speaking of this WG's work, how about some comments on the discussion points Andy took the time to put together and post for us? thanks, April From william at completewhois.com Wed Oct 15 17:14:44 2003 From: william at completewhois.com (William Leibzon) Date: Wed Oct 15 17:00:21 2003 Subject: [Ietf-not43] From answer to domain In-Reply-To: <20031015132242.V91545@shell-ng.nominum.com> Message-ID: On Wed, 15 Oct 2003, April Marine wrote: > I have to cry "focus!" here as co-chair. I think Chris's work is very > interesting, but it is not CRISP. It is not an implementation of the IRIS > protocol, which is not even fully defined. Defining that protocol is what > the CRISP WG is tasked to do and what this list needs to focus on. It's > hard enough to make progress on just ONE topic, so I really don't want to > add more stuff, tangentially relevant as it may be. > > I'm sure we can find someone to host list for this effort and I'm sure > many CRISPies would join and comment. But if we start going off on a > tangent now, we won't finish our "real" work. > > This statement in no way is meant as a comment on the work going on here, > just a comment on the fact that is should not be going on "here". :) > > Speaking of this WG's work, how about some comments on the discussion > points Andy took the time to put together and post for us? > > thanks, > April I think this was interesting discussion on some practical use of CRISP structures and I think its not at all off-topic to the list even if its off-the side from the main track of this group. I have myself started implementing a converter from whois output to a more standard form with XML as possible output (internally it transforms output from multiple registrars to identify common fields and then can display it in pre-defined templated format or output as pure xml). I'm not using SOAP, but I was interested in hearing how others are doing. I know of at least one other whois proxy client developer who was also doing xml conversion and I'm sure there are others and we would like to coordinate with registrars if they support xml and how to use it directly as well as registrars themselve who may want to talk about it their own coordination as Chris mentioned. If there is indeed no interest in continuing discussion on using xml with current whois and making it forward compatible with future CRISP, then I'm willing to host a separate mailing list for this topic, but I hope it can stay here. --- William Leibzon Elan Networks, Completewhois Project From April.Marine at nominum.com Wed Oct 15 17:10:55 2003 From: April.Marine at nominum.com (April Marine) Date: Wed Oct 15 17:10:59 2003 Subject: [Ietf-not43] re Focus In-Reply-To: References: Message-ID: <20031015140311.U91545@shell-ng.nominum.com> Hm, in reviewing some of the feedback on my "focus" msg, let me clarify a couple of things. - Chris can get the feedback and input he desires via another list. No one on this list is going to ignore that work. - The IRIS folks can get the feedback and input they no doubt value via another list. So that effort will not lack valuable input, an example of which Rick has pointed out already. - As I was just looking at the charter and milestones this morning as a prelude to making sure they are up to date, the following sentence from the charter is fresh in my mind: "Backwards compatibility with existing administrative directory services such as WHOIS is not a goal of this effort." So, IMO, a separate effort does not harm Chris's work, but combining that work on the CRISP list *could* dilute the focus on CRISP, which, as co-chair, I must defend. :) In no way is my request to move the discussion meant to say that it is not useful, interesting or valuable. thanks, A. From wessorh at ar.com Wed Oct 15 17:24:54 2003 From: wessorh at ar.com (Rick Wesson) Date: Wed Oct 15 17:26:02 2003 Subject: [Ietf-not43] re Focus In-Reply-To: <20031015140311.U91545@shell-ng.nominum.com> References: <20031015140311.U91545@shell-ng.nominum.com> Message-ID: <20031015142454.77105eb7.wessorh@ar.com> April, lets not let administrativia get in the way of some valuable work/input. On Wed, 15 Oct 2003 14:10:55 -0700 (PDT) April Marine wrote: > Hm, in reviewing some of the feedback on my "focus" msg, let me clarify a > couple of things. > - As I was just looking at the charter and milestones this morning as a > prelude to making sure they are up to date, the following sentence from > the charter is fresh in my mind: "Backwards compatibility with existing > administrative directory services such as WHOIS is not a goal of this > effort." chris's effort is not for backward compatability, the port he is working on is irrilivant. he is interested in a single shot query/response lookup over SOAP using dreg. He is only using a diferent transport that beep. I've herd no implementation report on CRISP over beep, though i have herd grumbelings of a desire for a udp transport, so when did SOAP become out of scope? Stop being blinded when someone says "whois" as it is more often a service than a proto. -rick From chris.ambler at enom.com Wed Oct 15 17:42:02 2003 From: chris.ambler at enom.com (Chris Ambler) Date: Wed Oct 15 17:42:09 2003 Subject: [Ietf-not43] Status element in dreg Message-ID: Okay, specific to the protocol and apropos to the list (I hope). I note that there are a fixed number of status elements allowable in a domain element, and none of them cover some of the more typical status possibilities like registry-lock, registrar-lock and the like. Is this deliberate? If so, is there a contemplated method for communicating additional status information, such as the seeAlso element? Christopher -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.verisignlabs.com/pipermail/ietf-not43/attachments/20031015/51680673/attachment-0001.htm From davidb at verisignlabs.com Wed Oct 15 18:10:20 2003 From: davidb at verisignlabs.com (David Blacka) Date: Wed Oct 15 18:10:25 2003 Subject: [Ietf-not43] re Focus In-Reply-To: <20031015142454.77105eb7.wessorh@ar.com> References: <20031015140311.U91545@shell-ng.nominum.com> <20031015142454.77105eb7.wessorh@ar.com> Message-ID: <200310151810.20188.davidb@verisignlabs.com> On Wednesday 15 October 2003 05:24 pm, Rick Wesson wrote: > > April, > > lets not let administrativia get in the way of some valuable work/input. > > On Wed, 15 Oct 2003 14:10:55 -0700 (PDT) > April Marine wrote: > > > Hm, in reviewing some of the feedback on my "focus" msg, let me clarify a > > couple of things. > > > - As I was just looking at the charter and milestones this morning as a > > prelude to making sure they are up to date, the following sentence from > > the charter is fresh in my mind: "Backwards compatibility with existing > > administrative directory services such as WHOIS is not a goal of this > > effort." > > chris's effort is not for backward compatability, the port he is working on is irrilivant. he is interested in a single shot query/response lookup over SOAP using dreg. He is only using a diferent transport that beep. I've herd no implementation report on CRISP over beep, though i have herd grumbelings of a desire for a udp transport, so when did SOAP become out of scope? If, fundamentally, Chris is describing a special use case of IRIS, then all of his work is in scope. The use case he is describing (registar-to-registrar communication for the purposes of whatever) is one, IMHO, that should be in scope for the WG if it isn't. If, however, he is describing and aiming for a protocol that is somewhere between current WHOIS and IRIS, then some of his work will be in scope for this group, and some will not. And unfortunately, it will be difficult to tell which is which, because the stuff that is in scope really should be discussed on this list because it will help finish IRIS/DREG. Btw, Rick, what are you looking for as an implementation report of CRISP over BEEP? We've implemented it and released the code. We've even released a perl command line client that uses BEEP. -- David Blacka Sr. Engineer Verisign Applied Research From chris.ambler at enom.com Wed Oct 15 18:23:02 2003 From: chris.ambler at enom.com (Chris Ambler) Date: Wed Oct 15 18:23:06 2003 Subject: [Ietf-not43] re Focus Message-ID: >If, fundamentally, Chris is describing a special use case of IRIS, then all >of his work is in scope. The use case he is describing >(registar-to-registrar communication for the purposes of whatever) is one, >IMHO, that should be in scope for the WG if it isn't. If I understand you correctly, then yes, this is what I'm describing: Registrar to registrar communication for the purpose of transmitting accurate and consistently-formatted information about a domain, initially for the purpose of ensuring correct information to aid in the facilitation of registrar-to-registrar transfers. Call it a *replacement* for WHOIS if you wish, though my port-43 WHOIS server also consumes the dreg data from the SOAP web service I've created - it's a single-point-of-contact for domain data. Whether that's in scope for this WG is not for me to say. I'm happy to participate wherever appropriate. Christopher From anewton at ecotroph.net Wed Oct 15 21:53:55 2003 From: anewton at ecotroph.net (Andrew Newton) Date: Wed Oct 15 21:51:13 2003 Subject: [Ietf-not43] re Focus In-Reply-To: <20031015142454.77105eb7.wessorh@ar.com> References: <20031015140311.U91545@shell-ng.nominum.com> <20031015142454.77105eb7.wessorh@ar.com> Message-ID: <3F8DFA33.7090305@ecotroph.net> Rick Wesson wrote: > chris's effort is not for backward compatability, the port he is working on is irrilivant. he is interested in a single shot query/response lookup over SOAP using dreg. He is only using a diferent transport that beep. I've herd no implementation report on CRISP over beep, though i have herd grumbelings of a desire for a udp transport, so when did SOAP become out of scope? > We've got two server and client implementations doing IRIS over BEEP if you would like an implementation report. With regard to transports: 1) There is already an iris-lwz transport (using udp) defined as an individual submission (not a working group item). 2) There is also another individual submission on how to do whois/crisp cohabitation (also not a working group item). I put these down to show that the chairs have made these types of decisions in the past and that this is not new. Chairs do have certain responsibilities not to let things boil for too long, and I understand this. 3) IRIS over nicname/whois is akin to IRIS over TCP. In fact, if you have it on another port number, it would look astonishingly similar. This is just an observation. 4) The question of SOAP has come up many times, and its use has larger meaning than the CRISP working group for use with IETF protocols. In other words, I think there are larger meta questions that need to be answered. Personally, if IRIS over SOAP is to be persued, I think it should be done in a similar fashion to what the NeuStar guys were trying to do with EPP over SOAP. I would like to see us discuss other transports, but I would like to see us do it in a constructive manner that does not bog us down. -andy From anewton at ecotroph.net Wed Oct 15 22:01:34 2003 From: anewton at ecotroph.net (Andrew Newton) Date: Wed Oct 15 21:58:52 2003 Subject: [Ietf-not43] Status element in dreg In-Reply-To: References: Message-ID: <3F8DFBFE.9080205@ecotroph.net> Excellent question. We've discussed this and it was on my list of items April mentioned. I'll refer you back to the original message on the topic: > http://lists.verisignlabs.com/pipermail/ietf-not43/2003-September/000890.html But to save time (since I had to go look it up anyway), here's the relevant part quoted: > Change the status codes in the following way: > 1) They are contained within a parent element. > 2) Add a and status values. > 3) Allow the status elements to have an optional language="xx"> child. > 4) Make it a sequence and not a choice allowing the registry to define > the mutual exclusion of status values. > > This allows for localization as before but also accounts for locally > defined status values, and mixtures of status values. > Also, if you believe registry-lock and registrar-lock or other values are common and not accounted for in the current schema, I think they should be added. -andy Chris Ambler wrote: > Okay, specific to the protocol and apropos to the list (I hope). > > > > I note that there are a fixed number of status elements allowable in a > domain element, and none of them cover some of the more typical status > possibilities like registry-lock, registrar-lock and the like. Is this > deliberate? If so, is there a contemplated method for communicating > additional status information, such as the seeAlso element? > > > > Christopher > > > ------------------------------------------------------------------------ > > _______________________________________________ > Ietf-not43 mailing list > Ietf-not43@lists.verisignlabs.com > https://lists.verisignlabs.com/mailman/listinfo/ietf-not43 From chris.ambler at enom.com Wed Oct 15 22:37:50 2003 From: chris.ambler at enom.com (Chris Ambler) Date: Wed Oct 15 22:38:02 2003 Subject: [Ietf-not43] Status element in dreg Message-ID: Well, we've got the standard RRP and EPP status flags, as well as any that a registrar might care to add, if they're responding to the query. Indeed, some status flags aren't mutually exclusive. Additionally, I can forsee non-registry/non-registrar servers that have more, uncontemplated status flags, some of which might even be internal (and, more than likely, additive to other flags) So if there were to be a element, it might make sense to add an attribute that describes from what realm the status derives, such as "epp" or "rrp" or "podunk-registry-services" and the like, and to allow multiple children. Advanced codification of EPP and RRP status flags could be put into the XSD with the note that more can be added at any time - or it could just be a string value, with the known values documented for easy reference. I'm all for localization, but in the case of EPP and RRP, the values have codified meaning. In that case, we might want to have two fields, one for the codified meaning and one for localized-for-display? All off the top of my head, and without any prior knowledge of what has been discussed in the past, so apologies if I'm treading on well-worn ground. Christopher -----Original Message----- From: Andrew Newton To: Chris Ambler Cc: CRISP WG Sent: 10/15/03 7:01 PM Subject: Re: [Ietf-not43] Status element in dreg Excellent question. We've discussed this and it was on my list of items April mentioned. I'll refer you back to the original message on the topic: > http://lists.verisignlabs.com/pipermail/ietf-not43/2003-September/000890 .html But to save time (since I had to go look it up anyway), here's the relevant part quoted: > Change the status codes in the following way: > 1) They are contained within a parent element. > 2) Add a and status values. > 3) Allow the status elements to have an optional language="xx"> child. > 4) Make it a sequence and not a choice allowing the registry to define > the mutual exclusion of status values. > > This allows for localization as before but also accounts for locally > defined status values, and mixtures of status values. > Also, if you believe registry-lock and registrar-lock or other values are common and not accounted for in the current schema, I think they should be added. -andy Chris Ambler wrote: > Okay, specific to the protocol and apropos to the list (I hope). > > > > I note that there are a fixed number of status elements allowable in a > domain element, and none of them cover some of the more typical status > possibilities like registry-lock, registrar-lock and the like. Is this > deliberate? If so, is there a contemplated method for communicating > additional status information, such as the seeAlso element? > > > > Christopher > > > ------------------------------------------------------------------------ > > _______________________________________________ > Ietf-not43 mailing list > Ietf-not43@lists.verisignlabs.com > https://lists.verisignlabs.com/mailman/listinfo/ietf-not43 From anewton at ecotroph.net Thu Oct 16 12:31:35 2003 From: anewton at ecotroph.net (Andrew Newton) Date: Thu Oct 16 11:57:35 2003 Subject: [Ietf-not43] Status element in dreg In-Reply-To: References: Message-ID: <3F8EC7E7.5000003@ecotroph.net> I think what was proposed takes care of everything you just said, except for the new attribute for the realm. That's a pretty good idea. Should it be named 'realm' or 'origin'? -andy Chris Ambler wrote: > Well, we've got the standard RRP and EPP status flags, as well as any that a > registrar might care to add, if they're responding to the query. Indeed, > some status flags aren't mutually exclusive. Additionally, I can forsee > non-registry/non-registrar servers that have more, uncontemplated status > flags, some of which might even be internal (and, more than likely, additive > to other flags) > > So if there were to be a element, it might make sense to add an > attribute that describes from what realm the status derives, such as "epp" > or "rrp" or "podunk-registry-services" and the like, and to allow multiple > children. > > Advanced codification of EPP and RRP status flags could be put into the XSD > with the note that more can be added at any time - or it could just be a > string value, with the known values documented for easy reference. > > I'm all for localization, but in the case of EPP and RRP, the values have > codified meaning. In that case, we might want to have two fields, one for > the codified meaning and one for localized-for-display? > > All off the top of my head, and without any prior knowledge of what has been > discussed in the past, so apologies if I'm treading on well-worn ground. From chris.ambler at enom.com Thu Oct 16 12:22:29 2003 From: chris.ambler at enom.com (Chris Ambler) Date: Thu Oct 16 12:22:33 2003 Subject: [Ietf-not43] Status element in dreg Message-ID: Isn't there an accepted term of art for this sort of thing? If not, might I suggest that we call it "scope" for better accuracy of meaning? Christopher -----Original Message----- From: Andrew Newton [mailto:anewton@ecotroph.net] Sent: Thursday, October 16, 2003 9:32 AM To: Chris Ambler Cc: 'CRISP WG ' Subject: Re: [Ietf-not43] Status element in dreg I think what was proposed takes care of everything you just said, except for the new attribute for the realm. That's a pretty good idea. Should it be named 'realm' or 'origin'? -andy From anewton at ecotroph.net Thu Oct 16 13:00:53 2003 From: anewton at ecotroph.net (Andrew Newton) Date: Thu Oct 16 12:26:53 2003 Subject: [Ietf-not43] Status element in dreg In-Reply-To: References: Message-ID: <3F8ECEC5.1080706@ecotroph.net> I don't know, but 'scope' works for me. -andy Chris Ambler wrote: > Isn't there an accepted term of art for this sort of thing? If not, might I > suggest that we call it "scope" for better accuracy of meaning? > > Christopher > > -----Original Message----- > From: Andrew Newton [mailto:anewton@ecotroph.net] > Sent: Thursday, October 16, 2003 9:32 AM > To: Chris Ambler > Cc: 'CRISP WG ' > Subject: Re: [Ietf-not43] Status element in dreg > > I think what was proposed takes care of everything you just said, except > for the new attribute for the realm. That's a pretty good idea. Should > it be named 'realm' or 'origin'? > > -andy > > > _______________________________________________ > Ietf-not43 mailing list > Ietf-not43@lists.verisignlabs.com > https://lists.verisignlabs.com/mailman/listinfo/ietf-not43 From April.Marine at nominum.com Mon Oct 20 13:00:25 2003 From: April.Marine at nominum.com (April Marine) Date: Mon Oct 20 13:00:28 2003 Subject: [Ietf-not43] agenda items? Message-ID: <20031020095847.L11750@shell-ng.nominum.com> Hi all, George and I will be chatting later this week and hope to finalize an agenda for the next mtg soon. Any items people would like to see addressed? Drop a line. thx! April From anewton at ecotroph.net Mon Oct 20 13:41:59 2003 From: anewton at ecotroph.net (Andrew Newton) Date: Mon Oct 20 13:41:41 2003 Subject: [Ietf-not43] agenda items? In-Reply-To: <20031020095847.L11750@shell-ng.nominum.com> References: <20031020095847.L11750@shell-ng.nominum.com> Message-ID: <3F941E67.7040201@ecotroph.net> April Marine wrote: > Hi all, > > George and I will be chatting later this week and hope to finalize an > agenda for the next mtg soon. Any items people would like to see > addressed? Drop a line. > > thx! > April Can I get 15 minutes to talk about application transports, and specifically a UDP transport? -andy From April.Marine at nominum.com Fri Oct 24 20:34:25 2003 From: April.Marine at nominum.com (April Marine) Date: Fri Oct 24 20:34:28 2003 Subject: [Ietf-not43] suggested agenda for CRISP mtg in Minn. Message-ID: <20031024173252.O70284@shell-ng.nominum.com> George and I have come up with the following proposed agenda. Would you like to bash a bit before we send it in? Agenda for CRISP Working Group Meeting IETF 58 - Minneapolis, MN Wednesday, November 12, 13:00 - 15:00 o Welcome and Agenda Bashing - 10 min, chairs o Outstanding IRIS Issues - 35 min, Andy Newton and WG discussion o Additional Requirements? - 15 min, Ginny Listman - 10 min, WG discussion re: draft-ietf-crisp-internet-resource-number-requirements-00.txt o IRIS lightweight transport - 15 min, Andy Newton - 10 min, WG discussion o Update Charter and Milestones - 20 min, chairs o Wrap-up & Other Biz - 5 mins From April.Marine at nominum.com Fri Oct 24 20:48:58 2003 From: April.Marine at nominum.com (April Marine) Date: Fri Oct 24 20:49:03 2003 Subject: [Ietf-not43] draft CRISP charter Message-ID: <20031024173426.E70284@shell-ng.nominum.com> One of our agenda items is to update our charter and milestones. We have kicked around the following and want to run it by the group so you have time to review before the meeting (and so we can get input from those of you who won't be attending the meeting). This is a DRAFT, up for comments. I'm sure the milestone dates will change at the mtg. thx! April --------------------- In the standard operation of Internet systems, various labels and data are managed globally -- domain names, IPv4 and IPv6 addresses, etc. From time to time, for operational and administrative purposes, users of the Internet need to be able to find and access registered information associated with those labels. The CRISP (Cross-Registry Information Service Protocol) WG will define a standard mechanism that can be used for: - finding authoritative information associated with a label, - a protocol to transport queries and responses for accessing that information, - a first profile (schema & queries) to support commonly-required queries for domain registration information, * - a second profile (schema & queries) to support commonly-required queries for IP address registration information. The WG will strive to preserve an extensible architecture so that the work possibly be useful in the future to other types of registries beyond those specifically considered by the group. Specific topics that are NOT goals of this WG are: - Backwards compatibility with existing administrative directory services such as WHOIS. - Provisioning of data into registry or registrar systems. CRISP provides a uniform access to and view of data that may be held in disparate backend servers. The CRISP service definition will define: - a standard mechanism that can be used to determine the authoritative server(s) for information about a given label - a single mandatory to implement protocol for transporting application queries and responses, including - expression of input query - expression of result sets - standard expression of error conditions - authentication and verification of data integrity - specific data types and queries to be supported in the supported registry services. Deliverables: - Requirements document as an Informational RFC. (previously submitted) - First draft of protocol (use) specification. (previously submitted) - First draft of domain registration administrative directory services required schema element specification. (previously submitted) - Document specifying a new protocol, or the use of an existing one, for providing CRISP service (application transport). - Document specifying required schema elements and queries for domain registration administrative directory queries. * - Document specifying required schema elements and queries for IP address registration administrative directory queries. *Milestones: Jan 04 Submit revised protocol (use) specification document as Proposed Standard Jan 04 Submit revised draft of domain registration administrative directory services required schema element specification as Proposed Standard. Feb 04 Submit first draft of IP address registration administrative directory services required schema element specification Apr 04 Submit revised draft of IP address registration administrative directory services required schema element specification as Proposed Standard. From william at completewhois.com Sun Oct 26 20:25:15 2003 From: william at completewhois.com (William Leibzon) Date: Sun Oct 26 20:09:09 2003 Subject: [Ietf-not43] draft CRISP charter In-Reply-To: <20031024173426.E70284@shell-ng.nominum.com> Message-ID: It would be better to use more general term then just "IP address registration" or are we on purpose forgetting about ASNs? In some arin policies (such as experimental resource allocation 2002-2) the term used is "Numbering Resources" with definition for it given as "'Numbering Resources' refers to IPv4 or IPv6 address space and Autonomous System numbers". On Fri, 24 Oct 2003, April Marine wrote: > One of our agenda items is to update our charter and milestones. We have > kicked around the following and want to run it by the group so you have > time to review before the meeting (and so we can get input from those of > you who won't be attending the meeting). This is a DRAFT, up for > comments. I'm sure the milestone dates will change at the mtg. > > thx! > April > > --------------------- > > In the standard operation of Internet systems, various labels and data > are managed globally -- domain names, IPv4 and IPv6 addresses, > etc. From time to time, for operational and administrative purposes, > users of the Internet need to be able to find and access registered > information associated with those labels. > > The CRISP (Cross-Registry Information Service Protocol) WG will > define a standard mechanism that can be used for: > > - finding authoritative information associated with a label, > > - a protocol to transport queries and responses for accessing that > information, > > - a first profile (schema & queries) to support commonly-required > queries for domain registration information, > > * - a second profile (schema & queries) to support commonly-required > queries for IP address registration information. > > The WG will strive to preserve an extensible architecture so that the > work possibly be useful in the future to other types of registries > beyond those specifically considered by the group. > > > Specific topics that are NOT goals of this WG are: > > - Backwards compatibility with existing administrative directory > services such as WHOIS. > > - Provisioning of data into registry or registrar systems. CRISP > provides a uniform access to and view of data that may be held in > disparate backend servers. > > The CRISP service definition will define: > > - a standard mechanism that can be used to determine the > authoritative server(s) for information about a given label > > - a single mandatory to implement protocol for transporting > application queries and responses, including > > - expression of input query > > - expression of result sets > > - standard expression of error conditions > > - authentication and verification of data integrity > > - specific data types and queries to be supported in the > supported registry services. > > Deliverables: > > - Requirements document as an Informational RFC. (previously submitted) > > - First draft of protocol (use) specification. (previously submitted) > > - First draft of domain registration administrative directory > services required schema element specification. (previously submitted) > > - Document specifying a new protocol, or the use of an existing one, > for providing CRISP service (application transport). > > - Document specifying required schema elements and queries for domain > registration administrative directory queries. > > * - Document specifying required schema elements and queries for IP address > registration administrative directory queries. > > *Milestones: > > Jan 04 Submit revised protocol (use) specification document as > Proposed Standard > > Jan 04 Submit revised draft of domain registration administrative > directory services required schema element specification as Proposed > Standard. > > Feb 04 Submit first draft of IP address registration administrative > directory services required schema element specification > > Apr 04 Submit revised draft of IP address registration administrative > directory services required schema element specification as Proposed > Standard. > _______________________________________________ > Ietf-not43 mailing list > Ietf-not43@lists.verisignlabs.com > https://lists.verisignlabs.com/mailman/listinfo/ietf-not43 > From Internet-Drafts at ietf.org Mon Oct 27 09:14:30 2003 From: Internet-Drafts at ietf.org (Internet-Drafts@ietf.org) Date: Mon Oct 27 09:14:45 2003 Subject: [Ietf-not43] I-D ACTION:draft-ietf-crisp-iris-dreg-04.txt Message-ID: <200310271414.JAA13805@ietf.org> A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Cross Registry Information Service Protocol Working Group of the IETF. Title : IRIS - A Domain Registry (dreg) Type for the Internet Registry Information Service Author(s) : A. Newton Filename : draft-ietf-crisp-iris-dreg-04.txt Pages : 53 Date : 2003-10-24 This document describes an IRIS (draft-ietf-crisp-iris-core-00.txt ) registry schema for registered DNS information. The schema extends the necessary query and result operations of IRIS to provide the functional information service needs for syntaxes and results used by domain registries and registrars. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-crisp-iris-dreg-04.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-crisp-iris-dreg-04.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-crisp-iris-dreg-04.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. -------------- next part -------------- Skipped content of type multipart/alternative From Internet-Drafts at ietf.org Mon Oct 27 09:14:34 2003 From: Internet-Drafts at ietf.org (Internet-Drafts@ietf.org) Date: Mon Oct 27 09:14:55 2003 Subject: [Ietf-not43] I-D ACTION:draft-ietf-crisp-iris-areg-04.txt Message-ID: <200310271414.JAA13819@ietf.org> A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Cross Registry Information Service Protocol Working Group of the IETF. Title : IRIS - An Address Registry (areg) Type for the Internet Registry Information Service Author(s) : A. Newton Filename : draft-ietf-crisp-iris-areg-04.txt Pages : 39 Date : 2003-10-24 This document describes an IRIS (draft-ietf-crisp-iris-core-02.txt ) registry schema for IP address information. The schema extends the necessary query and result operations of IRIS to provide the functional information service needs for syntaxes and results used by Internet Protocol address registries. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-crisp-iris-areg-04.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-crisp-iris-areg-04.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-crisp-iris-areg-04.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. -------------- next part -------------- Skipped content of type multipart/alternative From Internet-Drafts at ietf.org Mon Oct 27 09:14:38 2003 From: Internet-Drafts at ietf.org (Internet-Drafts@ietf.org) Date: Mon Oct 27 09:15:02 2003 Subject: [Ietf-not43] I-D ACTION:draft-ietf-crisp-iris-core-04.txt Message-ID: <200310271414.JAA13838@ietf.org> A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Cross Registry Information Service Protocol Working Group of the IETF. Title : IRIS - The Internet Registry Information Service (IRIS) Core Protocol Author(s) : A. Newton Filename : draft-ietf-crisp-iris-core-04.txt Pages : 58 Date : 2003-10-24 This document describes an application layer client-server protocol for a framework of representing the query and result operations of the information services of Internet registries. Specified in XML, the protocol defines generic query and result operations and a mechanism for extending these operations for specific registry service needs. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-crisp-iris-core-04.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-crisp-iris-core-04.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-crisp-iris-core-04.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. -------------- next part -------------- Skipped content of type multipart/alternative From Internet-Drafts at ietf.org Mon Oct 27 09:14:41 2003 From: Internet-Drafts at ietf.org (Internet-Drafts@ietf.org) Date: Mon Oct 27 09:15:10 2003 Subject: [Ietf-not43] I-D ACTION:draft-ietf-crisp-iris-beep-04.txt Message-ID: <200310271414.JAA13852@ietf.org> A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Cross Registry Information Service Protocol Working Group of the IETF. Title : IRIS - Using the Internet Registry Information Service (IRIS) over the Blocks Extensible Exchange Protocol (BEEP) Author(s) : A. Newton Filename : draft-ietf-crisp-iris-beep-04.txt Pages : 19 Date : 2003-10-24 This document specifies how to use the Blocks Extensible Exchange Protocol (BEEP) as the application transport substrate for the Internet Registry Information Service (IRIS) as described draft-ietf-crisp-iris-core-00.txt. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-crisp-iris-beep-04.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-crisp-iris-beep-04.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-crisp-iris-beep-04.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. -------------- next part -------------- Skipped content of type multipart/alternative From Internet-Drafts at ietf.org Mon Oct 27 17:08:25 2003 From: Internet-Drafts at ietf.org (Internet-Drafts@ietf.org) Date: Mon Oct 27 17:08:43 2003 Subject: [Ietf-not43] I-D ACTION:draft-ietf-crisp-iris-dreg-04.txt Message-ID: <200310272208.RAA18611@ietf.org> A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Cross Registry Information Service Protocol Working Group of the IETF. Title : IRIS - A Domain Registry (dreg) Type for the Internet Registry Information Service Author(s) : A. Newton Filename : draft-ietf-crisp-iris-dreg-04.txt Pages : 53 Date : 2003-10-24 This document describes an IRIS (draft-ietf-crisp-iris-core-00.txt ) registry schema for registered DNS information. The schema extends the necessary query and result operations of IRIS to provide the functional information service needs for syntaxes and results used by domain registries and registrars. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-crisp-iris-dreg-04.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-crisp-iris-dreg-04.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-crisp-iris-dreg-04.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. -------------- next part -------------- Skipped content of type multipart/alternative From Internet-Drafts at ietf.org Mon Oct 27 17:08:28 2003 From: Internet-Drafts at ietf.org (Internet-Drafts@ietf.org) Date: Mon Oct 27 17:08:52 2003 Subject: [Ietf-not43] I-D ACTION:draft-ietf-crisp-iris-areg-04.txt Message-ID: <200310272208.RAA18630@ietf.org> A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Cross Registry Information Service Protocol Working Group of the IETF. Title : IRIS - An Address Registry (areg) Type for the Internet Registry Information Service Author(s) : A. Newton Filename : draft-ietf-crisp-iris-areg-04.txt Pages : 39 Date : 2003-10-24 This document describes an IRIS (draft-ietf-crisp-iris-core-02.txt ) registry schema for IP address information. The schema extends the necessary query and result operations of IRIS to provide the functional information service needs for syntaxes and results used by Internet Protocol address registries. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-crisp-iris-areg-04.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-crisp-iris-areg-04.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-crisp-iris-areg-04.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. -------------- next part -------------- Skipped content of type multipart/alternative From Internet-Drafts at ietf.org Mon Oct 27 17:08:32 2003 From: Internet-Drafts at ietf.org (Internet-Drafts@ietf.org) Date: Mon Oct 27 17:09:01 2003 Subject: [Ietf-not43] I-D ACTION:draft-ietf-crisp-iris-core-04.txt Message-ID: <200310272208.RAA18653@ietf.org> A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Cross Registry Information Service Protocol Working Group of the IETF. Title : IRIS - The Internet Registry Information Service (IRIS) Core Protocol Author(s) : A. Newton Filename : draft-ietf-crisp-iris-core-04.txt Pages : 58 Date : 2003-10-24 This document describes an application layer client-server protocol for a framework of representing the query and result operations of the information services of Internet registries. Specified in XML, the protocol defines generic query and result operations and a mechanism for extending these operations for specific registry service needs. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-crisp-iris-core-04.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-crisp-iris-core-04.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-crisp-iris-core-04.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. -------------- next part -------------- Skipped content of type multipart/alternative From Internet-Drafts at ietf.org Mon Oct 27 17:08:37 2003 From: Internet-Drafts at ietf.org (Internet-Drafts@ietf.org) Date: Mon Oct 27 17:09:09 2003 Subject: [Ietf-not43] I-D ACTION:draft-ietf-crisp-iris-beep-04.txt Message-ID: <200310272208.RAA18726@ietf.org> A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Cross Registry Information Service Protocol Working Group of the IETF. Title : IRIS - Using the Internet Registry Information Service (IRIS) over the Blocks Extensible Exchange Protocol (BEEP) Author(s) : A. Newton Filename : draft-ietf-crisp-iris-beep-04.txt Pages : 19 Date : 2003-10-24 This document specifies how to use the Blocks Extensible Exchange Protocol (BEEP) as the application transport substrate for the Internet Registry Information Service (IRIS) as described draft-ietf-crisp-iris-core-00.txt. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-crisp-iris-beep-04.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-crisp-iris-beep-04.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-crisp-iris-beep-04.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. -------------- next part -------------- Skipped content of type multipart/alternative From April.Marine at nominum.com Tue Oct 28 19:44:13 2003 From: April.Marine at nominum.com (April Marine) Date: Tue Oct 28 19:44:17 2003 Subject: [Ietf-not43] updated agenda for CRISP Message-ID: <20031028164302.H5670@shell-ng.nominum.com> I got one request for an additional slot, so stole some minutes away for it. I hope this adds up to 2 hours. I will be sending this form of the agenda in to the Secretariat as we are full up! thanks! A. Agenda for CRISP Working Group Meeting IETF 58 - Minneapolis, MN Wednesday, November 12, 13:00 - 15:00 o Welcome and Agenda Bashing - 10 min, chairs o Outstanding IRIS Issues - 35 min, Andy Newton and WG discussion o Additional Requirements? - 15 min, Ginny Listman - 7 min, WG discussion re: draft-ietf-crisp-internet-resource-number-requirements-00.txt o IRIS lightweight transport - 15 min, Andy Newton - 7 min, WG discussion o Update Charter and Milestones - 20 min, chairs o Using dreg for registrar-registrar - 6 mins, Chris Ambler communication o Wrap-up & Other Biz - 5 mins From April.Marine at nominum.com Thu Oct 30 13:46:26 2003 From: April.Marine at nominum.com (April Marine) Date: Thu Oct 30 13:46:29 2003 Subject: [Ietf-not43] draft CRISP charter In-Reply-To: References: Message-ID: <20031030104459.L91556@shell-ng.nominum.com> Sorry for the delay in replying. This is a very good point. I will flag it for now vs. doing yet another iteration of the charter and incorporate the final language choice into the final charter update. thanks! A. On Sun, 26 Oct 2003, William Leibzon wrote: > It would be better to use more general term then just "IP address > registration" or are we on purpose forgetting about ASNs? > > In some arin policies (such as experimental resource allocation 2002-2) > the term used is "Numbering Resources" with definition for it given as > "'Numbering Resources' refers to IPv4 or IPv6 address space and Autonomous > System numbers". > From anewton at ecotroph.net Thu Oct 30 14:33:00 2003 From: anewton at ecotroph.net (Andrew Newton) Date: Thu Oct 30 14:31:29 2003 Subject: [Ietf-not43] draft CRISP charter In-Reply-To: <20031024173426.E70284@shell-ng.nominum.com> References: <20031024173426.E70284@shell-ng.nominum.com> Message-ID: <3FA1676C.6010701@ecotroph.net> This doesn't seem to take into account Ginny's draft on the requirements for number resource registries: > http://www.ietf.org/internet-drafts/draft-ietf-crisp-internet-resource-number-req-00.txt Is that a given? -andy April Marine wrote: > One of our agenda items is to update our charter and milestones. We have > kicked around the following and want to run it by the group so you have > time to review before the meeting (and so we can get input from those of > you who won't be attending the meeting). This is a DRAFT, up for > comments. I'm sure the milestone dates will change at the mtg. > > thx! > April From April.Marine at nominum.com Thu Oct 30 14:37:52 2003 From: April.Marine at nominum.com (April Marine) Date: Thu Oct 30 14:37:55 2003 Subject: [Ietf-not43] draft CRISP charter In-Reply-To: <3FA1676C.6010701@ecotroph.net> References: <20031024173426.E70284@shell-ng.nominum.com> <3FA1676C.6010701@ecotroph.net> Message-ID: <20031030113453.U91556@shell-ng.nominum.com> mm, when you say "this" do you mean the charter? because at first I thought you meant that doc and that doc is Ginny's draft. If you mean the charter, we need to decide after the briefing on the draft that Ginny is giving in Minn. as to whether to adopt it as a WG item. Obviously, the draft charter assumes we are going in that direction, but I didn't want to be *too* presumptuous. The draft charter/milestones are there as a starting point for discussion--I expect they will be tweaked. If I misunderstood your question, pls let me know. thanks! A. On Thu, 30 Oct 2003, Andrew Newton wrote: > This doesn't seem to take into account Ginny's draft on the requirements > for number resource registries: > > > http://www.ietf.org/internet-drafts/draft-ietf-crisp-internet-resource-number-req-00.txt > > Is that a given? > > -andy > > April Marine wrote: > > One of our agenda items is to update our charter and milestones. We have > > kicked around the following and want to run it by the group so you have > > time to review before the meeting (and so we can get input from those of > > you who won't be attending the meeting). This is a DRAFT, up for > > comments. I'm sure the milestone dates will change at the mtg. > > > > thx! > > April > > From anewton at ecotroph.net Thu Oct 30 15:02:08 2003 From: anewton at ecotroph.net (Andrew Newton) Date: Thu Oct 30 15:00:37 2003 Subject: [Ietf-not43] draft CRISP charter In-Reply-To: <20031030113453.U91556@shell-ng.nominum.com> References: <20031024173426.E70284@shell-ng.nominum.com> <3FA1676C.6010701@ecotroph.net> <20031030113453.U91556@shell-ng.nominum.com> Message-ID: <3FA16E40.9000509@ecotroph.net> Sorry... this = proposed new charter -- as in: "This makes sense." thanks. -andy April Marine wrote: > mm, when you say "this" do you mean the charter? because at first I > thought you meant that doc and that doc is Ginny's draft. > > If you mean the charter, we need to decide after the briefing on the > draft that Ginny is giving in Minn. as to whether to adopt it as a WG > item. Obviously, the draft charter assumes we are going in that > direction, but I didn't want to be *too* presumptuous. The draft > charter/milestones are there as a starting point for discussion--I expect > they will be tweaked. > > If I misunderstood your question, pls let me know. > > thanks! > A. > > On Thu, 30 Oct 2003, Andrew Newton wrote: > > >>This doesn't seem to take into account Ginny's draft on the requirements >>for number resource registries: >> >> >>>http://www.ietf.org/internet-drafts/draft-ietf-crisp-internet-resource-number-req-00.txt >> >>Is that a given? >> >>-andy >> >>April Marine wrote: >> >>>One of our agenda items is to update our charter and milestones. We have >>>kicked around the following and want to run it by the group so you have >>>time to review before the meeting (and so we can get input from those of >>>you who won't be attending the meeting). This is a DRAFT, up for >>>comments. I'm sure the milestone dates will change at the mtg. >>> >>>thx! >>>April >> >> > _______________________________________________ > Ietf-not43 mailing list > Ietf-not43@lists.verisignlabs.com > https://lists.verisignlabs.com/mailman/listinfo/ietf-not43