Re: ISSUE: Checkgroups control messages

Thorfinn <[email protected]>
Newsgroups gmane.ietf.usenet.format
Message-ID <[email protected]>

On 23 Sep 2008, at 11:49, Russ Allbery wrote:

>
> Thorfinn <[email protected]> writes:
>
>> 640kb should be enough for anyone. Um. :-)
>>
>> That is, yes, 32 bit unsigned integer is better, not 15 bit.
>
> Just to clarify, the current draft has no limit at all.  I think  
> it's safe
> and reasonable to add a limit of 2^32 - 1, but I'm always nervous  
> about
> adding limits on values because you never know when you might want  
> them to
> be larger later.
>
> On the other hand, Julien has a good point that implementers aren't  
> going
> to add a bigint implementation just to check sequence numbers.


*nod* 64 bit is becoming fairly prevalent, and that should certainly  
be enough.

That said - the DNS world is pretty used to using a 32 bit integer  
circle for comparison.

Looking at the current USEPRO text... *ponder* Serial number MUST  
increase.  That is definitely a problem - you certainly can run out of  
32 bit integer.  It's not all that likely, but it's certainly possible.

You're not likely to run out of 64 bit integer, provided you aren't  
silly and start somewhere near the very top of the integer space.

I'd be uncomfortable putting in a 32 bit limit unless we also change  
the text to deal with serial comparison in the same way that DNS  
serial numbers are compared.

 From RFC 1035:
SERIAL The unsigned 32 bit version number of the original copy of the  
zone. Zone transfers preserve this value. This value wraps and should  
be compared using sequence space arithmetic.


-- 
<a href="http://tertius.net.au/~thorfinn/">[email protected]</a>
~/ For those who've come across the seas, ~/ We've boundless plains to  
share, ~/
~/   With courage let us all combine,     ~/    To Advance Australia  
Fair.    ~/
      -- The end of the second verse of the Australian National  
Anthem. --
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.