James,
> On Apr 16, 2026, at 11:34, James Bensley <[email protected]> wrote: > >> 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. > Again, understood. Having not read rfc2622 in a while and how new extensions are intended to be handled, I couldn't recall what the intended behavior would be if the responding server is unable to implement the necessary bit of set math for the client. I think at most this becomes a discussion point for a new operational considerations section. I also recognize that such sections are likely not present in other documents covering prior extensions so this would be a bit of a new burden. (Although, ideally only a paragraph at most.) > 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. It is highly likely that a portion of the documentation for a bit of that remains from my time at Merit working on RADB trying to figure out that same set of undocumented stuff. :-) > 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. A better access protocol would be nice and I agree with your points that this would add client complexity. End of the day, this is mostly recognizing that IRR and its toolchains sadly remains a helpful bit of dumpster fire. I was mostly hoping we could at least avoid adding a bit of accelerant to it. -- Jeff > > 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><publickey - > [email protected] - 0x3E936359.asc.sig> _______________________________________________ GROW mailing list -- [email protected] To unsubscribe send an email to [email protected]
