From ndavis at arin.net Mon Nov 4 08:50:25 2013 From: ndavis at arin.net (Nate Davis) Date: Mon, 4 Nov 2013 13:50:25 +0000 Subject: [arin-tech-discuss] Issue raised by community member Message-ID: Team, Jason submitted this to the ARIN's Suggestion and Consultation Process. However, I believe this is the correct forum for the issue. Can staff take a look at this and respond? I have asked Jason to subscribe to arin-tech-discuss in order to join the discussion on this matter. Thanks! 2013.25 Submitted11-01-2013 15:25:00 Status CONFIRMED Title Suggestion Our automated systems recently attempted to pass "N/" as a "State" field for a registration to a London, UK address. The API returned a 500 error, E_UNSPECIFIED, rather than returning 400/E_ENTITY_VALIDATION, or something more explanatory. This temporarily led us to believe it was a problem with the service rather than a problem with the data. Timeframe Immediate Comments[ Edit Suggestion ] Submitter Information Name Jason Rodriguez Org Name SoftLayer E-Mail Phone From martin at he.net Mon Nov 4 09:05:18 2013 From: martin at he.net (Martin J. Levy) Date: Mon, 4 Nov 2013 14:05:18 +0000 Subject: [arin-tech-discuss] Issue raised by community member In-Reply-To: References: Message-ID: <04B95F63-E2D9-4000-B4A8-4715E271CEA4@he.net> If I may expand this somewhat; isn't this an issue with ALL the physical postal address fields? Internationalization or support of weirds (IETF ICANN etc etc) seems the Globsl push. The state field is only part if this. Martin Martin J. Levy Director IPv6 Strategy Hurricane Electric 760 Mission Court, Fremont, CA 94539, USA +1 408 499 3801 (mobile) martin at he.net (email) http://he.net/ (web) On Nov 4, 2013, at 1:50 PM, Nate Davis wrote: > Team, > > Jason submitted this to the ARIN's Suggestion and Consultation Process. > However, I believe this is the correct forum for the issue. Can staff > take a look at this and respond? > > I have asked Jason to subscribe to arin-tech-discuss in order to join the > discussion on this matter. > > Thanks! > > > 2013.25 Submitted11-01-2013 15:25:00 > Status CONFIRMED > Title Suggestion > Our automated systems recently attempted to pass "N/" as a "State" field > for a registration to a London, UK address. The API returned a 500 error, > E_UNSPECIFIED, rather than returning 400/E_ENTITY_VALIDATION, or something > more explanatory. This temporarily led us to believe it was a problem > with the service rather than a problem with the data. > Timeframe Immediate > Comments[ Edit Suggestion ] > > > Submitter Information > Name Jason Rodriguez > Org Name SoftLayer > E-Mail > Phone > > > _______________________________________________ > arin-tech-discuss mailing list > arin-tech-discuss at arin.net > http://lists.arin.net/mailman/listinfo/arin-tech-discuss From timc at arin.net Mon Nov 4 13:42:23 2013 From: timc at arin.net (Tim Christensen) Date: Mon, 4 Nov 2013 18:42:23 +0000 Subject: [arin-tech-discuss] Issue raised by community member In-Reply-To: References: Message-ID: Greetings Jason, I'm having trouble replicating the issue that you reported. I have attempted to create both POCs and ORGs with a variety of combinations of country codes (including the valid "GB" and invalid "UK"), along with variations of iso3166-2 (state/province) codes (for which ARIN's system does not edit unless the country is 'US' or 'CA'). In each case, I got back either 400/Bad Request with E_ENTITY_VALIDATION and a descriptive message of the error, or in cases where the input was accepted, a 200/OK and a result payload. In no case was I able to replicate your 500/E_UNSPECIFIED error. Could you provide a (rather sanitized, without your API key or other sensitive information) copy of the method and payload that you were sending to the list, so that I can try to replicate the issue? Also, can you provide the time/date that you attempted this request, and whether it was against the production system or against the OT&E test system? Thanks for any insight you can provide. Best regards, Tim Christensen ARIN Engineering On Nov 4, 2013, at 8:50 AM, Nate Davis wrote: > Team, > > Jason submitted this to the ARIN's Suggestion and Consultation Process. > However, I believe this is the correct forum for the issue. Can staff > take a look at this and respond? > > I have asked Jason to subscribe to arin-tech-discuss in order to join the > discussion on this matter. > > Thanks! > > > 2013.25 Submitted11-01-2013 15:25:00 > Status CONFIRMED > Title Suggestion > Our automated systems recently attempted to pass "N/" as a "State" field > for a registration to a London, UK address. The API returned a 500 error, > E_UNSPECIFIED, rather than returning 400/E_ENTITY_VALIDATION, or something > more explanatory. This temporarily led us to believe it was a problem > with the service rather than a problem with the data. > Timeframe Immediate > Comments[ Edit Suggestion ] > > > Submitter Information > Name Jason Rodriguez > Org Name SoftLayer > E-Mail > Phone > > > _______________________________________________ > arin-tech-discuss mailing list > arin-tech-discuss at arin.net > http://lists.arin.net/mailman/listinfo/arin-tech-discuss From damien at supremebytes.com Mon Nov 11 20:02:27 2013 From: damien at supremebytes.com (Damien Burke) Date: Tue, 12 Nov 2013 01:02:27 +0000 Subject: [arin-tech-discuss] question about swip customer records Message-ID: <2FD50E6D13594B4C93B743BFCF9F52844ECF49@sbla1-exchange.sb.local> Hello, Does ARIN prune old customer records that don't have networks assigned to them? Damien Burke Chief Executive Officer SupremeBytes, LLC P.O. Box 13746 | Columbus, Ohio 43213 Office (614) 636-4923 | Phone (614) 636-4875 | Fax (614) 636-4877 http://www.supremebytes.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From krishna.csu at gmail.com Thu Nov 14 20:40:36 2013 From: krishna.csu at gmail.com (krishna.csu) Date: Thu, 14 Nov 2013 20:40:36 -0500 Subject: [arin-tech-discuss] arinrws-schema to java objects Message-ID: hi, can any of you let me know how to generate java objects from the schema. thank you Warm wishes, Krishna -------------- next part -------------- An HTML attachment was scrubbed... URL: From shellboy at ebhakt.info Sat Nov 16 08:26:28 2013 From: shellboy at ebhakt.info (shellboy at ebhakt.info) Date: Sat, 16 Nov 2013 05:26:28 -0800 Subject: [arin-tech-discuss] arinrws-schema to java objects Message-ID: <11061eb326f726a636d969f86fbd2390@ebhakt.info> hi, can any of you let me know how to generate java objects from the schema. thank you? Warm wishes, Krishna ? _______________________________________________ arin-tech-discuss mailing list arin-tech-discuss at arin.net http://lists.arin.net/mailman/listinfo/arin-tech-discuss From droisman at softlayer.com Sat Nov 16 23:10:11 2013 From: droisman at softlayer.com (Dani Roisman) Date: Sun, 17 Nov 2013 04:10:11 +0000 Subject: [arin-tech-discuss] FW: [ARIN-20131116.48] SERVFAIL replies in 174.in-addr.arpa. - Ref Ticket 7871618 Message-ID: Greetings, We have not seen a reply from ARIN yet on this ticket, I'm sending to the tech-discuss list to see if anyone else has experienced this today and can offer some guidance? Please note that our NOC isn't on this distro, so as you reply, please copy noc at softlayer.com ---- Dani Roisman VP, Network Operations SoftLayer, an IBM Company 315 Capitol Street Suite 205, Houston, TX 77002 From: ARIN Ticketing System [mailto:do-not-reply at arin.net] Sent: Saturday, November 16, 2013 10:33 To: Ticket Logger Cc: NOC - SoftLayer Subject: Re:[ARIN-20131116.48] SERVFAIL replies in 174.in-addr.arpa. - Ref Ticket 7871618 There appears to have been some sort of key roll over issue with 174.in-addr.arpa. This is causing SERVFAIL replies from validating DNS resolvers for anything in 174.in-addr.arpa. The in-addr.arpa zone contains a single DS key with the ID 7353. This is true for the zone that is currently being served. Truncated dig(1) output: 174.in-addr.arpa. 86400 IN DS 7353 5 1 2096BD9C5612836870ADCCBDD68A957CB6487F34 ;; Received 70 bytes from 2001:500:87::87#53(2001:500:87::87) in 60 ms This same record appears on line 946 (byte offset: 85175) in the in-addr.arpa zone file that's available ftp.internic.net (time stamp: Nov 16 04:34): 174.in-addr.arpa. 86400 IN DS 7353 5 1 2096BD9C5612836870ADCCBDD68A957CB6487F34 Unfortunately, the two keys that are available in the 174.in-addr.arpa zone, as served by z.arin.net, have id's of 19034 and 39420: 174.in-addr.arpa. 14400 IN DNSKEY 256 3 5 ( BQEAAAABtReA/SI3OKJpKhRDt5FfaXAsrQSO9a2zpxVY ZqP0z+ONdbw7aBaibwSC5Itly1foVXeZbTx3TkF8AAT3 0Aa/8au4KV26TDQ6o3awY087f7rspZld8OR/fh44HV3o puzIkeyh8PEb91rkCkAjkxqNavuEbL1OzT8wf8x+2L3p x5c= ) ; key id = 19034 174.in-addr.arpa. 14400 IN DNSKEY 257 3 5 ( BQEAAAABqELZSV55GgyN/BvBbtLlz7xzP341SyAcBqkI 87QVGiFt3PzKdNlw7NU5BeZ9Oo7aMih/5afr2RfZB50M cREP1TUhCOf2WSoCA2l7VFpC/eG0NO1EFSiqmxJVOJ61 XNZG0c0yPvmvz6jVbwLUGeIzEOHQy2bZNYc9lzP7fbKQ 4WLIwqQnS7iwkVaZtmub0WI+2ybCe27Xr+W/b1CwhTww mgCJegmb/xQMGwF3zR059i+adsPy8meveGKczf7R26mV pyynDJHFDTdBzVQH2ubGCZ3Qfnby1xq6xoNkcMUGMopQ mHDcPQFW2IZf667ijh2oSrns18vugXlFPtT33IFMNw== ) ; key id = 39420 I have verified my findings with two DNSSEC validation tools: Sandia National Labs: http://dnsviz.net/d/174.in-addr.arpa/dnssec/ Verisign: http://dnssec-debugger.verisignlabs.com/174.in-addr.arpa Finally, ICANN's in-addr.arpa DNSSEC Report for 15 and 16 Nov indicate an issue with the zone (Signed NO, DS Key YES): 15th: http://stats.research.icann.org/dns/inaddr_report/archive/20131115.003001.html 16th: http://stats.research.icann.org/dns/inaddr_report/archive/20131116.003001.html While the report from the 14th says everything was working fine (Signed YES, DS Key YES): http://stats.research.icann.org/dns/inaddr_report/archive/20131114.003002.html I don't have historical copies of the zones to know for sure what has happened, but my educated guess is that the DNSKEY records changed in 174.in-addr.arpa during key roll-over, but the DS key in the parent zone hasn't been updated. If that is what has happened, then either publishing a new DS key in the parent (in-addr.arpa.) zone, or publishing 7353 dns key and re-signing 174.in-addr.arpa zone correct the issue. Thank you for your time and attention to this matter. --- Christopher Price Network Operations Center SoftLayer, an IBM Company +1(281)714-3555 direct | +1(214)442-0600 main | noc at softlayer.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From matt at arin.net Sun Nov 17 01:52:48 2013 From: matt at arin.net (Matt Rowley) Date: Sun, 17 Nov 2013 01:52:48 -0500 Subject: [arin-tech-discuss] FW: [ARIN-20131116.48] SERVFAIL replies in 174.in-addr.arpa. - Ref Ticket 7871618 In-Reply-To: References: Message-ID: <528867C0.2050606@arin.net> Hi Dani, Sorry for this problem. The fix has been published. You can see the fixed chain of trust via: http://dnssec-debugger.verisignlabs.com/174.in-addr.arpa Again our apologies for this, and thanks for reaching out to us to let us know. Please let us know if you have any questions. Incidentally, you can also reach us at dns-ops at arin.net. cheers, Matt Rowley > From: Dani Roisman > Date: Sat, Nov 16, 2013 at 11:10 PM > Subject: [arin-tech-discuss] FW: [ARIN-20131116.48] SERVFAIL replies in > 174.in-addr.arpa. - Ref Ticket 7871618 > To: "arin-tech-discuss at arin.net" > Cc: NOC - SoftLayer > > > Greetings, > > > > We have not seen a reply from ARIN yet on this ticket, I?m sending to the > tech-discuss list to see if anyone else has experienced this today and can > offer some guidance? Please note that our NOC isn?t on this distro, so as > you reply, please copy noc at softlayer.com > > > > > > *----* > > Dani Roisman > > VP, Network Operations > > > > *SoftLayer, an IBM Company* > > 315 Capitol Street Suite 205, Houston, TX 77002 > > > > > > *From:* ARIN Ticketing System [mailto:do-not-reply at arin.net] > *Sent:* Saturday, November 16, 2013 10:33 > *To:* Ticket Logger > *Cc:* NOC - SoftLayer > *Subject:* Re:[ARIN-20131116.48] SERVFAIL replies in 174.in-addr.arpa. - > Ref Ticket 7871618 > > > > There appears to have been some sort of key roll over issue with > 174.in-addr.arpa. This is causing SERVFAIL replies from validating DNS > resolvers for anything in 174.in-addr.arpa. > > > > The in-addr.arpa zone contains a single DS key with the ID 7353. This is > true for the zone that is currently being served. Truncated dig(1) output: > > > > 174.in-addr.arpa. 86400 IN > > DS 7353 5 1 2096BD9C5612836870ADCCBDD68A957CB6487F34 > > ;; Received 70 bytes from 2001:500:87::87#53(2001:500:87::87) in 60 ms > > > > This same record appears on line 946 (byte offset: 85175) in the > in-addr.arpa zone file that's available ftp.internic.net (time stamp: Nov > 16 04:34): > > > > 174.in-addr.arpa. 86400 IN > > DS 7353 5 1 2096BD9C5612836870ADCCBDD68A957CB6487F34 > > > > > > Unfortunately, the two keys that are available in the 174.in-addr.arpa > zone, as served by z.arin.net, have id's of 19034 and 39420: > > > > 174.in-addr.arpa. 14400 IN DNSKEY 256 3 5 ( > > BQEAAAABtReA/SI3OKJpKhRDt5FfaXAsrQSO9a2zpxVY > > ZqP0z+ONdbw7aBaibwSC5Itly1foVXeZbTx3TkF8AAT3 > > 0Aa/8au4KV26TDQ6o3awY087f7rspZld8OR/fh44HV3o > > puzIkeyh8PEb91rkCkAjkxqNavuEbL1OzT8wf8x+2L3p > > x5c= > > ) ; key id = 19034 > > 174.in-addr.arpa. 14400 IN DNSKEY 257 3 5 ( > > BQEAAAABqELZSV55GgyN/BvBbtLlz7xzP341SyAcBqkI > > 87QVGiFt3PzKdNlw7NU5BeZ9Oo7aMih/5afr2RfZB50M > > cREP1TUhCOf2WSoCA2l7VFpC/eG0NO1EFSiqmxJVOJ61 > > XNZG0c0yPvmvz6jVbwLUGeIzEOHQy2bZNYc9lzP7fbKQ > > 4WLIwqQnS7iwkVaZtmub0WI+2ybCe27Xr+W/b1CwhTww > > mgCJegmb/xQMGwF3zR059i+adsPy8meveGKczf7R26mV > > pyynDJHFDTdBzVQH2ubGCZ3Qfnby1xq6xoNkcMUGMopQ > > mHDcPQFW2IZf667ijh2oSrns18vugXlFPtT33IFMNw== > > ) ; key id = 39420 > > I have verified my findings with two DNSSEC validation tools: > > > > Sandia National Labs: > > http://dnsviz.net/d/174.in-addr.arpa/dnssec/ > > > > Verisign: > > http://dnssec-debugger.verisignlabs.com/174.in-addr.arpa > > > > > > Finally, ICANN's in-addr.arpa DNSSEC Report for 15 and 16 Nov indicate an > issue with the zone (Signed NO, DS Key YES): > > > > 15th: > > http://stats.research.icann.org/dns/inaddr_report/archive/20131115.003001.html > > > > 16th: > > http://stats.research.icann.org/dns/inaddr_report/archive/20131116.003001.html > > > > While the report from the 14th says everything was working fine (Signed > YES, DS Key YES): > > http://stats.research.icann.org/dns/inaddr_report/archive/20131114.003002.html > > > > I don't have historical copies of the zones to know for sure what has > happened, but my educated guess is that the DNSKEY records changed in > 174.in-addr.arpa during key roll-over, but the DS key in the parent zone > hasn't been updated. > > > > If that is what has happened, then either publishing a new DS key in the > parent (in-addr.arpa.) zone, or publishing 7353 dns key and re-signing > 174.in-addr.arpa zone correct the issue. > > > > > > Thank you for your time and attention to this matter. > > > > --- > > *Christopher Price* > > Network Operations Center > > > > *SoftLayer, an IBM Company* > > +1(281)714-3555 direct | +1(214)442-0600 main | noc at softlayer.com > > > > _______________________________________________ > arin-tech-discuss mailing list > arin-tech-discuss at arin.net > http://lists.arin.net/mailman/listinfo/arin-tech-discuss > From brak at gameservers.com Fri Nov 22 08:57:16 2013 From: brak at gameservers.com (Brian Rak) Date: Fri, 22 Nov 2013 08:57:16 -0500 Subject: [arin-tech-discuss] IPv6 Alternative to Reassignment Report? In-Reply-To: <62D9228640AC7F49B2DD9ED0C9CE60E5E2DF4BE2@CHAXCH01.corp.arin.net> References: <62D9228640AC7F49B2DD9ED0C9CE60E5E2DF4BE2@CHAXCH01.corp.arin.net> Message-ID: <528F62BC.7020006@gameservers.com> Any progress on implementing this? On 6/12/2013 4:54 PM, Andy Newton wrote: > On 6/12/13 3:53 PM, "Brian Rak" wrote: > >> Is there any alternative to the Reassignment Report that works with IPv6? >> >> We use this report as part of our SWIP process, as it's the only real >> way to get a list of all the reassignments that ARIN knows about. Using >> the whois api with /children is not really something that is useful, as >> it's limited to 256 entries. > Brian, > > Unfortunately the reassignments report doesn't work with IPv6 resources. > We consider this an oversight, and I have entered an issue in our bug > tracking system to have it rectified. > > Sorry for the confusion and the inconvenience. > > Andy Newton, > Chief Engineer, ARIN > From brak at gameservers.com Fri Nov 22 10:50:48 2013 From: brak at gameservers.com (Brian Rak) Date: Fri, 22 Nov 2013 10:50:48 -0500 Subject: [arin-tech-discuss] SWIP and GeoIP In-Reply-To: <5254197F.3040803@gameservers.com> References: <5254197F.3040803@gameservers.com> Message-ID: <528F7D58.7070702@gameservers.com> So, for lack of a better option we've taken the step of creating an ORGID for each location, and assigning subnets to that. We'll have to wait and see how it works out... On 10/8/2013 10:41 AM, Brian Rak wrote: > We have a customer who operates VPN services with us. They have their > own ARIN OrgID, and we would like to be able to reassign all their IP > addresses to that organization (so that they can receive any abuse > reports directly, rather then having to relay them). > > They have reported to us that various GeoIP providers are using the > location of the ARIN contact to determine where an IP is located. The > customer would very much prefer that the location of the IPs match the > datacenter's location, rather then the customer's location. > > Does anyone have suggestions for handling this properly? Looking at > the data returned by WHOIS, it seems the only way they're going to be > able to specify a location is by creating a separate organization and > contact for each datacenter. Is that the best solution here? > _______________________________________________ > arin-tech-discuss mailing list > arin-tech-discuss at arin.net > http://lists.arin.net/mailman/listinfo/arin-tech-discuss From andy at arin.net Fri Nov 22 16:25:54 2013 From: andy at arin.net (Andy Newton) Date: Fri, 22 Nov 2013 21:25:54 +0000 Subject: [arin-tech-discuss] IPv6 Alternative to Reassignment Report? In-Reply-To: <528F62BC.7020006@gameservers.com> Message-ID: Brian, This fix will be in our next planned release, which is scheduled for December 14. Andy Newton, Chief Engineer, ARIN On 11/22/13 8:57 AM, "Brian Rak" wrote: >Any progress on implementing this? > >On 6/12/2013 4:54 PM, Andy Newton wrote: >> On 6/12/13 3:53 PM, "Brian Rak" wrote: >> >>> Is there any alternative to the Reassignment Report that works with >>>IPv6? >>> >>> We use this report as part of our SWIP process, as it's the only real >>> way to get a list of all the reassignments that ARIN knows about. >>>Using >>> the whois api with /children is not really something that is useful, as >>> it's limited to 256 entries. >> Brian, >> >> Unfortunately the reassignments report doesn't work with IPv6 resources. >> We consider this an oversight, and I have entered an issue in our bug >> tracking system to have it rectified. >> >> Sorry for the confusion and the inconvenience. >> >> Andy Newton, >> Chief Engineer, ARIN >> > > From andy at arin.net Fri Nov 22 17:16:46 2013 From: andy at arin.net (Andy Newton) Date: Fri, 22 Nov 2013 22:16:46 +0000 Subject: [arin-tech-discuss] SWIP and GeoIP In-Reply-To: <528F7D58.7070702@gameservers.com> Message-ID: Brian, For what it is worth, Google has a proposal implemented by a handful for network operators called GeoFeeds. They are currently attempting to have this adopted by the IETF GEOPRIV working group so that it is an RFC. Their current document is here: http://tools.ietf.org/html/draft-google-self-published-geofeeds-02 At present, reporting of the geofeeds is very manual and adhoc, but their hope is to have a standardized way for discovery of these feeds (ideas are documented in their draft). Andy Newton, Chief Engineer, ARIN On 11/22/13 10:50 AM, "Brian Rak" wrote: >So, for lack of a better option we've taken the step of creating an >ORGID for each location, and assigning subnets to that. We'll have to >wait and see how it works out... > >On 10/8/2013 10:41 AM, Brian Rak wrote: >> We have a customer who operates VPN services with us. They have their >> own ARIN OrgID, and we would like to be able to reassign all their IP >> addresses to that organization (so that they can receive any abuse >> reports directly, rather then having to relay them). >> >> They have reported to us that various GeoIP providers are using the >> location of the ARIN contact to determine where an IP is located. The >> customer would very much prefer that the location of the IPs match the >> datacenter's location, rather then the customer's location. >> >> Does anyone have suggestions for handling this properly? Looking at >> the data returned by WHOIS, it seems the only way they're going to be >> able to specify a location is by creating a separate organization and >> contact for each datacenter. Is that the best solution here? >> _______________________________________________ >> arin-tech-discuss mailing list >> arin-tech-discuss at arin.net >> http://lists.arin.net/mailman/listinfo/arin-tech-discuss > >_______________________________________________ >arin-tech-discuss mailing list >arin-tech-discuss at arin.net >http://lists.arin.net/mailman/listinfo/arin-tech-discuss > From jayb at braeburn.org Mon Nov 25 15:09:38 2013 From: jayb at braeburn.org (Jay Borkenhagen) Date: Mon, 25 Nov 2013 15:09:38 -0500 Subject: [arin-tech-discuss] ARIN RPKI: smooth transition from hosted to delegated? Message-ID: <21139.44674.635649.117375@oz.mt.att.com> ARIN, Regarding https://www.arin.net/resources/rpki/index.html: Suppose a resource holder starts off using the Hosted RPKI model and later wishes to transition to Delegated RPKI. Can this transition be structured in a make-before-break manner, such that no disruption in validation status is experienced? Thank you. Jay B. From andy at arin.net Mon Nov 25 16:44:08 2013 From: andy at arin.net (Andy Newton) Date: Mon, 25 Nov 2013 21:44:08 +0000 Subject: [arin-tech-discuss] ARIN RPKI: smooth transition from hosted to delegated? In-Reply-To: <21139.44674.635649.117375@oz.mt.att.com> Message-ID: Jay, Unfortunately our system does not have the proper set of features to allow make-before-break when moving from hosted RPKI to delegated RPKI. Currently moving from hosted to delegated requires revocation of the CA certificate in the RPKI and re-issuance of a new certificate. If this is a feature you would like to have considered for implementation by ARIN, please submit it as a suggestion via the ARIN Consultation and Suggestion Process. The one page form for submitting ACSP suggestions can be found here: https://www.arin.net/app/suggestion/ I hope this answers your question. Let me know if it does not. Andy Newton, Chief Engineer, ARIN On 11/25/13 3:09 PM, "Jay Borkenhagen" wrote: >ARIN, > >Regarding https://www.arin.net/resources/rpki/index.html: > >Suppose a resource holder starts off using the Hosted RPKI model and >later wishes to transition to Delegated RPKI. Can this transition be >structured in a make-before-break manner, such that no disruption in >validation status is experienced? > >Thank you. > > Jay B. > > >_______________________________________________ >arin-tech-discuss mailing list >arin-tech-discuss at arin.net >http://lists.arin.net/mailman/listinfo/arin-tech-discuss >