From maurice at shq.nl Tue Aug 6 13:59:45 2013 From: maurice at shq.nl (Maurice [SHQ]) Date: Tue, 6 Aug 2013 13:59:45 +0200 Subject: [ncc-services-wg] https://www.ripe.net/ripe/policies/proposals/2013-04 Message-ID: <1A0070A2-5C81-48AD-87EC-E9F981CA623C@shq.nl> https://www.ripe.net/ripe/policies/proposals/2013-04 Support +1 Met vriendelijke groet, Maurice SHQ B.V. Sterk in e-commerce hosting Klantenservice Nederland: 0165-201005 Klantenservice Belgie: 03-8081633 klantenservice at shq.nl / www.shq.nl Postadres: Ekelstraat 3 4726AN Heerle - NB Op al onze diensten en leveringen zijn onze algemene voorwaarden van toepassing. SHQ.nl is onderdeel van Trafego IS B.V. - KVK Breda: 58096140 -------------- next part -------------- An HTML attachment was scrubbed... URL: From denis at ripe.net Thu Aug 8 11:52:24 2013 From: denis at ripe.net (Denis Walker) Date: Thu, 08 Aug 2013 11:52:24 +0200 Subject: [ncc-services-wg] [db-wg] New RIPE Database Release Available Soon In-Reply-To: <1E0F2F52-381D-4496-8F9D-6E4881305439@ripe.net> References: <1E0F2F52-381D-4496-8F9D-6E4881305439@ripe.net> Message-ID: <52036A58.3050502@ripe.net> Dear Colleagues The features and changes outlined below have now been fully deployed to the RIPE Database. Regards Denis Walker Business Analyst RIPE NCC Database Team On 16/07/2013 15:10, Johan ?hl?n wrote: > Dear colleagues, > > We are pleased to announce that a new release of the RIPE Database will > be available soon. Details about the upcoming release, including dates, > descriptions of the changes and other factors that might affect you as a > user, can be found here: > https://www.ripe.net/data-tools/db/release-notes/ripe-database-release-1.67.4 > > The first new feature is a diff functionality, which allows you to see, > in detail, what changes were made between two versions of an object in > the RIPE Database. Head over to RIPE Labs to read more about the diff > feature: > https://labs.ripe.net/Members/denis/diff-functionality-in-the-ripe-database > > We have also improved the way the Global Resource Service (GRS) data is > imported. This allows us to present a more complete data set for all > Internet resources throughout the world. This RIPE Labs article will > bring you up to speed on the GRS improvements: > https://labs.ripe.net/Members/denis/the-ripe-global-resource-service > > Lastly, we have also made several improvements to the REST API. As there > are some changes, the new implementation will be deployed and running in > parallel to the old version up until the next release. This provides you > with time to verify your software and scripts against the new release. > The implications of these changes are described in the release notes > linked above. > > If you have any questions or comments, we look forward to hearing them! > > Kind regards, > > Johan ?hl?n > Assistant Manager Database > RIPE NCC From rv at NIC.DTAG.DE Thu Aug 15 14:52:03 2013 From: rv at NIC.DTAG.DE (Ruediger Volk, Deutsche Telekom Technik - FMED-41..) Date: Thu, 15 Aug 2013 14:52:03 +0200 Subject: [ncc-services-wg] [db-wg] Urgent release of RIPE Database software In-Reply-To: Your message of "Thu, 15 Aug 2013 11:18:49 +0200." <418424A5-9F35-4D8E-AE14-F96689E4C990@ripe.net> Message-ID: <6795.1376571123@x37.NIC.DTAG.DE> Dear Johan, thanks a lot for the new much more transparent mode of software version management for the RIPE data base service. This is a huge improvement. Nevertheless I think that we need continued discussion in the community to improve mutual understanding of considerations and impact. Your message today brings up few consideratiosn from me (a bit more tuned to the general pro cess than the specific case). > We were recently made aware of some issues with the documentation > related to the REST API. To fix these issues requires a new release of > the Database software as some parts of the documentation are generated > from the active code. The documentation is vital for anyone wanting to > use the service. We therefore believe it is necessary to make a new > release containing this fix only and deploy it directly to production > later today. The problem description does NOT read like there IS ACTUAL SERVICE IMPACT at the moment; looking at the RIPE NCC service status page seems to confirm since it reports "no known problems" and no ser vice announcements either. Doing a software version change with less than a day advance notice certainly can be appropriate as an "emergency update" to deal with some service impact. How much harm is done if fix to the documentation is done a few days later while a note is posted indicating that certain errors will be fixed in the near future... ? > In this particular case we don=92t believe it is necessary to put the > release in test beforehand. The only fix is for the documentation and > this is preventing users form using the service, so it's quite urgent. > This fix should have no impact on any other part of the RIPE Database > service. I am tempted to believe your assessment; I dont have access to the changes and the resources to do my own full assessment. As I did experience 3 service impacting bugs within 12 months with UNannounced version changes I conclude that I rather see than believe. I certainly do see a need to watch more carefully how software behaves after ANY change and a non zero probability of some surprise (that could result in service impact for me). Note: knowing the schedule of upcoming changes some time in advance can be more important than actually having the ability to run tests (like due to IETF timing I could not run tests against the test server with 1.67.4 - but we did schedule preparation of critical production runs in a way that protected us against potential surprises due to the software change.) > If you have any questions then please let us know. > > Kind regards, > > Johan =C5hl=E9n > Assistant Manager Database > RIPE NCC= Best regards, Ruediger Ruediger Volk Deutsche Telekom AG -- Internet Backbone Engineering E-Mail: rv at NIC.DTAG.DE From jahlen at ripe.net Thu Aug 15 15:27:58 2013 From: jahlen at ripe.net (=?iso-8859-1?Q?Johan_=C5hl=E9n?=) Date: Thu, 15 Aug 2013 15:27:58 +0200 Subject: [ncc-services-wg] [db-wg] Urgent release of RIPE Database software In-Reply-To: <6795.1376571123@x37.NIC.DTAG.DE> References: <6795.1376571123@x37.NIC.DTAG.DE> Message-ID: <5F24B37A-77BB-4F15-8138-BD0FE3BA9C35@ripe.net> Dear Ruediger, Thank you for the input. As you are all aware the release procedure is new and does require some tuning, so in that aspect any suggestions on how we can improve this are welcome. In this particular situation our assessment is that the broken links in the documentation indeed has a service impact. For some users this could be critical as they may not be able to use the REST API service. At least one case was reported to us where the development towards the API has come to a halt because of this. Perhaps in this case we can hold the deployment of the fix until the working group advices us on how to proceed. Kind regards, Johan ?hl?n Assistant Database Manager RIPE NCC On 15 Aug 2013, at 14:52, "Ruediger Volk, Deutsche Telekom Technik - FMED-41.." wrote: > Dear Johan, > > thanks a lot for the new much more transparent mode of software > version management for the RIPE data base service. > This is a huge improvement. > > Nevertheless I think that we need continued discussion in the community to > improve mutual understanding of considerations and impact. > > Your message today brings up few consideratiosn from me > (a bit more tuned to the general pro cess than the specific case). > >> We were recently made aware of some issues with the documentation >> related to the REST API. To fix these issues requires a new release of >> the Database software as some parts of the documentation are generated >> from the active code. The documentation is vital for anyone wanting to >> use the service. We therefore believe it is necessary to make a new >> release containing this fix only and deploy it directly to production >> later today. > The problem description does NOT read like there IS ACTUAL SERVICE IMPACT > at the moment; looking at the RIPE NCC service status page seems to confirm > since it reports "no known problems" and no ser vice announcements either. > > Doing a software version change with less than a day advance notice certainly > can be appropriate as an "emergency update" to deal with some service impact. > How much harm is done if fix to the documentation is done a few days later > while a note is posted indicating that certain errors will be fixed > in the near future... ? > >> In this particular case we don=92t believe it is necessary to put the >> release in test beforehand. The only fix is for the documentation and >> this is preventing users form using the service, so it's quite urgent. >> This fix should have no impact on any other part of the RIPE Database >> service. > I am tempted to believe your assessment; I dont have access to the changes > and the resources to do my own full assessment. > As I did experience 3 service impacting bugs within 12 months with > UNannounced version changes I conclude that I rather see than believe. > I certainly do see a need to watch more carefully how software behaves > after ANY change and a non zero probability of some surprise > (that could result in service impact for me). > > Note: knowing the schedule of upcoming changes some time in advance > can be more important than actually having the ability to run tests > (like due to IETF timing I could not run tests against the test server with > 1.67.4 - but we did schedule preparation of critical production runs in > a way that protected us against potential surprises due to the software change.) > >> If you have any questions then please let us know. >> >> Kind regards, >> >> Johan =C5hl=E9n >> Assistant Manager Database >> RIPE NCC= > Best regards, > Ruediger > > > Ruediger Volk > > Deutsche Telekom AG -- Internet Backbone Engineering > > E-Mail: rv at NIC.DTAG.DE > From job.snijders at atrato.com Thu Aug 15 15:32:09 2013 From: job.snijders at atrato.com (Job Snijders) Date: Thu, 15 Aug 2013 15:32:09 +0200 Subject: [ncc-services-wg] [db-wg] Urgent release of RIPE Database software In-Reply-To: <5F24B37A-77BB-4F15-8138-BD0FE3BA9C35@ripe.net> References: <6795.1376571123@x37.NIC.DTAG.DE> <5F24B37A-77BB-4F15-8138-BD0FE3BA9C35@ripe.net> Message-ID: Hi, Any reason not to deploy on test environmen, wait 24 hours, proceed to roll out on production environment? Kind regards, Job On Aug 15, 2013, at 3:27 PM, Johan ?hl?n wrote: > Dear Ruediger, > > Thank you for the input. As you are all aware the release procedure is new and does require some tuning, so in that aspect any suggestions on how we can improve this are welcome. > > In this particular situation our assessment is that the broken links in the documentation indeed has a service impact. For some users this could be critical as they may not be able to use the REST API service. At least one case was reported to us where the development towards the API has come to a halt because of this. > > Perhaps in this case we can hold the deployment of the fix until the working group advices us on how to proceed. > > Kind regards, > > Johan ?hl?n > Assistant Database Manager > RIPE NCC > > On 15 Aug 2013, at 14:52, "Ruediger Volk, Deutsche Telekom Technik - FMED-41.." wrote: > >> Dear Johan, >> >> thanks a lot for the new much more transparent mode of software >> version management for the RIPE data base service. >> This is a huge improvement. >> >> Nevertheless I think that we need continued discussion in the community to >> improve mutual understanding of considerations and impact. >> >> Your message today brings up few consideratiosn from me >> (a bit more tuned to the general pro cess than the specific case). >> >>> We were recently made aware of some issues with the documentation >>> related to the REST API. To fix these issues requires a new release of >>> the Database software as some parts of the documentation are generated >>> from the active code. The documentation is vital for anyone wanting to >>> use the service. We therefore believe it is necessary to make a new >>> release containing this fix only and deploy it directly to production >>> later today. >> The problem description does NOT read like there IS ACTUAL SERVICE IMPACT >> at the moment; looking at the RIPE NCC service status page seems to confirm >> since it reports "no known problems" and no ser vice announcements either. >> >> Doing a software version change with less than a day advance notice certainly >> can be appropriate as an "emergency update" to deal with some service impact. >> How much harm is done if fix to the documentation is done a few days later >> while a note is posted indicating that certain errors will be fixed >> in the near future... ? >> >>> In this particular case we don=92t believe it is necessary to put the >>> release in test beforehand. The only fix is for the documentation and >>> this is preventing users form using the service, so it's quite urgent. >>> This fix should have no impact on any other part of the RIPE Database >>> service. >> I am tempted to believe your assessment; I dont have access to the changes >> and the resources to do my own full assessment. >> As I did experience 3 service impacting bugs within 12 months with >> UNannounced version changes I conclude that I rather see than believe. >> I certainly do see a need to watch more carefully how software behaves >> after ANY change and a non zero probability of some surprise >> (that could result in service impact for me). >> >> Note: knowing the schedule of upcoming changes some time in advance >> can be more important than actually having the ability to run tests >> (like due to IETF timing I could not run tests against the test server with >> 1.67.4 - but we did schedule preparation of critical production runs in >> a way that protected us against potential surprises due to the software change.) >> >>> If you have any questions then please let us know. >>> >>> Kind regards, >>> >>> Johan =C5hl=E9n >>> Assistant Manager Database >>> RIPE NCC= >> Best regards, >> Ruediger >> >> >> Ruediger Volk >> >> Deutsche Telekom AG -- Internet Backbone Engineering >> >> E-Mail: rv at NIC.DTAG.DE >> > > -- AS5580 - Atrato IP Networks -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 841 bytes Desc: Message signed with OpenPGP using GPGMail URL: From tgarrison at softlayer.com Thu Aug 15 15:37:18 2013 From: tgarrison at softlayer.com (Tim Garrison) Date: Thu, 15 Aug 2013 08:37:18 -0500 Subject: [ncc-services-wg] [db-wg] Urgent release of RIPE Database software In-Reply-To: References: <6795.1376571123@x37.NIC.DTAG.DE> <5F24B37A-77BB-4F15-8138-BD0FE3BA9C35@ripe.net> Message-ID: <520CD98E.6010309@softlayer.com> That seems like a reasonable approach to me. Tim Garrison Software Engineer III *SoftLayer, an IBM Company* 315 Capitol Street Suite 205, Houston, TX 77002 281.714.4213 direct | 713.540.4325 mobile | 281.714.4657 fax | tgarrison at softlayer.com On 08/15/2013 08:32 AM, Job Snijders wrote: > Hi, > > Any reason not to deploy on test environmen, wait 24 hours, proceed to roll out on production environment? > > Kind regards, > > Job > > On Aug 15, 2013, at 3:27 PM, Johan ?hl?n wrote: > >> Dear Ruediger, >> >> Thank you for the input. As you are all aware the release procedure is new and does require some tuning, so in that aspect any suggestions on how we can improve this are welcome. >> >> In this particular situation our assessment is that the broken links in the documentation indeed has a service impact. For some users this could be critical as they may not be able to use the REST API service. At least one case was reported to us where the development towards the API has come to a halt because of this. >> >> Perhaps in this case we can hold the deployment of the fix until the working group advices us on how to proceed. >> >> Kind regards, >> >> Johan ?hl?n >> Assistant Database Manager >> RIPE NCC >> >> On 15 Aug 2013, at 14:52, "Ruediger Volk, Deutsche Telekom Technik - FMED-41.." wrote: >> >>> Dear Johan, >>> >>> thanks a lot for the new much more transparent mode of software >>> version management for the RIPE data base service. >>> This is a huge improvement. >>> >>> Nevertheless I think that we need continued discussion in the community to >>> improve mutual understanding of considerations and impact. >>> >>> Your message today brings up few consideratiosn from me >>> (a bit more tuned to the general pro cess than the specific case). >>> >>>> We were recently made aware of some issues with the documentation >>>> related to the REST API. To fix these issues requires a new release of >>>> the Database software as some parts of the documentation are generated >>>> from the active code. The documentation is vital for anyone wanting to >>>> use the service. We therefore believe it is necessary to make a new >>>> release containing this fix only and deploy it directly to production >>>> later today. >>> The problem description does NOT read like there IS ACTUAL SERVICE IMPACT >>> at the moment; looking at the RIPE NCC service status page seems to confirm >>> since it reports "no known problems" and no ser vice announcements either. >>> >>> Doing a software version change with less than a day advance notice certainly >>> can be appropriate as an "emergency update" to deal with some service impact. >>> How much harm is done if fix to the documentation is done a few days later >>> while a note is posted indicating that certain errors will be fixed >>> in the near future... ? >>> >>>> In this particular case we don=92t believe it is necessary to put the >>>> release in test beforehand. The only fix is for the documentation and >>>> this is preventing users form using the service, so it's quite urgent. >>>> This fix should have no impact on any other part of the RIPE Database >>>> service. >>> I am tempted to believe your assessment; I dont have access to the changes >>> and the resources to do my own full assessment. >>> As I did experience 3 service impacting bugs within 12 months with >>> UNannounced version changes I conclude that I rather see than believe. >>> I certainly do see a need to watch more carefully how software behaves >>> after ANY change and a non zero probability of some surprise >>> (that could result in service impact for me). >>> >>> Note: knowing the schedule of upcoming changes some time in advance >>> can be more important than actually having the ability to run tests >>> (like due to IETF timing I could not run tests against the test server with >>> 1.67.4 - but we did schedule preparation of critical production runs in >>> a way that protected us against potential surprises due to the software change.) >>> >>>> If you have any questions then please let us know. >>>> >>>> Kind regards, >>>> >>>> Johan =C5hl=E9n >>>> Assistant Manager Database >>>> RIPE NCC= >>> Best regards, >>> Ruediger >>> >>> >>> Ruediger Volk >>> >>> Deutsche Telekom AG -- Internet Backbone Engineering >>> >>> E-Mail: rv at NIC.DTAG.DE >>> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From rv at nic.dtag.de Thu Aug 15 16:03:43 2013 From: rv at nic.dtag.de (Ruediger Volk, Deutsche Telekom Technik - FMED-41..) Date: Thu, 15 Aug 2013 16:03:43 +0200 Subject: [ncc-services-wg] [db-wg] Urgent release of RIPE Database software In-Reply-To: Your message of "Thu, 15 Aug 2013 15:32:09 +0200." Message-ID: <6883.1376575423@x37.NIC.DTAG.DE> Hi Job, Johan, I'm happy to see careful attention, improvements, and tuning for the new process. That needs to continue and I'd expect to have some discussion in Athens... > Hi, > > Any reason not to deploy on test environmen, wait 24 hours, proceed to > roll out on production environment? would seem to me: deploying the fix to the test environment would already solve the service impact (that Johan sees) ... if we can point potential readers of the documentation there... So sidestepping the test environment actually delays fixing the specific problem - while increasing risks for the production use... My take: no need and justification for rushing change on the production system. Kind regards, Ruediger Ruediger Volk Deutsche Telekom AG -- Internet Backbone Engineering E-Mail: rv at NIC.DTAG.DE From jahlen at ripe.net Thu Aug 15 16:10:07 2013 From: jahlen at ripe.net (=?iso-8859-1?Q?Johan_=C5hl=E9n?=) Date: Thu, 15 Aug 2013 16:10:07 +0200 Subject: [ncc-services-wg] [db-wg] Urgent release of RIPE Database software In-Reply-To: <520CD98E.6010309@softlayer.com> References: <6795.1376571123@x37.NIC.DTAG.DE> <5F24B37A-77BB-4F15-8138-BD0FE3BA9C35@ripe.net> <520CD98E.6010309@softlayer.com> Message-ID: Dear all, The release containing the fix is now available in the TEST Database and there's a service announcement on the web page. If there are no objections to this we will proceed with 24h in the TEST Database and put this release in production on the RIPE Database tomorrow at 16:00. Please go ahead and test your applications against the version in the TEST Database. The URL for the REST API in TEST is: http(s)://rest-test.db.ripe.net Kind regards, Johan ?hl?n Assistant Manager Database RIPE NCC On 15 Aug 2013, at 15:37, Tim Garrison wrote: > That seems like a reasonable approach to me. > > Tim Garrison > Software Engineer III > > SoftLayer, an IBM Company > 315 Capitol Street Suite 205, Houston, TX 77002 > 281.714.4213 direct | 713.540.4325 mobile | 281.714.4657 fax | tgarrison at softlayer.com > > On 08/15/2013 08:32 AM, Job Snijders wrote: >> Hi, >> >> Any reason not to deploy on test environmen, wait 24 hours, proceed to roll out on production environment? >> >> Kind regards, >> >> Job >> >> On Aug 15, 2013, at 3:27 PM, Johan ?hl?n wrote: >> >>> Dear Ruediger, >>> >>> Thank you for the input. As you are all aware the release procedure is new and does require some tuning, so in that aspect any suggestions on how we can improve this are welcome. >>> >>> In this particular situation our assessment is that the broken links in the documentation indeed has a service impact. For some users this could be critical as they may not be able to use the REST API service. At least one case was reported to us where the development towards the API has come to a halt because of this. >>> >>> Perhaps in this case we can hold the deployment of the fix until the working group advices us on how to proceed. >>> >>> Kind regards, >>> >>> Johan ?hl?n >>> Assistant Database Manager >>> RIPE NCC >>> >>> On 15 Aug 2013, at 14:52, "Ruediger Volk, Deutsche Telekom Technik - FMED-41.." wrote: >>> >>>> Dear Johan, >>>> >>>> thanks a lot for the new much more transparent mode of software >>>> version management for the RIPE data base service. >>>> This is a huge improvement. >>>> >>>> Nevertheless I think that we need continued discussion in the community to >>>> improve mutual understanding of considerations and impact. >>>> >>>> Your message today brings up few consideratiosn from me >>>> (a bit more tuned to the general pro cess than the specific case). >>>> >>>>> We were recently made aware of some issues with the documentation >>>>> related to the REST API. To fix these issues requires a new release of >>>>> the Database software as some parts of the documentation are generated >>>>> from the active code. The documentation is vital for anyone wanting to >>>>> use the service. We therefore believe it is necessary to make a new >>>>> release containing this fix only and deploy it directly to production >>>>> later today. >>>> The problem description does NOT read like there IS ACTUAL SERVICE IMPACT >>>> at the moment; looking at the RIPE NCC service status page seems to confirm >>>> since it reports "no known problems" and no ser vice announcements either. >>>> >>>> Doing a software version change with less than a day advance notice certainly >>>> can be appropriate as an "emergency update" to deal with some service impact. >>>> How much harm is done if fix to the documentation is done a few days later >>>> while a note is posted indicating that certain errors will be fixed >>>> in the near future... ? >>>> >>>>> In this particular case we don=92t believe it is necessary to put the >>>>> release in test beforehand. The only fix is for the documentation and >>>>> this is preventing users form using the service, so it's quite urgent. >>>>> This fix should have no impact on any other part of the RIPE Database >>>>> service. >>>> I am tempted to believe your assessment; I dont have access to the changes >>>> and the resources to do my own full assessment. >>>> As I did experience 3 service impacting bugs within 12 months with >>>> UNannounced version changes I conclude that I rather see than believe. >>>> I certainly do see a need to watch more carefully how software behaves >>>> after ANY change and a non zero probability of some surprise >>>> (that could result in service impact for me). >>>> >>>> Note: knowing the schedule of upcoming changes some time in advance >>>> can be more important than actually having the ability to run tests >>>> (like due to IETF timing I could not run tests against the test server with >>>> 1.67.4 - but we did schedule preparation of critical production runs in >>>> a way that protected us against potential surprises due to the software change.) >>>> >>>>> If you have any questions then please let us know. >>>>> >>>>> Kind regards, >>>>> >>>>> Johan =C5hl=E9n >>>>> Assistant Manager Database >>>>> RIPE NCC= >>>> Best regards, >>>> Ruediger >>>> >>>> >>>> Ruediger Volk >>>> >>>> Deutsche Telekom AG -- Internet Backbone Engineering >>>> >>>> E-Mail: rv at NIC.DTAG.DE >>>> >>> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tgarrison at softlayer.com Thu Aug 15 17:20:58 2013 From: tgarrison at softlayer.com (Tim Garrison) Date: Thu, 15 Aug 2013 10:20:58 -0500 Subject: [ncc-services-wg] [db-wg] Urgent release of RIPE Database software In-Reply-To: References: <6795.1376571123@x37.NIC.DTAG.DE> <5F24B37A-77BB-4F15-8138-BD0FE3BA9C35@ripe.net> <520CD98E.6010309@softlayer.com> Message-ID: <520CF1DA.1050907@softlayer.com> I would like to report that there appear to be some broken links in the documentation still. For example, on https://rest-test.db.ripe.net/api-doc/path__create.html there is a link to the "whois-resources" element, which points to https://rest-test.db.ripe.net/api-doc/el_ns0_whois-resources.html . This link produces a 404. Tim Garrison Software Engineer III *SoftLayer, an IBM Company* 315 Capitol Street Suite 205, Houston, TX 77002 281.714.4213 direct | 713.540.4325 mobile | 281.714.4657 fax | tgarrison at softlayer.com On 08/15/2013 09:10 AM, Johan ?hl?n wrote: > Dear all, > > The release containing the fix is now available in the TEST Database > and there's a service announcement on the web page. > > If there are no objections to this we will proceed with 24h in > the TEST Database and put this release in production on the RIPE > Database tomorrow at 16:00. Please go ahead and test your applications > against the version in the TEST Database. > > The URL for the REST API in TEST is: > > http(s)://rest-test.db.ripe.net > > Kind regards, > > Johan ?hl?n > Assistant Manager Database > RIPE NCC > > On 15 Aug 2013, at 15:37, Tim Garrison > wrote: > >> That seems like a reasonable approach to me. >> >> Tim Garrison >> Software Engineer III >> >> *SoftLayer, an IBM Company* >> 315 Capitol Street Suite 205, Houston, TX 77002 >> 281.714.4213 direct | 713.540.4325 mobile | 281.714.4657 fax | >> tgarrison at softlayer.com >> >> On 08/15/2013 08:32 AM, Job Snijders wrote: >>> Hi, >>> >>> Any reason not to deploy on test environmen, wait 24 hours, proceed to roll out on production environment? >>> >>> Kind regards, >>> >>> Job >>> >>> On Aug 15, 2013, at 3:27 PM, Johan ?hl?n wrote: >>> >>>> Dear Ruediger, >>>> >>>> Thank you for the input. As you are all aware the release procedure is new and does require some tuning, so in that aspect any suggestions on how we can improve this are welcome. >>>> >>>> In this particular situation our assessment is that the broken links in the documentation indeed has a service impact. For some users this could be critical as they may not be able to use the REST API service. At least one case was reported to us where the development towards the API has come to a halt because of this. >>>> >>>> Perhaps in this case we can hold the deployment of the fix until the working group advices us on how to proceed. >>>> >>>> Kind regards, >>>> >>>> Johan ?hl?n >>>> Assistant Database Manager >>>> RIPE NCC >>>> >>>> On 15 Aug 2013, at 14:52, "Ruediger Volk, Deutsche Telekom Technik - FMED-41.." wrote: >>>> >>>>> Dear Johan, >>>>> >>>>> thanks a lot for the new much more transparent mode of software >>>>> version management for the RIPE data base service. >>>>> This is a huge improvement. >>>>> >>>>> Nevertheless I think that we need continued discussion in the community to >>>>> improve mutual understanding of considerations and impact. >>>>> >>>>> Your message today brings up few consideratiosn from me >>>>> (a bit more tuned to the general pro cess than the specific case). >>>>> >>>>>> We were recently made aware of some issues with the documentation >>>>>> related to the REST API. To fix these issues requires a new release of >>>>>> the Database software as some parts of the documentation are generated >>>>>> from the active code. The documentation is vital for anyone wanting to >>>>>> use the service. We therefore believe it is necessary to make a new >>>>>> release containing this fix only and deploy it directly to production >>>>>> later today. >>>>> The problem description does NOT read like there IS ACTUAL SERVICE IMPACT >>>>> at the moment; looking at the RIPE NCC service status page seems to confirm >>>>> since it reports "no known problems" and no ser vice announcements either. >>>>> >>>>> Doing a software version change with less than a day advance notice certainly >>>>> can be appropriate as an "emergency update" to deal with some service impact. >>>>> How much harm is done if fix to the documentation is done a few days later >>>>> while a note is posted indicating that certain errors will be fixed >>>>> in the near future... ? >>>>> >>>>>> In this particular case we don=92t believe it is necessary to put the >>>>>> release in test beforehand. The only fix is for the documentation and >>>>>> this is preventing users form using the service, so it's quite urgent. >>>>>> This fix should have no impact on any other part of the RIPE Database >>>>>> service. >>>>> I am tempted to believe your assessment; I dont have access to the changes >>>>> and the resources to do my own full assessment. >>>>> As I did experience 3 service impacting bugs within 12 months with >>>>> UNannounced version changes I conclude that I rather see than believe. >>>>> I certainly do see a need to watch more carefully how software behaves >>>>> after ANY change and a non zero probability of some surprise >>>>> (that could result in service impact for me). >>>>> >>>>> Note: knowing the schedule of upcoming changes some time in advance >>>>> can be more important than actually having the ability to run tests >>>>> (like due to IETF timing I could not run tests against the test server with >>>>> 1.67.4 - but we did schedule preparation of critical production runs in >>>>> a way that protected us against potential surprises due to the software change.) >>>>> >>>>>> If you have any questions then please let us know. >>>>>> >>>>>> Kind regards, >>>>>> >>>>>> Johan =C5hl=E9n >>>>>> Assistant Manager Database >>>>>> RIPE NCC= >>>>> Best regards, >>>>> Ruediger >>>>> >>>>> >>>>> Ruediger Volk >>>>> >>>>> Deutsche Telekom AG -- Internet Backbone Engineering >>>>> >>>>> E-Mail:rv at NIC.DTAG.DE >>>>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jahlen at ripe.net Thu Aug 15 19:07:06 2013 From: jahlen at ripe.net (=?iso-8859-1?Q?Johan_=C5hl=E9n?=) Date: Thu, 15 Aug 2013 19:07:06 +0200 Subject: [ncc-services-wg] [db-wg] Urgent release of RIPE Database software In-Reply-To: <520CF1DA.1050907@softlayer.com> References: <6795.1376571123@x37.NIC.DTAG.DE> <5F24B37A-77BB-4F15-8138-BD0FE3BA9C35@ripe.net> <520CD98E.6010309@softlayer.com> <520CF1DA.1050907@softlayer.com> Message-ID: Dear Tim, Instead of quickly fixing this issue and creating a new release today we've decided to halt the deployment of any new release for now. This is very embarrassing and we're very sorry for this. We obviously put too much trust in the framework that generates the documentation and we don't have the proper mechanisms in place to validate the correctness of the documentation generated. We will give this our fullest attention the coming days and expect to have a working solution sometime next week. In the meantime I hope the existing documentation in TEST Database contains the information you need to proceed with your project. If you have any questions about how the API works then please contact us directly and we'll gladly help you out. Kind regards, Johan ?hl?n Assistant Manager Database RIPE NCC On 15 Aug 2013, at 17:20, Tim Garrison wrote: > I would like to report that there appear to be some broken links in the documentation still. For example, on https://rest-test.db.ripe.net/api-doc/path__create.html there is a link to the "whois-resources" element, which points to https://rest-test.db.ripe.net/api-doc/el_ns0_whois-resources.html . This link produces a 404. > > Tim Garrison > Software Engineer III > > SoftLayer, an IBM Company > 315 Capitol Street Suite 205, Houston, TX 77002 > 281.714.4213 direct | 713.540.4325 mobile | 281.714.4657 fax | tgarrison at softlayer.com > > On 08/15/2013 09:10 AM, Johan ?hl?n wrote: >> Dear all, >> >> The release containing the fix is now available in the TEST Database and there's a service announcement on the web page. >> >> If there are no objections to this we will proceed with 24h in the TEST Database and put this release in production on the RIPE Database tomorrow at 16:00. Please go ahead and test your applications against the version in the TEST Database. >> >> The URL for the REST API in TEST is: >> >> http(s)://rest-test.db.ripe.net >> >> Kind regards, >> >> Johan ?hl?n >> Assistant Manager Database >> RIPE NCC >> >> On 15 Aug 2013, at 15:37, Tim Garrison wrote: >> >>> That seems like a reasonable approach to me. >>> >>> Tim Garrison >>> Software Engineer III >>> >>> SoftLayer, an IBM Company >>> 315 Capitol Street Suite 205, Houston, TX 77002 >>> 281.714.4213 direct | 713.540.4325 mobile | 281.714.4657 fax | tgarrison at softlayer.com >>> >>> On 08/15/2013 08:32 AM, Job Snijders wrote: >>>> Hi, >>>> >>>> Any reason not to deploy on test environmen, wait 24 hours, proceed to roll out on production environment? >>>> >>>> Kind regards, >>>> >>>> Job >>>> >>>> On Aug 15, 2013, at 3:27 PM, Johan ?hl?n wrote: >>>> >>>>> Dear Ruediger, >>>>> >>>>> Thank you for the input. As you are all aware the release procedure is new and does require some tuning, so in that aspect any suggestions on how we can improve this are welcome. >>>>> >>>>> In this particular situation our assessment is that the broken links in the documentation indeed has a service impact. For some users this could be critical as they may not be able to use the REST API service. At least one case was reported to us where the development towards the API has come to a halt because of this. >>>>> >>>>> Perhaps in this case we can hold the deployment of the fix until the working group advices us on how to proceed. >>>>> >>>>> Kind regards, >>>>> >>>>> Johan ?hl?n >>>>> Assistant Database Manager >>>>> RIPE NCC >>>>> >>>>> On 15 Aug 2013, at 14:52, "Ruediger Volk, Deutsche Telekom Technik - FMED-41.." wrote: >>>>> >>>>>> Dear Johan, >>>>>> >>>>>> thanks a lot for the new much more transparent mode of software >>>>>> version management for the RIPE data base service. >>>>>> This is a huge improvement. >>>>>> >>>>>> Nevertheless I think that we need continued discussion in the community to >>>>>> improve mutual understanding of considerations and impact. >>>>>> >>>>>> Your message today brings up few consideratiosn from me >>>>>> (a bit more tuned to the general pro cess than the specific case). >>>>>> >>>>>>> We were recently made aware of some issues with the documentation >>>>>>> related to the REST API. To fix these issues requires a new release of >>>>>>> the Database software as some parts of the documentation are generated >>>>>>> from the active code. The documentation is vital for anyone wanting to >>>>>>> use the service. We therefore believe it is necessary to make a new >>>>>>> release containing this fix only and deploy it directly to production >>>>>>> later today. >>>>>> The problem description does NOT read like there IS ACTUAL SERVICE IMPACT >>>>>> at the moment; looking at the RIPE NCC service status page seems to confirm >>>>>> since it reports "no known problems" and no ser vice announcements either. >>>>>> >>>>>> Doing a software version change with less than a day advance notice certainly >>>>>> can be appropriate as an "emergency update" to deal with some service impact. >>>>>> How much harm is done if fix to the documentation is done a few days later >>>>>> while a note is posted indicating that certain errors will be fixed >>>>>> in the near future... ? >>>>>> >>>>>>> In this particular case we don=92t believe it is necessary to put the >>>>>>> release in test beforehand. The only fix is for the documentation and >>>>>>> this is preventing users form using the service, so it's quite urgent. >>>>>>> This fix should have no impact on any other part of the RIPE Database >>>>>>> service. >>>>>> I am tempted to believe your assessment; I dont have access to the changes >>>>>> and the resources to do my own full assessment. >>>>>> As I did experience 3 service impacting bugs within 12 months with >>>>>> UNannounced version changes I conclude that I rather see than believe. >>>>>> I certainly do see a need to watch more carefully how software behaves >>>>>> after ANY change and a non zero probability of some surprise >>>>>> (that could result in service impact for me). >>>>>> >>>>>> Note: knowing the schedule of upcoming changes some time in advance >>>>>> can be more important than actually having the ability to run tests >>>>>> (like due to IETF timing I could not run tests against the test server with >>>>>> 1.67.4 - but we did schedule preparation of critical production runs in >>>>>> a way that protected us against potential surprises due to the software change.) >>>>>> >>>>>>> If you have any questions then please let us know. >>>>>>> >>>>>>> Kind regards, >>>>>>> >>>>>>> Johan =C5hl=E9n >>>>>>> Assistant Manager Database >>>>>>> RIPE NCC= >>>>>> Best regards, >>>>>> Ruediger >>>>>> >>>>>> >>>>>> Ruediger Volk >>>>>> >>>>>> Deutsche Telekom AG -- Internet Backbone Engineering >>>>>> >>>>>> E-Mail: rv at NIC.DTAG.DE >>>>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From training at ripe.net Mon Aug 19 11:13:35 2013 From: training at ripe.net (Training Team) Date: Mon, 19 Aug 2013 11:13:35 +0200 Subject: [ncc-services-wg] [training] RIPE NCC Webinars - new dates In-Reply-To: <51CBF1C5.8070707@ripe.net> References: <51CBF1C5.8070707@ripe.net> Message-ID: <5211E1BF.8030900@ripe.net> Dear colleagues, We are pleased to announce the launch of new dates for our Webinars. The RIPE NCC Webinars are live and take only one hour. You can interact with our trainers without leaving your desk. We focus on the topics and issues most important for LIRs. Register now at https://www.ripe.net/lir-services/training/e-learning/webinars Participation is limited to 20 people, so don't hesitate if you want to take part! If you have questions, please email . We look forward to seeing you online. Kind regards, RIPE NCC Training Services From training at ripe.net Thu Aug 22 15:09:16 2013 From: training at ripe.net (Training Team) Date: Thu, 22 Aug 2013 15:09:16 +0200 Subject: [ncc-services-wg] [training] RIPE NCC Training Courses October-December 2013 In-Reply-To: <5215F793.2060707@ripe.net> References: <5215F793.2060707@ripe.net> Message-ID: <52160D7C.2000404@ripe.net> Dear Colleagues, Our training team travels the RIPE NCC service region to deliver training courses to our members without any additional cost. Over the next few months, we'll be in Kiev, Belgrade, Tallinn, Hamburg, Oslo, Paris, Dublin, Vienna, Barcelona, Muscat, Manchester, Amsterdam. Visit the following page to register and to check which training courses we are giving in your area: https://lirportal.ripe.net/training/courses The RIPE NCC delivers the following training courses: - LIR Training Course - Database Training Course (new) - IPv6 for LIRs Training Course - Routing Security Training Course For more information visit: http://www.ripe.net/lir-services/training/courses With kind regards, Rumy Spratley-Kanis Training Services Manager From BECHA at ripe.net Fri Aug 23 16:24:37 2013 From: BECHA at ripe.net (Vesna Manojlovic) Date: Fri, 23 Aug 2013 16:24:37 +0200 Subject: [ncc-services-wg] Accessing Routing Information Via RIPEstat In-Reply-To: <927D9603-3F26-4774-86D9-3C83177C52E5@ripe.net> References: <927D9603-3F26-4774-86D9-3C83177C52E5@ripe.net> Message-ID: <521770A5.3020003@ripe.net> Dear colleagues, (apologies for cross-posting) Our Routing Information Service (RIS) has been collecting global BGP routing information for 12 years now. During this period, many different interfaces to analyse and visualise accumulated data have been developed. In line with our long-term goals to provide more consolidated services, we will be integrating the RIS interface's tools and services into RIPEstat. More information about this is detailed in a new RIPE Labs article: https://labs.ripe.net/Members/fatemah_mafi/improved-routing-information-available-via-ripestat We invite the community to comment on these upcoming changes via the MAT Working Group Mailing List: https://www.ripe.net/ripe/groups/wg/mat Please submit any urgent requests for additional features via email to stat at ripe.net by 20 September 2013 so that we can implement these along with the planned migration of tools and features. Any feedback received after this date will be considered feature requests, and added to the RIPEstat Roadmap: http://roadmap.ripe.net/ripe-stat/ We look forward to your feedback. Regards, Vesna -- Vesna Manojlovic BECHA at ripe.net Senior Community Builder @Ms_Measurements for Measurements Tools RIPE NCC http://ripe.net From mir at ripe.net Wed Aug 28 16:28:38 2013 From: mir at ripe.net (Mirjam Kuehne) Date: Wed, 28 Aug 2013 16:28:38 +0200 Subject: [ncc-services-wg] New RIPEstat Website Message-ID: <521E0916.6020501@ripe.net> Dear colleagues, We've revamped the RIPEstat website to make it easier to find the information you're looking for. Please read more on RIPE Labs: https://labs.ripe.net/Members/suzanne_taylor_muzzin/new-ripestat-website Kind regards, Mirjam Kuehne RIPE NCC From nick at netability.ie Thu Aug 29 12:22:45 2013 From: nick at netability.ie (Nick Hilliard) Date: Thu, 29 Aug 2013 11:22:45 +0100 Subject: [ncc-services-wg] Requirement for fax numbers in LIR Portal Message-ID: <521F20F5.9090901@netability.ie> The LIR Portal requires a fax-no: in several places, including initial LIR setup and ipv4/ipv6 allocation forms. Can this attribute be made optional instead of mandatory? Most organisations respond with surprise verging on mild panic when you tell them that they need a fax to be a RIPE NCC member. Does this require a policy change, or is it an operational thing in the NCC? I can't see any policy which makes fax-no: mandatory, but I haven't looked very closely either. Nick From ebais at a2b-internet.com Thu Aug 29 12:59:37 2013 From: ebais at a2b-internet.com (Erik Bais) Date: Thu, 29 Aug 2013 12:59:37 +0200 Subject: [ncc-services-wg] Requirement for fax numbers in LIR Portal In-Reply-To: <521F20F5.9090901@netability.ie> References: <521F20F5.9090901@netability.ie> Message-ID: <002f01cea4a6$daa20260$8fe60720$@a2b-internet.com> Hi Nick, I believe that a valid fax nr is required in the procedure to reset the maintainer object authorization. If my recollection of that specific procedure is correct, it is one of the ways the RIPE NCC communicates during part of that procedure. Although we don't use a fax for normal business anymore these days, we have a dedicated fax number (pointing to a mailbox) specific for companies that are still in the 80's. Regards, Erik Bais -----Original Message----- From: ncc-services-wg-bounces at ripe.net [mailto:ncc-services-wg-bounces at ripe.net] On Behalf Of Nick Hilliard Sent: donderdag 29 augustus 2013 12:23 To: ncc-services-wg at ripe.net Subject: [ncc-services-wg] Requirement for fax numbers in LIR Portal The LIR Portal requires a fax-no: in several places, including initial LIR setup and ipv4/ipv6 allocation forms. Can this attribute be made optional instead of mandatory? Most organisations respond with surprise verging on mild panic when you tell them that they need a fax to be a RIPE NCC member. Does this require a policy change, or is it an operational thing in the NCC? I can't see any policy which makes fax-no: mandatory, but I haven't looked very closely either. Nick From lists-ripe at c4inet.net Thu Aug 29 13:30:48 2013 From: lists-ripe at c4inet.net (Sascha Luck) Date: Thu, 29 Aug 2013 12:30:48 +0100 Subject: [ncc-services-wg] Requirement for fax numbers in LIR Portal In-Reply-To: <002f01cea4a6$daa20260$8fe60720$@a2b-internet.com> References: <521F20F5.9090901@netability.ie> <002f01cea4a6$daa20260$8fe60720$@a2b-internet.com> Message-ID: <20130829113048.GA29880@cilantro.c4inet.net> Hi Erik, On Thu, Aug 29, 2013 at 12:59:37PM +0200, Erik Bais wrote: >have a dedicated fax number (pointing to a mailbox) specific for >companies that are still in the 80's. while there are many companies that are still living the '80s, I see no really good reason why the NCC has to be one of them. rgds, Sascha Luck From nick at netability.ie Thu Aug 29 13:42:26 2013 From: nick at netability.ie (Nick Hilliard) Date: Thu, 29 Aug 2013 12:42:26 +0100 Subject: [ncc-services-wg] Requirement for fax numbers in LIR Portal In-Reply-To: <20130829113048.GA29880@cilantro.c4inet.net> References: <521F20F5.9090901@netability.ie> <002f01cea4a6$daa20260$8fe60720$@a2b-internet.com> <20130829113048.GA29880@cilantro.c4inet.net> Message-ID: <521F33A2.2000502@netability.ie> On 29/08/2013 12:30, Sascha Luck wrote: > while there are many companies that are still living the '80s, I see no > really good reason why the NCC has to be one of them. ... nor dragging other companies into this situation. Besides, the fax for mnt auth reset is from $member to the NCC, not the other way around. So it's not relevant to this discussion. Nick From maurice at shq.nl Thu Aug 29 13:47:02 2013 From: maurice at shq.nl (Maurice [SHQ]) Date: Thu, 29 Aug 2013 13:47:02 +0200 Subject: [ncc-services-wg] Requirement for fax numbers in LIR Portal In-Reply-To: <20130829113048.GA29880@cilantro.c4inet.net> References: <521F20F5.9090901@netability.ie> <002f01cea4a6$daa20260$8fe60720$@a2b-internet.com> <20130829113048.GA29880@cilantro.c4inet.net> Message-ID: <92E3F549-B001-47BD-B254-67CD411617AA@shq.nl> Hi Sascha There are a lot of companies in countries where Internet is still not as strong as evaluated example like in the Netherlands, Belgium etc.. These are often dependent on fax. Met vriendelijke groet, Maurice SHQ B.V. Sterk in e-commerce hosting Klantenservice Nederland: 0165-201005 Klantenservice Belgie: 03-8081633 klantenservice at shq.nl / www.shq.nl Postadres: Ekelstraat 3 4726AN Heerle - NB Op al onze diensten en leveringen zijn onze algemene voorwaarden van toepassing. SHQ.nl is onderdeel van Trafego IS B.V. - KVK Breda: 58096140 Op 29 aug 2013, om 13:30 heeft Sascha Luck het volgende geschreven: > Hi Erik, > > On Thu, Aug 29, 2013 at 12:59:37PM +0200, Erik Bais wrote: >> have a dedicated fax number (pointing to a mailbox) specific for >> companies that are still in the 80's. > > while there are many companies that are still living the '80s, I see no > really good reason why the NCC has to be one of them. > > rgds, > Sascha Luck > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From woody at pch.net Thu Aug 29 13:50:27 2013 From: woody at pch.net (Bill Woodcock) Date: Thu, 29 Aug 2013 07:50:27 -0400 Subject: [ncc-services-wg] Requirement for fax numbers in LIR Portal In-Reply-To: <92E3F549-B001-47BD-B254-67CD411617AA@shq.nl> References: <521F20F5.9090901@netability.ie> <002f01cea4a6$daa20260$8fe60720$@a2b-internet.com> <20130829113048.GA29880@cilantro.c4inet.net> <92E3F549-B001-47BD-B254-67CD411617AA@shq.nl> Message-ID: <028A1040-56AD-4828-AD73-F930F160ED48@pch.net> Then, if it's optional, they could avail themselves of the option. -Bill On Aug 29, 2013, at 7:47, "Maurice [SHQ]" wrote: > Hi Sascha > > There are a lot of companies in countries where Internet is still not as strong as evaluated example like in the Netherlands, Belgium etc.. These are often dependent on fax. > > Met vriendelijke groet, > Maurice > > SHQ B.V. > Sterk in e-commerce hosting > > Klantenservice Nederland: 0165-201005 > Klantenservice Belgie: 03-8081633 > > klantenservice at shq.nl / www.shq.nl > > Postadres: Ekelstraat 3 4726AN Heerle - NB > > Op al onze diensten en leveringen zijn onze algemene voorwaarden van toepassing. > SHQ.nl is onderdeel van Trafego IS B.V. - KVK Breda: 58096140 > > > > > > Op 29 aug 2013, om 13:30 heeft Sascha Luck het volgende geschreven: > >> Hi Erik, >> >> On Thu, Aug 29, 2013 at 12:59:37PM +0200, Erik Bais wrote: >>> have a dedicated fax number (pointing to a mailbox) specific for >>> companies that are still in the 80's. >> >> while there are many companies that are still living the '80s, I see no >> really good reason why the NCC has to be one of them. >> >> rgds, >> Sascha Luck > -------------- next part -------------- An HTML attachment was scrubbed... URL: From woody at pch.net Thu Aug 29 13:46:21 2013 From: woody at pch.net (Bill Woodcock) Date: Thu, 29 Aug 2013 07:46:21 -0400 Subject: [ncc-services-wg] Requirement for fax numbers in LIR Portal In-Reply-To: <002f01cea4a6$daa20260$8fe60720$@a2b-internet.com> References: <521F20F5.9090901@netability.ie> <002f01cea4a6$daa20260$8fe60720$@a2b-internet.com> Message-ID: <78A0B493-A8B2-43E4-BBF4-AAC44ED47B9D@pch.net> It does seem high time this be modernized. -Bill On Aug 29, 2013, at 7:00, "Erik Bais" wrote: > Hi Nick, > > I believe that a valid fax nr is required in the procedure to reset the maintainer object authorization. > > If my recollection of that specific procedure is correct, it is one of the ways the RIPE NCC communicates during part of that procedure. > Although we don't use a fax for normal business anymore these days, we have a dedicated fax number (pointing to a mailbox) specific for companies that are still in the 80's. > > Regards, > Erik Bais > > -----Original Message----- > From: ncc-services-wg-bounces at ripe.net [mailto:ncc-services-wg-bounces at ripe.net] On Behalf Of Nick Hilliard > Sent: donderdag 29 augustus 2013 12:23 > To: ncc-services-wg at ripe.net > Subject: [ncc-services-wg] Requirement for fax numbers in LIR Portal > > The LIR Portal requires a fax-no: in several places, including initial LIR > setup and ipv4/ipv6 allocation forms. > > Can this attribute be made optional instead of mandatory? Most > organisations respond with surprise verging on mild panic when you tell > them that they need a fax to be a RIPE NCC member. > > Does this require a policy change, or is it an operational thing in the > NCC? I can't see any policy which makes fax-no: mandatory, but I haven't > looked very closely either. > > Nick > > > From Piotr.Strzyzewski at polsl.pl Thu Aug 29 14:13:26 2013 From: Piotr.Strzyzewski at polsl.pl (Piotr Strzyzewski) Date: Thu, 29 Aug 2013 14:13:26 +0200 Subject: [ncc-services-wg] Requirement for fax numbers in LIR Portal In-Reply-To: <92E3F549-B001-47BD-B254-67CD411617AA@shq.nl> References: <521F20F5.9090901@netability.ie> <002f01cea4a6$daa20260$8fe60720$@a2b-internet.com> <20130829113048.GA29880@cilantro.c4inet.net> <92E3F549-B001-47BD-B254-67CD411617AA@shq.nl> Message-ID: <20130829121326.GF25108@hydra.ck.polsl.pl> On Thu, Aug 29, 2013 at 01:47:02PM +0200, Maurice [SHQ] wrote: Hi Maurice > There are a lot of companies in countries where Internet is still not as strong as evaluated example like in the Netherlands, Belgium etc.. These are often dependent on fax. Which is not relevant in the discussion about making the fax-no optional. Piotr -- gucio -> Piotr Strzy?ewski E-mail: Piotr.Strzyzewski at polsl.pl From sander at steffann.nl Thu Aug 29 15:25:05 2013 From: sander at steffann.nl (Sander Steffann) Date: Thu, 29 Aug 2013 15:25:05 +0200 Subject: [ncc-services-wg] Requirement for fax numbers in LIR Portal In-Reply-To: <20130829113048.GA29880@cilantro.c4inet.net> References: <521F20F5.9090901@netability.ie> <002f01cea4a6$daa20260$8fe60720$@a2b-internet.com> <20130829113048.GA29880@cilantro.c4inet.net> Message-ID: Op 29 aug. 2013, om 13:30 heeft Sascha Luck het volgende geschreven: > On Thu, Aug 29, 2013 at 12:59:37PM +0200, Erik Bais wrote: >> have a dedicated fax number (pointing to a mailbox) specific for >> companies that are still in the 80's. > > while there are many companies that are still living the '80s, I see no > really good reason why the NCC has to be one of them. +1 Sander From Piotr.Strzyzewski at polsl.pl Thu Aug 29 15:33:52 2013 From: Piotr.Strzyzewski at polsl.pl (Piotr Strzyzewski) Date: Thu, 29 Aug 2013 15:33:52 +0200 Subject: [ncc-services-wg] Requirement for fax numbers in LIR Portal In-Reply-To: References: <521F20F5.9090901@netability.ie> <002f01cea4a6$daa20260$8fe60720$@a2b-internet.com> <20130829113048.GA29880@cilantro.c4inet.net> Message-ID: <20130829133352.GI25108@hydra.ck.polsl.pl> On Thu, Aug 29, 2013 at 03:25:05PM +0200, Sander Steffann wrote: > Op 29 aug. 2013, om 13:30 heeft Sascha Luck het volgende geschreven: > > On Thu, Aug 29, 2013 at 12:59:37PM +0200, Erik Bais wrote: > >> have a dedicated fax number (pointing to a mailbox) specific for > >> companies that are still in the 80's. > > > > while there are many companies that are still living the '80s, I see no > > really good reason why the NCC has to be one of them. > > +1 +1 Piotr -- gucio -> Piotr Strzy?ewski E-mail: Piotr.Strzyzewski at polsl.pl From training at ripe.net Thu Aug 29 16:25:35 2013 From: training at ripe.net (Training Team) Date: Thu, 29 Aug 2013 16:25:35 +0200 Subject: [ncc-services-wg] [training] RIPE NCC Webinars - new dates In-Reply-To: <50FE6858.9090800@ripe.net> References: <50FE6858.9090800@ripe.net> Message-ID: <521F59DF.7090103@ripe.net> Dear colleagues, We are pleased to announce the launch of new dates for our Webinars for LIRs. The RIPE NCC Webinars are live, one hour online training courses that allow participants to interact with our trainers without leaving their desks. We focus on the topics and issues most important for LIRs. Register now at https://www.ripe.net/lir-services/training/e-learning/webinars Participation is limited to 20 people, so don't hesitate if you want to take part! If you have questions, please email. We look forward to seeing you online. Kind regards, RIPE NCC Training Services From laura at ripe.net Thu Aug 29 17:19:28 2013 From: laura at ripe.net (Laura Cobley) Date: Thu, 29 Aug 2013 17:19:28 +0200 Subject: [ncc-services-wg] Requirement for fax numbers in LIR Portal In-Reply-To: <002f01cea4a6$daa20260$8fe60720$@a2b-internet.com> References: <521F20F5.9090901@netability.ie> <002f01cea4a6$daa20260$8fe60720$@a2b-internet.com> Message-ID: <521F6680.8010106@ripe.net> Dear all, Thank you for your feedback regarding the requirement for fax numbers within various RIPE NCC processes. We will adjust our systems to make fax numbers optional fields. The process to request a change in the authorisation of a MNTNER object was updated some time ago and the requirement for a fax number was also removed. If you have any further questions, please don't hesitate to contact me. Kind regards, Laura Cobley RIPE NCC Customer Services Manager On 8/29/13 12:59 PM, Erik Bais wrote: > Hi Nick, > > I believe that a valid fax nr is required in the procedure to reset the maintainer object authorization. > > If my recollection of that specific procedure is correct, it is one of the ways the RIPE NCC communicates during part of that procedure. > Although we don't use a fax for normal business anymore these days, we have a dedicated fax number (pointing to a mailbox) specific for companies that are still in the 80's. > > Regards, > Erik Bais > > -----Original Message----- > From: ncc-services-wg-bounces at ripe.net [mailto:ncc-services-wg-bounces at ripe.net] On Behalf Of Nick Hilliard > Sent: donderdag 29 augustus 2013 12:23 > To: ncc-services-wg at ripe.net > Subject: [ncc-services-wg] Requirement for fax numbers in LIR Portal > > The LIR Portal requires a fax-no: in several places, including initial LIR > setup and ipv4/ipv6 allocation forms. > > Can this attribute be made optional instead of mandatory? Most > organisations respond with surprise verging on mild panic when you tell > them that they need a fax to be a RIPE NCC member. > > Does this require a policy change, or is it an operational thing in the > NCC? I can't see any policy which makes fax-no: mandatory, but I haven't > looked very closely either. > > Nick > > > > From m.hallgren at free.fr Thu Aug 29 23:33:30 2013 From: m.hallgren at free.fr (Michael Hallgren) Date: Thu, 29 Aug 2013 23:33:30 +0200 Subject: [ncc-services-wg] Requirement for fax numbers in LIR Portal In-Reply-To: <20130829113048.GA29880@cilantro.c4inet.net> References: <521F20F5.9090901@netability.ie> <002f01cea4a6$daa20260$8fe60720$@a2b-internet.com> <20130829113048.GA29880@cilantro.c4inet.net> Message-ID: <521FBE2A.5020106@free.fr> Le 29/08/2013 13:30, Sascha Luck a ?crit : > Hi Erik, > > On Thu, Aug 29, 2013 at 12:59:37PM +0200, Erik Bais wrote: >> have a dedicated fax number (pointing to a mailbox) specific for >> companies that are still in the 80's. > > while there are many companies that are still living the '80s, I see no > really good reason why the NCC has to be one of them. Shared view. Make the fax contact info optional (and adjust proc's accordingly)? mh > > rgds, > Sascha Luck > > From sander at steffann.nl Fri Aug 30 00:05:34 2013 From: sander at steffann.nl (Sander Steffann) Date: Fri, 30 Aug 2013 00:05:34 +0200 Subject: [ncc-services-wg] Requirement for fax numbers in LIR Portal In-Reply-To: <521FBE2A.5020106@free.fr> References: <521F20F5.9090901@netability.ie> <002f01cea4a6$daa20260$8fe60720$@a2b-internet.com> <20130829113048.GA29880@cilantro.c4inet.net> <521FBE2A.5020106@free.fr> Message-ID: <10CFEDA6-2EBC-4B35-9FE8-3729B595353D@steffann.nl> Hi, > Shared view. Make the fax contact info optional (and adjust proc's > accordingly)? The NCC already posted this afternoon that will adjust their processes: Op 29 aug. 2013, om 17:19 heeft Laura Cobley het volgende geschreven: > Dear all, > > Thank you for your feedback regarding the requirement for fax numbers > within various RIPE NCC processes. We will adjust our systems to make > fax numbers optional fields. > > The process to request a change in the authorisation of a MNTNER object > was updated some time ago and the requirement for a fax number was also > removed. > > If you have any further questions, please don't hesitate to contact me. > > Kind regards, > > Laura Cobley > RIPE NCC Customer Services Manager Cheers, Sander From jrace at attglobal.net Fri Aug 30 09:40:12 2013 From: jrace at attglobal.net (Jeffrey Race) Date: Fri, 30 Aug 2013 08:40:12 +0100 Subject: [ncc-services-wg] Requirement for fax numbers in LIR Portal In-Reply-To: <002f01cea4a6$daa20260$8fe60720$@a2b-internet.com> Message-ID: Aside from registered postal mail, it is the only method of record communication generating a legally valid receipt of communication, so it is highly advisable to retain this requirement. Some organizations may feel discomfort at the requirement to be contactable by accountable means, but this is in my opinion a small price to pay to counterbalance the very large number of organizations which ignore all attempts to communicate via e-mail. Jeffrey Race Cambridge Electronics Laboratories On Thu, 29 Aug 2013 12:59:37 +0200, Erik Bais wrote: >Hi Nick, > >I believe that a valid fax nr is required in the procedure to reset the maintainer object authorization. > >If my recollection of that specific procedure is correct, it is one of the ways the RIPE NCC communicates during part of that procedure. >Although we don't use a fax for normal business anymore these days, we have a dedicated fax number (pointing to a mailbox) specific for companies that are still in the 80's. > >Regards, >Erik Bais > >-----Original Message----- >From: ncc-services-wg-bounces at ripe.net [mailto:ncc-services-wg-bounces at ripe.net] On Behalf Of Nick Hilliard >Sent: donderdag 29 augustus 2013 12:23 >To: ncc-services-wg at ripe.net >Subject: [ncc-services-wg] Requirement for fax numbers in LIR Portal > >The LIR Portal requires a fax-no: in several places, including initial LIR >setup and ipv4/ipv6 allocation forms. > >Can this attribute be made optional instead of mandatory? Most >organisations respond with surprise verging on mild panic when you tell >them that they need a fax to be a RIPE NCC member. > >Does this require a policy change, or is it an operational thing in the >NCC? I can't see any policy which makes fax-no: mandatory, but I haven't >looked very closely either. > >Nick > > > From James_R-ripelist at jump.org.uk Fri Aug 30 10:01:57 2013 From: James_R-ripelist at jump.org.uk (James A. T. Rice) Date: Fri, 30 Aug 2013 09:01:57 +0100 (BST) Subject: [ncc-services-wg] Requirement for fax numbers in LIR Portal Message-ID: On Fri, 30 Aug 2013, Jeffrey Race wrote: > Aside from registered postal mail, it is the only method of record > communication generating a legally valid receipt of communication Citation needed Regards James From jim at rfc1035.com Fri Aug 30 11:35:14 2013 From: jim at rfc1035.com (Jim Reid) Date: Fri, 30 Aug 2013 10:35:14 +0100 Subject: [ncc-services-wg] Requirement for fax numbers in LIR Portal In-Reply-To: <002f01cea4a6$daa20260$8fe60720$@a2b-internet.com> Message-ID: <9BE5DF81-D49C-4466-BAE6-CFFFD999B2FE@rfc1035.com> On 30 Aug 2013, at 08:40, Jeffrey Race wrote: > Aside from registered postal mail, it is the only method > of record communication generating a legally valid > receipt of communication, so it is highly advisable to > retain this requirement. Even if this is true -- for all jurisdictions in the NCC service region? -- I am unable to invent a scenario where the NCC would have to use fax instead of registered snail-mail for such "legally valid" communication with one of its members. Members who are still living in the 1980s or have legal systems forcing them to do that are of course welcome to add an optional fax number to their contact data. Nobody else should bother. From m.hallgren at free.fr Fri Aug 30 14:29:59 2013 From: m.hallgren at free.fr (Michael Hallgren) Date: Fri, 30 Aug 2013 14:29:59 +0200 Subject: [ncc-services-wg] Requirement for fax numbers in LIR Portal In-Reply-To: <9BE5DF81-D49C-4466-BAE6-CFFFD999B2FE@rfc1035.com> References: <9BE5DF81-D49C-4466-BAE6-CFFFD999B2FE@rfc1035.com> Message-ID: <52209047.8060906@free.fr> Le 30/08/2013 11:35, Jim Reid a ?crit : > On 30 Aug 2013, at 08:40, Jeffrey Race wrote: > >> Aside from registered postal mail, it is the only method >> of record communication generating a legally valid >> receipt of communication, so it is highly advisable to >> retain this requirement. > Even if this is true -- for all jurisdictions in the NCC service region? -- I am unable to invent a scenario where the NCC would have to use fax instead of registered snail-mail for such "legally valid" communication with one of its members. > > Members who are still living in the 1980s or have legal systems forcing them to do that are of course welcome to add an optional fax number to their contact data. Nobody else should bother. Voil? ! mh > >