|
|
Terry, I have a simple question. >>> 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? >> > > There is an underlying argument in when we start and stop accepting > updates from different entry points. This argument centres around the > question: "which is the authoritative data set?". > > At present, due to facets of history, APNIC has two distinct databases, > one known as registry and one known as whois. Which do we consider to be > the true and correct representation? After evaluations of workflows, > data sets, and processes it was agreed internally that the 'registry' > data should be known as the one and true location of information. Whois > would then be a view of registry that fits all of the APNIC community > and business rules (such as reporting, privacy and confidentiality). > > The XML mechanism proposed updates 'registry' directly and conversely > email updates 'whois' alone. If we were to run both mechanisms for a > data-set, say inetnum, we could have a clash of data and that raises > some very difficult data-merge questions when you have two equally > authorised data-sets. > > Based on this, and I take your point about the timing of the change. Can > I suggest: > > 6 months: Have prototype for all objects available > 10 months: stop accepting domain objects via email > 14 months: stop accepting inetnum, inet6num, autnum > objects > 18 months: stop accepting all remaining objects. When the new XML-based production system, which we can send actual registration requests, starts accepting all registration? Best, Shin -- Shin Yamasaki Japan Network Information Center (JPNIC)
Attachment:
smime.p7s
Description: S/MIME Cryptographic Signature