As a point of information, APNIC uses cc "ZZ" specifically for
unallocated and "stub" (outward transferred) records.
ZZ is an ISO3166 assigned code for "unknown"
-George
On Tue, Oct 8, 2019 at 4:56 AM Ronald F. Guilmette via db-wg
wrote:
>
> In message
>
> =?utf-8?q?T=C3=B6ma_Gavrichenkov_via
There was an implication in your mail that no WHOIS records should have ZZ.
There are specific reasons *some* WHOIS records have ZZ.
I understand you want *delegated* WHOIS records to have valid economies.
FYI the readme of delegated-extened and the non-exteded delegated
statistics files for the
I would like to offer strong support for this from the APNIC region.
RDAP has an ability to handle this, and I feel is rapidly becoming the
visible super-set of behaviour we need in Registry to record and
propagate information.
We still use RPSL encoded state in Whois for public record and contac
>From outside your region, but since we run a "fork" of the RIPE DB
code, I would like to add some comments.
APNIC has seen clear demand from our community for multiple language
alternatives to be possible for at least these attributes: contact
address (all parts), person names and org names. It
I would be broadly supportive of a cross-RIR database/registry
conversation. I think its long overdue.
It's not an easy conversation, but I think it's a necessary one.
it is also off-topic. So I won't say more, but having opened the door,
I strongly urge you to continue opening this door.
I beli
FYI, when APNIC implemented "WHOWAS" we deliberately walk over
deletions to carry history backward to prior state.
Whowas is implemented in RDAP, its meta state over RDAP representation
of the information but the underlying information comes from Whois
updates.
We also have a view inside APNIC th
Purely as a point of information, Randy also asked for APNIC to
consider this field, and it has been put into the Opportunity process
inside Registry Product, of which I am the manager.
I am following this discussion. My primary concerns are the effects on
tools, of a new type:value assertion appe
RRDP was designed in the light of experience with NRTM. It has good
fast convergence, TLS protection, fits the CDN model, and we have
deployment experience.
RDAP mirroring protocol is a design in early test, for RDAP to do NRTM
like mirroring, which was informed by RRDP.
I would like to suggest t
The Geofeed: field is a URL.
It points to a resource.
The semantic content of the resource should not be checked, what
matters is that the URL is not a 404 at the time of publication.
if you want to check it isn't a 404 after that, its like Lame checks:
good to do, not strictly essential in the
I'd say rather than a 2xx, Allowing for 30x redirection, HTTP->HTTPS
uplift and other things. And, gzip compression. So, basically,
completion of a data exchange.
Probably in the spirit of what you meant. As long as thats what "200"
means, I'd be fine!
cheers
-G
On Thu, Apr 8, 2021 at 8:42 AM C
This space is not constrained by RPKI.
Do we care about alignment? Personally, I do. I think IRR and RPKI
should be aligned.But, across the IRR space, route object
authorisation varies. Things done in RIPE IRR will not necessarily be
echoed in other IRR including ones mirrored and served by RIPE i
To one side of your core concern, which I think is entirely valid.
AP technically "belongs" to the African Fisheries forum, and APNIC
deprecates use of AP in delegated statistics. as I write, only one (asn)
record has AP against it. It may be used in Whois or RDAP.
EU is used more widely but I ha
I don't think that is a reasonable conclusion to draw from what was said.
Note: "...In line with the data management principles proposed by the
RIPE Database Requirements Task Force, it would be prudent to approach
this issue holistically, taking into account that other geolocation
information is
The field is OPTIONAL in the schema. Therefore the maintainer surely
has "consented" to publication of the URL to geo, if the field exists:
It isn't pre-filled. The consent question here, is the maintainer and
their obligations in law, and the role of the RIPE NCC in offering a
publication service
I suggest that this is not just a localized decision of the db-wg, but
has global implications. You are discussing a field whose value is
interpreted both directly from WHOIS and RDAP, and less directly from
delegated files in the registry system across all the RIR. Your
consumers are my consumers,
--- Begin Message ---
as a passive (mostly) participant, this is mostly my recollection too.
as a non passive participant...
I think the previously stated position from APNIC region is clear: we
have problems with the logistics which permit resources from our
region to be included in IRR statemen
--- Begin Message ---
On Tue, Jul 18, 2017 at 4:10 PM, Sander Steffann via db-wg
wrote:
>
>
> -- Forwarded message --
> From: Sander Steffann
> To: George Michaelson
> Cc: Nick Hilliard , Database WG , denis
> walker
> Bcc:
> Date: Tue, 18 Jul 2017 16:10:09 +0200
> Subject: Re:
--- Begin Message ---
I think its time to stop disrespecting external source of authority on
this. You argued for a position based on the desire of RIPE entities
needing to import foreign objects into their RPSL But you did not
address the far larger body of people who are exposed to risks from
the
Yes, I would support these changes. Half of the concerns with APNIC
resource management disappears if we cease depending on aut-num
authorization for route objects.
I prefer that ultimately the open maintainer method cease. But a step
along the way is to mark foreign objects clearly, so their stat
I also would like the work to deprecate ASN auth for ROUTE creation,
and the associated foreign object tagging to distinct source: work to
be a discrete item (or pair of items) and not "glommed" into a
collection of other things.
Because there are two other RIR who run variants of the RIPE-NCC cod
I concur with this.
And, I think that probably you are right Tim, and out-of-region data
should be disallowed, if not needed.
I'd also ask for documentation associated with RPSL and route object
and aut-num management to be reviewed and updated to reflect the
emerging reality.
-George
On Wed, D
I do not believe any future ROUTE and ROUTE6 object creation should
be permitted routinely, for non-RIPE address space, inside the RIPE
NCC routing registry.
-George
On Thu, Jan 11, 2018 at 9:21 AM, denis walker via db-wg wrote:
> Colleagues
>
> Plans to implement the solution for NWI-5 by drop
My personal (and I stress personal) opinion moving forward, is that
the use of an IRR really does not sit well with the management side of
delegation of authority in a distributed model that we have right now.
If we move to a model where the IRR/RPSL "maintainer" is understood to
be documentation
23 matches
Mail list logo
