Re: [Wg-rms] Summary of discusstion

[Jas Webb <jaswbb@yahoo.com.au>]

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.

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.
 
> 
> 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?
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??

> 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.

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.

> 
> 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 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