-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi Jeff,
> My concern is that if you care about this feature, the whole point is you
> want to know if a given exclude behavior is covered by the implementation
> responding to your whois query.
>
> If the summary of your response is "good luck, may the odds be ever in your
> favor", it's at least clear what the (lack of) expectations are.
>
> In YANG land, this is exactly what lead to "features" being made visible in
> the protocols like NETCONF.
Yes, it would be different in a newer protocol. Whois is still very widely used
so this needs to be backwards compatibility and not restricted to newer REST or
GraphQL interfaces only.
I think the concern you are raising is the same as wanting to know if the
server you are querying uses a specific data source or not; it's not something
that can be provided in the whois response of the query, but it is something
the user can query. When sending "!s-lc" to IRRd for example, it will respond
with the data sources it uses and the search order of those data sources.
For the ROA filtering that I mentioned before, again there is nothing in the
whois response which indicates if ROA filtering was used. The IRRd
implementation does support queries that disable this ("!fno-rpki-filter"); the
user needs to request this before making their "main" query.
So the output of these whois queries does not include any meta data, so there
is no way to signal the data sources used or if ROA filtering was used in the
response of the "main" query. Therefore there is also no way to signal if any
sets were excluded in the response if a software implementation supporting this
document were queried. (Correct me anyone if I'm wrong here).
However, like the query to disable ROA filtering, or to get the data sources,
it could be possible to define in this document that a new query which disables
set exclusion must be supported, or one that tells the user that exclusion
filtering is enabled on the server.
Queries like "!v", "!a", "!i", "!gAS", "!6AS", and so on, are all not
standardised in any official standards documentation form, only in the sense of
wide spread implementation.
Introducing a new query which allows users to check if exclusions are enabled
and/or disable them would means that client implementations need to be updated
too, not just server implementations.
With kind regards,
James.
-----BEGIN PGP SIGNATURE-----
Version: ProtonMail
wsG5BAEBCgBtBYJp4QFxCRCoEx+igX+A+0UUAAAAAAAcACBzYWx0QG5vdGF0
aW9ucy5vcGVucGdwanMub3JnZ0qfsBzCAEI0IXE2caP6ytHFy80VeHhAl0Fz
IcgX6FkWIQQ+k2NZBObfK8Tl7sKoEx+igX+A+wAALicQAItu9nQBbauiiygw
LPd+L74c4slrsOXJQDaBT2X9KFNjCkc+SYmB29SvwQiHQ7+IZoVyEGUmlIwU
ztEDDAsNpPuL2dzwZxWPLEiThaZGs1xXrtA5pUVOvfFVM+JljtjuS+3aN92e
MYH5SKNwuIcWRO1nQC6ChoSrokyqfClIhZG/73qFXnLfh5TJCPCUaLatQ/8i
xxEEvP8AwqKLYAINqpDRRk1dpC1Y7cQWAx0Gr0L2z1TY6PkDdQVHxXrTajK9
BIgGvY0V/W6PSyC0w9IYxgjkt+ixCsh5vPTjdz5EcBRhTfY9vn6XuvfPP5VA
F6+laMQlUU5DhT2NLrEm5B04XHBstYUvmB4Y9434GscMnuTsBo4pDvfoELIL
HduHDgyTU8CvLXnpAAaUFwHJZpKFzhF3fE7Dr+QwIiKji9J8hVTGD3dKrDbX
pLCycdIyvv5Xfr4y0LWeNn7AKjdo0bq8E+ZLoyPwHmHfKvza9HaPs1VvUk43
r2Xh469afYacUeRS4AHvFXGVtRrwRTMeA7yZEj1jkxOsCbxPMtLhmWU4+M2v
ez6NLvEqQ7dW5YFm4qPzbyyLs1hGjwPIp7f1CsoLHLJaSjdrCFuaHE2B0FpW
KhvelFtPaCI5PsbI5tBch1RGzD4LV3FZg6WL1dxS9MKyWBHwK/wez/Ubq9dU
4m47iu8i
=LrHg
-----END PGP SIGNATURE-----
publickey - [email protected] - 0x3E936359.asc
Description: application/pgp-keys
publickey - [email protected] - 0x3E936359.asc.sig
Description: PGP signature
_______________________________________________ GROW mailing list -- [email protected] To unsubscribe send an email to [email protected]
