Hello James, Thank you for your comments on the draft!
You raise a good point around GTSM—we will discuss adding an additional field at our next authors’ meeting. We will also clarify the versioning and API type. Our initial yaml specification of the API did track the version (https://github.com/bgp/autopeer/blob/main/api/openapi.yaml) but if that is not clear in the IETF draft, we will certainly make it clearer. We had discussed moving the yaml specification into the draft as well, so we can explore that for the next version. Thank you for your feedback on the draft, Jenny From: James Bensley <[email protected]> Date: Sunday, July 20, 2025 at 2:33 AM To: Jenny Ramseyer <[email protected]>, Grow <[email protected]> Subject: Re: [GROW] Re: Peering API: new version draft-ietf-grow-peering-api-01.txt -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi Jenny and co-authors, I had a coupe of afterthoughts since my last email. The first is that the document doesn't provide a method for specifying the use of BFD, nor the use of GTSM. I know that traditionally the use of these has been limited, IMO, primarily because they haven't been supported in hardware and/or software, which I believe is no longer the case (most vendors now support both, and at scale). I think it would be wise to include these as fields for two reasons: 1. Because I am seeing (anecdotally) a slow increase in their adoption which I expect to continue to increase with time. 2. To avoid locking operators in to the way something has historically been done, and not providing them the option to break out of that. This leads me on to my second point; future proofing the API. I know that RFC9205 is referenced and it is hinted in the draft document that a REST API is being specified but it's not 100% clearly stated, so I think whatever API type your going for here, you should 100% clearly state it, otherwise implementations won't be compatible. RFC9205 also provides mechanisms for version control of the API. In the future you are going to want to add/drop/alter fields, and/or change behaviour, or authentication methods. I think again you should provide a statement on exactly which kind of API versioning and version detection should be used. Related; explicitly define behaviour for unrecognised fields, should these be ignored or treated as an error (this relates to API version control)? Apologies if my ramblings aren't helpful. With kind regards, James. -----BEGIN PGP SIGNATURE----- Version: ProtonMail wsG5BAEBCgBtBYJofLfRCZCoEx+igX+A+0UUAAAAAAAcACBzYWx0QG5vdGF0 aW9ucy5vcGVucGdwanMub3JnuBD5RUllyV3KpUMEn9+Off9ph/xCnH2XsfGf UE1k/JYWIQQ+k2NZBObfK8Tl7sKoEx+igX+A+wAAhIMP+gIJaTcP9Z4cl6FC l/vMHUXC3hkWdGJ9IGcpGFHfbwCQ0fi9rVX+Poyp28RulI+2dwHndM2qb9f0 x6XDnzxaV5aUCRwDWXleT3wJS3OmlF9h0/FDmRfh14JPab1i2LYUfFt6/UVD gtyHTy8p5CgQmMunTeBdIYxG4wEk9IJFnIN9B9LHlhoqfzqATTX+tWg1AMfd 7lfIwI6kDCBLm/RKPEpTxy7IyQYzXRdY0Dd4JNdUP9zHnHiGem4pFbmts7Rd 8yvzABduiMaCHyY/3bzeFtPbct7UkJGaWkRydlRBU1F5ZwMJvgbCnJ+p9Iyx CXyalaM/uM4+d3v8QC6UPGn6DBpE3Rjui793y1S5uAM+ViSW9+cWI7TbSxvF jYCzC1dynfZOxPdqJeOTr8690b0vm61EVTcJpVzB+pHQZ/Funj/EyR54TaG0 FYoo6ss5cjkrKIWkRmlVv3rUAt9Mc1MxJZ5l8KZkUmplMkged/JV5QEtfjo7 uW7eUpShlG+wyUgDDPQM3mv/Vg6IGDuKUf/C8iEqbmQenCfJ+SyiZNZSgTZR xiROGswkPZRTHcjjmbUl7E47h5FXGAvPLCaBEUQQ4uczoFTUOtLpbECw7SxA B8NlwyorefvO+soiaCTzuQgxMhTMTffVK4mFIlIdkr9Uss/70f3buPD9qGJT 8lemzjTe =cfL0 -----END PGP SIGNATURE-----
_______________________________________________ GROW mailing list -- [email protected] To unsubscribe send an email to [email protected]
