From John.Mazzella at qwest.com Tue Sep 3 11:10:45 2002 From: John.Mazzella at qwest.com (Mazzella, John N) Date: Tue, 3 Sep 2002 09:10:45 -0600 Subject: FW: Do rejected SWIPs look different? Message-ID: <49F78F5E3F07D511818200508B5C785104AD40C7@BALNTEX001.qwest.net> > -----Original Message----- > From: IP Admin > Sent: Wednesday, August 28, 2002 5:19 PM > To: 'dbwg at arin.net' > Cc: Mazzella, John N > Subject: Do rejected SWIPs look different? > > ARIN, > > Is there a process in the works to change the appearance of rejected > SWIPs, so that we can parse rejected ARIN emails on our side? If not, > then can I recommend that ARIN change the appearance (change the subject > line, insert "REJECTED SWIP" perhaps, etc.) so that we can search on the > string and better organize our email from ARIN? > > Thanks and regards, > John Mazzella > Qwest IP Admin > 703.363.4139 > > PS: Also by the way, our ORG-DETAILEDs are visible and our swips appear to > be working smoothly! Thank you to everyone involved in the database > conversion! From ginny at arin.net Wed Sep 4 16:48:19 2002 From: ginny at arin.net (ginny listman) Date: Wed, 4 Sep 2002 16:48:19 -0400 (EDT) Subject: FW: Do rejected SWIPs look different? In-Reply-To: <49F78F5E3F07D511818200508B5C785104AD40C7@BALNTEX001.qwest.net> Message-ID: I was hoping to see more discussion on this on the list. ARIN Engineering can implement this. However, it is something that we would need community consensus on. I imagine there are companies out there that would not like us to change the header, or may need advanced notice of the change. Does anyone else an opinion on this? Ginny On Tue, 3 Sep 2002, Mazzella, John N wrote: > > > > -----Original Message----- > > From: IP Admin > > Sent: Wednesday, August 28, 2002 5:19 PM > > To: 'dbwg at arin.net' > > Cc: Mazzella, John N > > Subject: Do rejected SWIPs look different? > > > > ARIN, > > > > Is there a process in the works to change the appearance of rejected > > SWIPs, so that we can parse rejected ARIN emails on our side? If not, > > then can I recommend that ARIN change the appearance (change the subject > > line, insert "REJECTED SWIP" perhaps, etc.) so that we can search on the > > string and better organize our email from ARIN? > > > > Thanks and regards, > > John Mazzella > > Qwest IP Admin > > 703.363.4139 > > > > PS: Also by the way, our ORG-DETAILEDs are visible and our swips appear to > > be working smoothly! Thank you to everyone involved in the database > > conversion! > From ebohlin at uu.net Wed Sep 4 17:06:12 2002 From: ebohlin at uu.net (Einar Bohlin) Date: Wed, 4 Sep 2002 17:06:12 -0400 Subject: FW: Do rejected SWIPs look different? Message-ID: <20020904170612.A10782@uu.net> Good idea, we don't need to read the ones that go through, only the rejects. I look for the word 'unable' in the current rejections. But it wouldn't hurt and might even help to add something to the subject line. How about appending "REJECTED" to the end of the current subject line. Later, Einar Bohlin IP Number Commissar UUNET Technologies, Inc. Phone: USA 703 886-7362 email: ebohlin at uu.net (VNET Number 806-7362) ---------- Forwarded message ---------- Date: Wed, 04 Sep 2002 16:48:19 -0400 (EDT) From: ginny listman To: "Mazzella, John N" Cc: "'dbwg at arin.net'" Subject: Re: FW: Do rejected SWIPs look different? I was hoping to see more discussion on this on the list. ARIN Engineering can implement this. However, it is something that we would need community consensus on. I imagine there are companies out there that would not like us to change the header, or may need advanced notice of the change. Does anyone else an opinion on this? Ginny On Tue, 3 Sep 2002, Mazzella, John N wrote: > > > > -----Original Message----- > > From: IP Admin > > Sent: Wednesday, August 28, 2002 5:19 PM > > To: 'dbwg at arin.net' > > Cc: Mazzella, John N > > Subject: Do rejected SWIPs look different? > > > > ARIN, > > > > Is there a process in the works to change the appearance of rejected > > SWIPs, so that we can parse rejected ARIN emails on our side? If not, > > then can I recommend that ARIN change the appearance (change the subject > > line, insert "REJECTED SWIP" perhaps, etc.) so that we can search on the > > string and better organize our email from ARIN? > > > > Thanks and regards, > > John Mazzella > > Qwest IP Admin > > 703.363.4139 > > > > PS: Also by the way, our ORG-DETAILEDs are visible and our swips appear to > > be working smoothly! Thank you to everyone involved in the database > > conversion! > ----- End forwarded message ----- From brunner at nic-naa.net Thu Sep 5 13:32:26 2002 From: brunner at nic-naa.net (Eric Brunner-Williams in Portland Maine) Date: Thu, 05 Sep 2002 13:32:26 -0400 Subject: Request to Move RFC 954 to Historic Status Message-ID: <200209051732.g85HWQP3075043@nic-naa.net> [ietf-whois and related lists] I sat down with the European Commission's Call for Expressions of Interest for the Selection of the .eu TLD Registry this week, and was pleased that Directive 95/46/EC is the controlling framework for that registry's core policy requirements (B.3, 1(b), Technical Annex, page 2). Here is the URL to the EC's DP home: http://europa.eu.int/comm/internal_market/en/dataprot/ That was my first imputus to finally submit an individual contribution to move 954 from "DRAFT STANDARD" to "HISTORIC". Now prior to Yokahama I asked around if anyone knew why and how (process) 954 had been moved from "UNKNOWN" (like 742 and 812) to "DRAFT STANDARD". No one I asked knew, but I didn't bother to formally ask the IESG and/or the RFC Editor. That change of status for 954 appears to have occured in the past two years. Perhaps someone on the IESG can enlighten me. Then there is the current ICANN announcement of some policy w.r.t. its Registrar Accreditation Agreement (RAA). The RAA contains language which appears closer to the language in 954 concerning MILNET TAC users than to the language in 954 concerning individual with a directory on an ARPANET or MILNET host. Both are in conflict with 95/46/EC, and the OEDC Guidelines (the oecd.org link is broken, so here is Roger Clarke's restatement, itself a useful read) http://www.anu.edu.au/people/Roger.Clarke/DV/PaperOECD.html I can't speculate on the actual status of :43 deployments by ccTLD operators located outside of North America. I decided not to include a mapping from the DCA language to a P3P schema, as for many, the policy scope question (controlling jurisdiction and legal theory, e.g., "fair trade" (US) vs "human rights" (EU)), not the mechanism for description and policy-scoped access, is more interesting, and both XML and schemas and/or DTDs are a distraction. I'll add it to -01. Your comments are welcome. I've cc'd the Provreg WG list due to the overlap of interest (many are also registrars and/or registry operators), and the W3C's P3P Spec WG list, also due to the overlap of interest. If anyone can provide feedback from RIPE-43 and or CENTR (Jaap?), or ICDPPC-24 (Rigo?) this month, and ARIN-X (Ed?) next month, that would be a good thing. Please be sure to cc me if replying. I started writing this before a comment got to me. The comment was: > I strongly disagree with the suggestion posed by this Draft. Whois is > a protocol in the public domain, and people can and do still use it. > The fact that SRI no longer supports it under DCA funding is an absurd > argument; it is just as irrelevant as the fact that ISI no longer > supports the DNS under DARPA funding, as it once did; should we make > the DNS protocol Historic? > > There is no protocol document obsoleting Whois, and I am not aware of > any terrible network consequence of its operation. People with > security issues on their databases do not have to participate. If > there are technical security problems with the protocol, the IESG > should move to develop a protocol to obsolete Whois. In the absence of > such a replacement, and in the absence of any demonstrable harm to the > Internet from keeping it as a Draft Standard, moving it to Historic > would be unnecessary and (I believe) a violatiokn of common sense > and proper standards setting. 954 specifies not only a protocol: C: [::printable::]\r\n S: .*\r\n It also specifies a data colleciton practice, the DCA's for MILNET TAC users, and for individual (users) with a directory on an ARPANET or MILNET host. The data collection practice itself is historic. The PROPOSED STANDARD status of a national military data collection practice is historic as well. If the IETF has any role in non-military public registry data collection practices, by RIRs, domain registry operators, or others choosing to use the above protocol on port 43, 954 is historic. Strong disagreement noted. Eric ------- Forwarded Message To: IETF-Announce: ; From: Internet-Drafts at ietf.org Reply-to: Internet-Drafts at ietf.org Subject: I-D ACTION:draft-brunner-rfc954-historic-00.txt Date: Thu, 05 Sep 2002 07:18:36 -0400 Sender: nsyracus at cnri.reston.va.us - --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Request to Move RFC 954 to Historic Status Author(s) : E. Brunner-Williams Filename : draft-brunner-rfc954-historic-00.txt Pages : 3 Date : 2002-9-4 This memo requests a change of the status of RFC 954, A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-brunner-rfc954-historic-00.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-brunner-rfc954-historic-00.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 at ietf.org. In the body type: "FILE /internet-drafts/draft-brunner-rfc954-historic-00.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. - --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" - --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv at ietf.org" Content-Type: text/plain Content-ID: <2002-9-4143115.I-D at ietf.org> ENCODING mime FILE /internet-drafts/draft-brunner-rfc954-historic-00.txt - --OtherAccess Content-Type: Message/External-body; name="draft-brunner-rfc954-historic-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2002-9-4143115.I-D at ietf.org> - --OtherAccess-- - --NextPart-- ------- End of Forwarded Message From dredd at megacity.org Thu Sep 5 14:12:33 2002 From: dredd at megacity.org (Derek J. Balling) Date: Thu, 5 Sep 2002 14:12:33 -0400 Subject: Request to Move RFC 954 to Historic Status In-Reply-To: <200209051732.g85HWQP3075043@nic-naa.net> Message-ID: <0C98942B-C0FB-11D6-AF9D-00039384A830@megacity.org> On Thursday, September 5, 2002, at 01:32 PM, Eric Brunner-Williams in Portland Maine wrote: > [ietf-whois and related lists] I won't pretend that I'm on all of these mailing list in that CC line, but I am at least on a few. :-) > I decided not to include a mapping from the DCA language to a P3P > schema, > as for many, the policy scope question (controlling jurisdiction and > legal > theory, e.g., "fair trade" (US) vs "human rights" (EU)), not the > mechanism > for description and policy-scoped access, is more interesting, and > both XML > and schemas and/or DTDs are a distraction. I'll add it to -01. > > Your comments are welcome. A lot of this discussion appears to sort of happen "over my head" so please forgive me a bit if I seem stupid or something. ;-) Part of my "night job" is the maintenance of the rfc-ignorant.org site, including the "whois.rfc-ignorant.org" zone, listing both individual domains with bad/missing/inaccurate WHOIS data, and [using a different result code], ccTLD's with similar problems. We have a wide variety of users who utilize our service, including universities and commercial establishments. Some of them, obviously, use "the entire list" and some use "everything but the ccTLD wildcard entries". It is fairly difficult to ascertain accurately what percentage is behaving how, in that regard. In our experience, there is - as you note - two different mindsets to registry operators. The USian perspective seems to be "you're part of a shared namespace, other folks have a right to know who you are", and the EU perspective seems to be, simply, "no you don't". (!US,!EU) tend to be either split into thirds between US, EU, and "no whois server at all". I believe that the main problem of RFC954 is that it tries to (well, it DOES) define both a protocol and a policy. In the absence of a document which defines "just the protocol", though, which could obsolete RFC954, the removal of 954 to HISTORIC status is a misnomer. It *is* an active protocol in use by registries around the world. It is also an accurate statement to say that 954 is horribly out of date and doesn't necessarily reflect "the real state of the world" in many of the things it contains within the document, and I think such "dated" statements taint the value of both the protocol portions of the document, and the "spirit" of the document. In my ideal world, I believe that the "vision" of complete WHOIS information that 954 describes is still, in fact, a BCP, despite what some EU members might think. (it's ok, you're entitled to disagree with me *grin*) I can respect the desire for privacy that some feel is important. However, I think in a networking environment such as we have today, it is equally - if not more - important, to be able to contact folks via "a range of available methods", to be able to do so quickly without jumping through various registry-induced hoops, and to be able to obtain that complete info via a standardized protocol. (Too many ccTLD operators point people at web pages, which - unless there is a standard - breaks automated tools quite handily). The short version of this is, I guess, "I think relegating 954 to HISTORIC status is premature, and should be postponed until - at bare minimum - a new/updated RFC defines the protocol, and preferably until there is both a protocol RFC as well as a policy RFC". We can debate what the policy RFC would say at a later date. ;-) Cheers, D -- +------------------------------+--------------------------------+ | Derek J. Balling | "You can get more with a kind | | dredd at megacity.org | word and a two-by-four, than | | www.megacity.org/blog/ | you can with just a kind | | | word." - Marcus | +---------------------------------------------------------------+ From John.Mazzella at qwest.com Fri Sep 6 18:12:17 2002 From: John.Mazzella at qwest.com (Mazzella, John N) Date: Fri, 6 Sep 2002 18:12:17 -0400 Subject: FW: Do rejected SWIPs look different? Message-ID: <49F78F5E3F07D511818200508B5C785108CC8B4B@BALNTEX001.qwest.net> Einar, I agree completely with you! We have a huge number of swip email replies from ARIN, and we would like to manage them better. We do not rely on the current contents of the Subject line, but we would start to utilize the Subject line if there were "REJECTED" somewhere in the Subject line. I am not having much success with your solution yet, to filter on the word "unable" in the body. We would definitely like to see a clear difference in the Subject lines of rejected vs successful SWIPs. Are there any other ISPs who would like to comment? John -----Original Message----- From: Einar Bohlin [mailto:ebohlin at uu.net] Sent: Wednesday, September 04, 2002 5:06 PM To: dbwg at arin.net Subject: Re: FW: Do rejected SWIPs look different? Good idea, we don't need to read the ones that go through, only the rejects. I look for the word 'unable' in the current rejections. But it wouldn't hurt and might even help to add something to the subject line. How about appending "REJECTED" to the end of the current subject line. Later, Einar Bohlin IP Number Commissar UUNET Technologies, Inc. Phone: USA 703 886-7362 email: ebohlin at uu.net (VNET Number 806-7362) ---------- Forwarded message ---------- Date: Wed, 04 Sep 2002 16:48:19 -0400 (EDT) From: ginny listman To: "Mazzella, John N" Cc: "'dbwg at arin.net'" Subject: Re: FW: Do rejected SWIPs look different? I was hoping to see more discussion on this on the list. ARIN Engineering can implement this. However, it is something that we would need community consensus on. I imagine there are companies out there that would not like us to change the header, or may need advanced notice of the change. Does anyone else an opinion on this? Ginny On Tue, 3 Sep 2002, Mazzella, John N wrote: > > > > -----Original Message----- > > From: IP Admin > > Sent: Wednesday, August 28, 2002 5:19 PM > > To: 'dbwg at arin.net' > > Cc: Mazzella, John N > > Subject: Do rejected SWIPs look different? > > > > ARIN, > > > > Is there a process in the works to change the appearance of rejected > > SWIPs, so that we can parse rejected ARIN emails on our side? If not, > > then can I recommend that ARIN change the appearance (change the subject > > line, insert "REJECTED SWIP" perhaps, etc.) so that we can search on the > > string and better organize our email from ARIN? > > > > Thanks and regards, > > John Mazzella > > Qwest IP Admin > > 703.363.4139 > > > > PS: Also by the way, our ORG-DETAILEDs are visible and our swips appear to > > be working smoothly! Thank you to everyone involved in the database > > conversion! > ----- End forwarded message ----- From John.Mazzella at qwest.com Mon Sep 9 16:01:25 2002 From: John.Mazzella at qwest.com (Mazzella, John N) Date: Mon, 9 Sep 2002 14:01:25 -0600 Subject: ARIN reply-alls Message-ID: <49F78F5E3F07D511818200508B5C785108CC8B60@BALNTEX001.qwest.net> ARIN, When we send you an email with multiple names on the To: and CC:, will you be replying to all orders, or just to the single order listed on our ORG record (ipadmin at qwest.com)? We noticed that as of August 30, you stopped reply-all'ing. Is this a temporary policy change, or permanent? We would like to know, because if you do reply-all, then we can better target the originating engineer straight from your reply. However, I am also in favor of the argument for tighter security on the single emails listed in the ORG record. Thanks for your feedback, John Mazzella Qwest IP Implementation 703.363.4139 From ginny at arin.net Tue Sep 10 11:24:06 2002 From: ginny at arin.net (ginny listman) Date: Tue, 10 Sep 2002 11:24:06 -0400 (EDT) Subject: ARIN reply-alls In-Reply-To: <49F78F5E3F07D511818200508B5C785108CC8B60@BALNTEX001.qwest.net> Message-ID: John, We have been replying to the Sender, who should have past the authorization. Other people have also expressed an interest in received replies to the Reply-To. Will make the change to CC the Reply-To and continue to reply to the Sender. This change will be in testing for the next few days, but you should notice the change by the end of the week. Ginny Listman Director of Engineering ARIN On Mon, 9 Sep 2002, Mazzella, John N wrote: > ARIN, > > When we send you an email with multiple names on the To: and CC:, will you > be replying to all orders, or just to the single order listed on our ORG > record (ipadmin at qwest.com)? We noticed that as of August 30, you stopped > reply-all'ing. Is this a temporary policy change, or permanent? > > We would like to know, because if you do reply-all, then we can better > target the originating engineer straight from your reply. However, I am > also in favor of the argument for tighter security on the single emails > listed in the ORG record. Thanks for your feedback, > > John Mazzella > Qwest IP Implementation > 703.363.4139 > From jjbrzozowski at lucent.com Tue Sep 24 12:15:48 2002 From: jjbrzozowski at lucent.com (John Brzozowski) Date: Tue, 24 Sep 2002 12:15:48 -0400 Subject: SWIP Inquiries Message-ID: <008d01c263e5$a4f22b30$371e640a@quadritek.com> I have a couple of questions related to SWIP Reporting and was wondering if someone could help clarify. 1) It seems that the Reallocate and Reassign - Details templates are similar but clearly not identical. What exactly is the difference between the two? Also, if an allocation is performed using one of the above what template is used to (de/re)allocate or free the allocation space? I am assuming Reassign - Simple since neither Reallocate and Reassign - Detail have a "Registration Action" parameter. Is this a bad assumption? 2) Reallocate, Reassign - Simple, and Reassign - Details appear to be versioned. Can it be assumed that this was done in anticipation of future versions with changes that correspond to the same? What level of backward compatibility will there be with subsequent versions of these templates? For example, if a 3.0 template is used to perform an allocation today what template can or should be used to (de/re)allocate at some point in the future when version a later version of the templates are available? Will the original template version be required or will most recent version be accepted as well? Thanks, ============================================ John Jason Brzozowski Lucent Technologies (O) 610-722-7979 (F) 610-725-8559 mailto:jjbrzozowski at lucent.com mailto:jbrzozowski at quadritek.com http://qip.lucent.com/ ============================================ From ginny at arin.net Tue Sep 24 14:00:01 2002 From: ginny at arin.net (ginny listman) Date: Tue, 24 Sep 2002 14:00:01 -0400 (EDT) Subject: SWIP Inquiries In-Reply-To: <008d01c263e5$a4f22b30$371e640a@quadritek.com> Message-ID: On Tue, 24 Sep 2002, John Brzozowski wrote: > I have a couple of questions related to SWIP Reporting and was wondering if > someone could help clarify. > > 1) It seems that the Reallocate and Reassign - Details templates are similar > but clearly not identical. What exactly is the difference between the two? > Also, if an allocation is performed using one of the above what template is > used to (de/re)allocate or free the allocation space? I am assuming > Reassign - Simple since neither Reallocate and Reassign - Detail have a > "Registration Action" parameter. Is this a bad assumption? If you remove the embedded instructions, the only difference between the two templates is the header. The reason ARIN went with two different templates is that there were a large number of requests to change a reassign to a reallocate from the old template. A reallocate template is used by an upstream ISP to allocate addresses to a downstream ISP customer, who in turn can allocate or assign addresses to their downstream customer. A reassign detailed template is used by an upstream ISP to assign IP addresses to a downstream customer for use in their own network, and who wishes to either maintain their own POCs or in-addr servers on their reassigned IP space. To remove a Reassign-Detailed or Reallocate you should use the Netmod template. The Reassign-Simple can only be used to remove simple reassignments, i.e. those without POC or inaddr name servers associated with them. Note that you can use either Netmod or Reassign-Simple to remove simple reassign networks. > > 2) Reallocate, Reassign - Simple, and Reassign - Details appear to be > versioned. Can it be assumed that this was done in anticipation of future > versions with changes that correspond to the same? What level of backward > compatibility will there be with subsequent versions of these templates? > For example, if a 3.0 template is used to perform an allocation today what > template can or should be used to (de/re)allocate at some point in the > future when version a later version of the templates are available? Will > the original template version be required or will most recent version be > accepted as well? > We will use the version number for version control. If we release a new version, the latest version is preferred for all templates. However, we realize that many people have automated scripts and do not download the latest versions from the ftp site on a regular basis. As long as there isn't a drastic change to the templates, older versions will continue to be accepted. Ginny Listman Director of Engineering ARIN From brmandal at att.com Thu Sep 26 11:07:50 2002 From: brmandal at att.com (Mandal, Barbara R, ALCNS) Date: Thu, 26 Sep 2002 11:07:50 -0400 Subject: [dbwg] Org ID question Message-ID: <62DA45D4963FA747BA1B253E266760F903F08FFB@OCCLUST04EVS1.ugd.att.com> We're trying to decide whether or not to enhance our SWIP application to take advantage of org IDs. Currently we resend the customer information on subsequent reassign-detailed templates because we do not save the org _D. However, it seems that ARIN is able to recognize that the company was previously registered even without the org ID. Can you tell me what information you use to make that decision? Name, address, city, state, zip, and/or country? Thanks. Barbara Mandal AT&T IP Systems Engineering From ginny at arin.net Thu Sep 26 14:04:45 2002 From: ginny at arin.net (ginny listman) Date: Thu, 26 Sep 2002 14:04:45 -0400 (EDT) Subject: [dbwg] Org ID question In-Reply-To: <62DA45D4963FA747BA1B253E266760F903F08FFB@OCCLUST04EVS1.ugd.att.com> Message-ID: Barbara, The registration software will prompt the user (Registration Services) with a list of Org IDs for matches with the same Org Name, City, State and Country Code. However, we do not recommend that you rely on this for several reasons: 1. Since this requires interaction by an IP Analyst, it will not be auto- processed. If you provide the Org ID, you may reduce your turn around time to a few hours. Those templates that are not auto-processed will be manually processed within two business days. 2. There are many downstreams that are multi-homed and may have several Org IDs associated with each upstream. There is the possibility the IP Analyst may not be able to determine which Org ID to associate the resource with, and therefore will create a new one. 3. If there is updated information on the org, for example a new address, this information will not be updated if the IP Analyst selects an existing Org ID. Updates of this nature should be submitted on an Org-Simple or Org-Detailed template. Ginny Listman Director of Engineering ARIN On Thu, 26 Sep 2002, Mandal, Barbara R, ALCNS wrote: > We're trying to decide whether or not to enhance our SWIP application to take advantage of org IDs. Currently we resend the customer information on subsequent reassign-detailed templates because we do not save the org _D. However, it seems that ARIN is able to recognize that the company was previously registered even without the org ID. Can you tell me what information you use to make that decision? Name, address, city, state, zip, and/or country? Thanks. > > Barbara Mandal > AT&T IP Systems Engineering > >