sig-nir March 2008

sig-nir@lists.apnic.net

3 participants
2 discussions

Re: [sig-nir] prop-054: NIR operational policydocument revision
by Izumi Okutani 13 Mar '08

13 Mar '08

Thanks for the comment, Jian Zhang. Just as a clarification question, are you refering to this part of the proposal? > 3. "Appendix: Details of flat file view of a zone" be removed from > APNIC-103-v001 as it is no longer needed. If you are concerned about removal from the Appendix, it is simply because the practice described here will no longer be valid once we transfer to REST/XML interface (which Terry informed us on nir-system ML). It has no actual impact on its own. ...or you perhaps have some other concerns? Just trying to understand the background behind your suggestion :-). izumi zhangjian wrote: > Hi everybody: > Should we add something like: APNIC will give notice to NIRs before a > certain time of deadline of removing flat file? > > Thanks > Jian Zhang > CNNIC > > ---------- > : sig-nir-bounces(a)lists.apnic.net [mailto:sig-nir-bounces@lists.apnic. > net] Izumi Okutani > : 200835 15:48 > : sig-nir(a)lists.apnic.net > : [sig-nir] Call for comments on prop-054: NIR operational > policydocument revision > > ----------------------------------------------------------------------- > prop-054: NIR operational policy document revision > ----------------------------------------------------------------------- > > Dear colleagues > > This is the final call for comments on policy proposal prop-054, 'NIR > operational policy document revision'. > > This proposal was presented at APNIC 25 and was accepted by consensus. > > The APNIC Secretariat will provide further details in the near future > that address concerns about ensuring that a documented history of > reverse DNS delegation methods can be tracked. > > The APNIC Secretariat and NIRs have agreed to discuss comfortable time > frames for the NIRs to implement any new reverse DNS delegation methods > on a case-by-case basis before new methods are adopted by APNIC and > the NIRs. > > The proposal has been submitted to the NIR SIG mailing list for an > eight-week discussion period. At the end of that period, if consensus > appears to have been achieved, the NIR SIG Chair will ask the > Executive Council to endorse the proposal for implementation. > > * Send all comments and questions to: <sig-nir(a)apnic.net> > * Deadline for comments: 29 April 2008 > > > Proposal details > ---------------- > > It is proposed that: > > 1. Section 3.4 of APNIC-103-v001 be updated to include a reference to > reverse DNS delegations in ip6.arpa. > > 2. The two processes for delegating reverse zones specified in section > 3.4 of APNIC-103-v001 be replaced with the following two processes: > > 1. Automated > > Reverse DNS zones may be managed using the currently supported > automated process documented at: > > Reverse DNS delegations resource guide > http://www.apnic.net/services/dns_guide.html > > > 2. Manual > > Reverse DNS delegations may be managed using MyAPNIC. > > 3. "Appendix: Details of flat file view of a zone" be removed from > APNIC-103-v001 as it is no longer needed. > > > Proposal details including the full text of the proposal, > presentations, links to relevant meeting archives and links to > mailing list discussions are available at: > > http://www.apnic.net/policy/proposals/prop-054-v001.html > > > Best Regards, > Izumi Okutani, David Chen, Billy Cheon > _______________________________________________ > sig-nir mailing list > sig-nir(a)lists.apnic.net > http://mailman.apnic.net/mailman/listinfo/sig-nir >

1 0

Re: [sig-nir] prop-054: NIR operational policy document revision
by Terry Manderson 07 Mar '08

07 Mar '08

Hi Shin, > Shin wrote: > - Do you support moving the technical descriptions of managing > reverse DNS zone out of 'Operational policies for National Internet > Registries in the APNIC region' and onto the APNIC website? > Currently I cannot find the equivalent part of section 3.4 of > APNIC-103-v001 in the web page stated in the proposal: > http://www.apnic.net/services/dns_guide.html > Unless APNIC clearly describes all required procedures in the page > before Policy SIG in APNIC 25, it is difficult to support this part. > The best I could bend backward is that APNIC posts the content of > the addendum to the web page to this mailing list. > Without that, it could be blind approval for non-existent procedure. I will endeavour to create a draft of that page, or furnish the information that will be provided on that url to the list before the meeting. However you can expect that it would simply reflect the preferred methods for updating the DNS, those being MyAPNIC and the XML/REST API. We clearly need to be careful about releasing the API information as it isn't yet a member wide service. > In the Disadvantages: part in the Pros/Cons section, | To ensure > that NIRs have enough time to adapt to the changes, | the APNIC > Secretariat will commit to a six-month notice period | between > announcing changes to the system and expected | implementation > by NIRs. > I prefer to change this to: To ensure that NIRs have enough time to > adapt to the changes, the APNIC Secretariat will commit to at least > six-month notice period between announcing changes to the system > and expected implementation by NIRs. Given that our development process is transparent, such that we are quite overt about upcoming work in the secretariat that may affect the NIRs. I'm guessing that your concern directly relates to your ability implement in 6 months assuming that you hadn't heard of it previously. So in applying this to future (not already scheduled) changes.. How does this sound as an alternative? ----- To ensure that NIRs have enough time to be both aware of the changes and adapt their systems to the changes, the APNIC Secretariat will commit to the following notice periods: 1) Notification of development or work-in-progress of three(3) to Six(6) months, prior to: 2) A six(6) month notice period to implementation by the NIR. ----- > The notice period can be extended upon request from APNIC or an NIR. I think I would find this acceptable if the request came with supporting reasons why the request needs to be extended, such that the reason for extension is in the best interests of the common good for continuous improvement or a direct conflict with another APNIC operational change at that time. Cheers Terry -- Terry Manderson email: terry(a)apnic.net Network Operations Manager, APNIC sip: info(a)voip.apnic.net http://www.apnic.net phone: +61 7 3858 3100

5 14

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

sig-nir March 2008