Re: [Wg-rms] Summary of discussion

[Shin Yamasaki <yamasaki@nic.ad.jp>]

Jas and all,

Happy new year!  Thank you for your contribution for this WG mailing list.

-------- Original Message --------
Subject: Re:[Wg-rms] Summary of discusstion
From: Jas Webb <jaswbb@yahoo.com.au>
To: wg-rms@lists.apnic.net
Date: Fri Jan 05 2007 09:55:19 GMT+0900

> Yamasaki-san and all,
> 
> happy new year!
> 
> --- Shin Yamasaki <yamasaki@nic.ad.jp> wrote:
> 
>> 1. Co-chair resignation
>>
>> Terry Manderson stepped down from the co-chair
>> position due to his
>> concern about his status as secretariat.
> 
> I think that is only partially fair, I also feel that
> the secretariat has responsibility here and an APNIC
> representative should be on the steering side of
> things to ensure that suggestions and requests for
> information are adequately supplied. It also allows
> the secretariat to adjudicate solutions for viability
> in terms of the secretariat resources.
> 
> It seems bizarre that the membership can suggest /
> promote or reject proposals that have longer term
> operational costs without a sensible guiding hand from
> the secretariat. 
> 
> Perhaps the WG could ask Terry (and APNIC) to re-take
> a position as "WG advisor" or similar that may
> maintain the impartiality but also be the 'buy in' and
> point of responsibility from the secretariat.

In my opinion, we don't have to re-appoint Terry special position
officially. The reason is Terry has already been providing enough input
to this WG.  In other words, he already takes that kind of role you
mentioned.  I prefer to have more participants rather than having more
officers in this WG.

> 
> Further, it seems that this working group has a longer
> term ongoing role that actually encompasses the
> DB-SIG, I think this WG should be promoted to a SIG
> level replacing and consuming the DB-SIG, which I
> don't see any traffic on.

Since this WG is a child of Policy WG, I don't think it's appropriate to
take another SIG over.  You can propose reform or re-org the DB SIG
after this WG is closed.

>  
>> 2.1. Pro opinion:
>>
>> - Thinking about new system would be good idea since
>> this discussion for
>> this kind of topic may take for a long time.
>> - Considering new technologies such as DNSSEC and
>> resource
>> certification, increasing security for bulk updating
>> method for APNIC
>> RMS would be good idea.
>> - E-mail registration interface isn't user-friendly.
>> - MyAPNIC doesn't address secure automated
>> registration.  The new
>> proposed XML interface solves this.
> 
> - longer term cost reduction to both members and
> APNIC.
> - faster updates
> 
> maybe, and this is me thinking aloud, have
> applications for resource submitted via xml as well?

Thanks for the addition.

> And track those applications via XML query?
> 
>> 2.2. Con opinion:
>>
>> - This affects existing in-house IT systems which
>> are optimized for
>> current e-mail application.  This could be pressure
>> costwise for small LIRs.
>> - MyAPNIC already exists for who prefer secure
>> registration.
>>
> 
> Both valid. But is there a weighting we can apply to
> both the Pros and the Cons? low/med/high??

I leave this for other participants.

> 
>> 2.3. From the APNIC Secretariat:
>>
>> In the proposal, the implementation periods as
>> follows:
>>
>>     -  4 months after adoption:     Stop accepting
>> email updates for
>>                                     domain objects
>>     -  8 months after adoption:     Stop accepting
>> email updates for
>>                                     inetnum,
>> inet6num, and aut-num
>>                                     objects
>>     -  12 months after adoption:    Stop accepting
>> email update for the
>>                                     remaining object
>> types
>>
>> The secretariat asked if these periods are
>> appropriate.
> 
> well.. sort of.. I think way to aggressive, in the
> same phrase as "I don't want to spend money on having
> someone deal with email update issues", I equally
> don't want have to rapidly change a resource budget to
> pay for a rapid implementation.
> 
> how about this, After adoption:
> 
> 6 months: Start accepting all objects via new method
> 10 months: stop accepting domain objects via email
> 14 months: stop accepting inetnum, inet6num, autnum
> objects
> 18 months: stop accepting all remaining objects.

Any comments, especially from APNIC secretariat?

> 
> Is it possible for APNIC to have a working prototype 2
> months after adoption so that we can begin change-over
> work?
> 
> APNIC must also provide tools for this.. perl or java
> please.

They might already have that.

> 
>> 2.4. Alternative/Counter proposal
>>
>> No counter proposal has been brought up.  In
>> addition, no compromise has
>> been proposed yet.
> 
> I actually think when most people really consider the
> long term scope of this only have small objections - i
> think - relating to the aggressive timelines proposed
> by Terry in the initial proposal.
> 
>>From my opinion - this reads as something deeper. Why
> the need for aggressive implementation? Perhaps Terry
> knows more than is written in the proposal.. I looked
> back over past APNIC meeting agendas and Terry has
> previously presented about issues with DNS generation
> and the APNIC internal registry system.  It seems
> plain that APNIC has a system that is desperate for an
> overhaul, and this proposal is that overhaul. If that
> is the case, and the proposal is about replacing an
> old incapable system, then I'll double my support of
> the proposal (with modifications).

I leave this for Terry.

Shin

> 
> 
>> I think our next step is bringing more participants
>> then having further
>> discusstion, then getting conclusion and
>> recommendation for the proposal
>> (prop-037) by APNIC 23.
>>
> 
> -- Jas
> 
> 
> 
> --
> Jas Webb
> 
> Send instant messages to your online friends http://au.messenger.yahoo.com 
> _______________________________________________
> Wg-rms mailing list
> Wg-rms@lists.apnic.net
> http://mailman.apnic.net/mailman/listinfo/wg-rms
> 


-- 
Shin Yamasaki
Japan Network Information Center (JPNIC)