On Dec 15, 2010, at 6:16 PM, Nick Hilliard wrote: > 1. please encode 1970-epoch timestamps as 64 bits, not 32. 32 bits will > break before I retire.
This is not out of the question, but keeping in mind that there's already implementation of the currently specified format, what is the value of making an incompatible change in order to avoid a wrap in 2106? I'd think that given 96 years to work on it and a grasp of modular arithmetic, it may be possible to work up BMP listeners that deal gracefully with the wrap. Further feedback from the WG on this point would be welcome. Also, out of curiosity, do you really expect to still be working in 2106? > 2. ASCII. Sigh. Colleagues keep threatening to educate me about text internationalization but it hasn't happened yet. If someone would care to contribute the least-onerous possible revision that would make the spec internationally correct, that would be welcome. > 3. maybe TLS/SSL instead of ipsec? It's not that I loathe ipsec (I don't); > it's just that ssl is much easier to implement, as there are well > understood client system APIs for it. IPSec is exemplary, not normative. TLS/SSL is another example, we can mention it and list in the Informative References too if folks feel that would be helpful. > 4. address encoding: would it not be wise from an implementation point of > view to include the protocol number near the address fields, on the basis > that ipv4 == len(4) and ipv6 == len(16) is, well, a bit hacky? What if > there's some other protocol in future which might want to use BMP? I won't argue it's not a bit hacky but it's a fairly common idiom. As a practical matter, BMP is pretty tightly bound to BGP and BGP is only specified over v4 and v6. I won't argue that generality isn't good in principle though, all things being equal. Feedback from the WG on this point would also be welcome, again bearing in mind that there's already running code. Regards, --John _______________________________________________ GROW mailing list [email protected] https://www.ietf.org/mailman/listinfo/grow
