On 16/12/2010 20:00, John Scudder wrote:
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.
I'm getting my signage mixed up - the 2038 problems associated with epoch
timestamps are related to signed 32 bit time_t rather than the unsigned
quantity used here. I agree it's less of an issue in this case - although
electrons are pretty cheap and if this were version 0, I'd be more
interested in seeing 64 bits on a matter of principle. As there's running
code, maybe it would be easier to stay with 32 bits.
Apologies - I'm jumping into this rather late in the proposal, with no
background context. Hence the revision 1 style comments on the revision 5
draft.
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.
I appreciate the difficulties here, and I'm sure you do too. But as a
general comment which is not particularly related to BMP, the ietf is
rather english/ascii centric, despite the fact that a large portion of its
global constituency doesn't even use latin based character sets. Some
time, as a point of policy, it may be good for the ietf to consider moving
away from ASCII to e.g. UTF8 for text strings in newly-designed protocols.
This isn't anything specific to GROW, though.
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.
It is exemplary, yes. However, implementers sometimes believe that
examples are in fact recommendations. At least mentioning SSL/TLS would be
good, as ipsec causes so much stomach acid for both implementers and end-users.
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.
Yeah, again considering the running code issue, it may be more prudent to
leave this as-is, even if it would have been better on day 1 to formulate
it more elegantly.
Perhaps if there are future updates to BMP which cause protocol
incompatibilities, it may be more appropriate to consider these suggestions
then rather than now.
Nick
_______________________________________________
GROW mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/grow
