-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi Jeff,
> At least part of this question is motivated by laziness in not wanting to > re-read 2622. :-) I can sympathise with that :) > Adding at least one such example on top of Job's observations, my biggest > question is where the exclusion is getting implemented and whether there are > consistency concerns. Inconsistencies are inherent in the design of the IRR DB ecosystem. Here we see two public servers running the same software (IRRd) but slightly different versions: $ nc rr.level3.net 43 !v A22 IRRd -- version 4.4.3 C $ nc rr.ntt.net 43 !v A22 IRRd -- version 4.4.6 C The version diff is minor, and the release notes from 4.4.3 to 4.4.6 inclusive (https://irrd.readthedocs.io/en/stable/releases/4.4.3/) suggest no change in behaviour with regards to the data returned by the whois interface. Yet querying both servers gets me different outcomes: $ bgpq4 -h rr.level3.net AS-ALL | wc -l 2 $ bgpq4 -h rr.ntt.net AS-ALL | wc -l 64 This is because the servers use different data sources and have different configurations. It is already the case (in my opinion) that the user has to be aware of the configuration of server they are using. Additionally, configuration options exist (specifically in the IRRd implementation), that for example, won't return prefixes which are ROA invalid. I think RADB is using this option? So if a user builds filters against RADB's public instance, they will get different results than if they had used another public instance, with the ROA filtering option disabled, even if both instances had the same data sources and the exact same software version. So from this perspective, the suggestion in this document wouldn't change anything as far as I understand (correct me if I'm wrong here); users still need to be aware of the server they are using (this is something that could be made clear in the document if it helps?). > What happens when you're talking to a bit of software expanding the sets that > may not understand this new exclusion mechanism? My suspicion is you simply > get the result without such exclusions. The proposed mechanism of using a new attribute means that existing software which is RFC compliant ignores unknown attributes and carries on as normal, it's not bothered if it comes across the new attribute, and produces the same output as if the attribute wasn't present. Software which is updated processes the encountered exclusions and provide the results with the exclusions applied. The idea here is to ensure backwards compatibility (exiting software deployments don't explode if they encounter the new attribute). I hope that clears some things up, if not, please let me know. With kind regards, James. -----BEGIN PGP SIGNATURE----- Version: ProtonMail wsG5BAEBCgBtBYJp4KhACRCoEx+igX+A+0UUAAAAAAAcACBzYWx0QG5vdGF0 aW9ucy5vcGVucGdwanMub3JnCEidoRFUOjcyJ0rRjnIFFFi8x/5ODKXJ8QQ3 WlScnloWIQQ+k2NZBObfK8Tl7sKoEx+igX+A+wAAM10P/j+AgjfvOOSIxSeD bNHI3IDfAWFycHG2F/wGFbRmNYf+4PG/DwIMBaOddXimaTt6881vEbKFPNBN cJ6MIHNMF/ZmpD2Gnp5KStA1bvTdw/H516ZVn4JD/kdU7M2rBaBCQ1NYhinG k1iL77PFVNlYA3m0tJUuvutUzzZd4jUc+R8ZzojI8LZzO+Wk5PL12RVt/iV1 5JXjrYZ74yiqfpKZLYi741SZL71IgjVXX+1pNGA2hbuvCrhja4c8mBwaax9M gdyR7mCamYszbZ9cvwxpObZw+s+qGPQFE8yK7Y2XfxBCNpMpdHv50+/sID1J xHtclsSEeUI4nmzVIFEYcaH+gIjmyfEJSArcvbvtx42IjCnWBdIzFQjZl1BF 3dxgvd4DmUELMoJ4GzOd7f80g9a9vI6XO/xgCaCilKj8v9IkXVaezA8u3qm6 IGe9Nt8Huwu/15KpcONUwjHAFOShzE7STfObYD79eP24OOtmEowYxgxrk6oe 6e2CBao+zFM/8v4+g3J1vK6RJZtdsfX+bSIGAo70zvd0WrkAeizoqGlWG4bA Q4xh/bUGVyfSKPRlnAq4q66EHb2k5kiizTnKoUYLzy3jO0R62BH73M3Zj5JC sjt7xguNFqY8d5mxAY92HYObke0tP+TgyJj8EYIIHBfo34a8S4L9e5Y3IZs9 qZiq4+8h =I31n -----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]
