-----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-----

Attachment: publickey - [email protected] - 0x3E936359.asc
Description: application/pgp-keys

Attachment: publickey - [email protected] - 0x3E936359.asc.sig
Description: PGP signature

_______________________________________________
GROW mailing list -- [email protected]
To unsubscribe send an email to [email protected]

Reply via email to