Subject: Re: [NNTP] Consensus?

From: [email-masked] (Thomas Gschwind)
Date: Fri, 12 Aug 2005 10:53:36 +0200

On Wed, Aug 10, 2005 at 04:53:16PM +0100, Clive D.W. Feather wrote:
C> > For (1), the discussion has been wide-ranging enough that I'm not sure on
C> > (a).  I know some folks here would like the limit removed entirely, but I
C> > don't have a good feeling on what people think about 2^32-1 versus 2^31-1
C> > assuming that we keep a limit.  More discussion would be valuable there, I
C> > believe.
C> 
C> The reason for keeping a limit is that it describes existing practice, and
C> that's what our charter talks about. Recent discussion has shown that some
C> existing practice uses signed int for this, so 2^31-1 is a genuine limit on
C> those systems.

The problem I see with setting a limit means that the limit will be
reached and as soon as the limit IS reached everybody WILL start
implementing a different solution to the problem.  And then we can again
catch up and document standard practice which would be painful.

On Thu, Aug 11, 2005 at 09:30:20AM -0400, Ken Murchison wrote:
K> Clive D.W. Feather wrote:
K> >It doesn't represent current practice, which is what we're supposed to be
K> >documenting.
K> 
K> True, but it sounds like current practice is all over the place (2^31, 
K> 2^32, 2^64), so we need to standardize on something.  Standardizing on 
K> something that we *know* will break in a few years doesn't seem like the 
K> best move when there is a relatively simple solution which will push the 
K> problem out far enough where most, if not all, of us on this list won't 
K> have to worry about it.  ;)

I could not agree any more with this.

C> However, something like:
C> 
C>     While servers MUST NOT send article numbers greater than this limit,
C>     client and server developers are advised to use internal structures
C>     and datatypes capable of handling larger values in anticipation of
C>     such a change.
C> 
C> might work.

This would be trade-off that I could easily live with.  Everybody
capable of writing any client software will understand the hint.

On Thu, Aug 11, 2005 at 09:27:04AM +0100, Clive D.W. Feather wrote:
C> Russ Allbery said:
C> >> Personally I would like the wording changed to require (a MUST) 32 bit
C> >> support and suggest (a SHOULD) 64 bit support.
C> > That's two people supporting that option.  What does everyone else think
C> > about that?
C> 
C> I seriously don't like it.
C> 
C> It doesn't represent current practice, which is what we're supposed to be
C> documenting.
C> 
C> It introduces an interoperability issue. What happens if the server
C> supports the SHOULD and the client doesn't?

As long as no newsgroup has reached the 2^31-1 (or 32) limit nothing.
Afterwards, the client won't be able to read news and will be forced to
upgrade the news client (or switch to a different one).  While forced
upgrades are typically a bad idea, I think in this case it is acceptable
since
1) Clients have >> 2 years time to upgrade their software which should
   be enough time for people to upgrade (cannot be backwards compatible
   forever).
2) 2 years with Steve's scheme which I agree is broken since it breaks
   all kinds of assumptions made by news clients.
3) If too many clients are affected they will complain at their news
   service provider which
   a) will either change the software (ie throw out Steve's software)
   b) or reset the article numbering if they have a sane server that
      exceeded the high limit (which with the current draft would be the
      only option anyways).

C> Finally, think how it actually would go into the wording. To remind you,
C> this is what the text currently says:
C>    [...original deleted...]
C>    [...nonsense version deleted...]
C> because that's a nonsense. Do they mean the inverse?
C> 
C>    Article numbers MUST lie between 1 and 2^64-1 inclusive and SHOULD
C>    lie between 1 and 2^32-1 inclusive.

That's only a wording issue and surely can be fixed.  What about (please
feel free to tear it apart ;) so that we can fix any bugs)?

  Historically, article numbers lie in the range between 1 and 2^32-1
  inclusive.  In the future, however, this range likely will not be
  sufficient.  In anticipation of an increase of this range news client
  implementors SHOULD be able to deal with an article number range
  between 1 and 2^6[34]-1.
  
  News server implementors SHOULD be aware that if they generate
  article numbers above 2^32-1, some news clients will break in an
  unexpected manner.  Until "all" clients have been upgraded to handle
  the larger article number range, news server administrators should be
  provided with a configuration option to have the article numbers
  reset (within the newsgroup in question).
  
C> What is the effect of breaching the SHOULD?
C> 
C> Let's see some actual wording proposals here, including addressing the
C> inter-operability issues when any SHOULD or MAY is breached.

For a fair treatment of this subject, this should be done for any
option.  Basically the options are:
* reset => I guess most of us agree that this is not a great thing to
  do since many clients will be confused about the articles they have
  read and not read and people would have at least to "re-read" their
  newsgroup.
* wrap-around => Clients do not implement this hence for them it has the
  same effect as a reset.
* generate larger numbers (as soon as necessary) => in a couple of years
  (2 if someone uses Steve's broken server) "old" clients will start
  breaking.  But IMHO, they had enough time to upgrade.  In case their
  are too many of those around they should complain at their news
  provider who might reset the newsgroup if there are too many of "old"
  clients.
* not accept new articles => not an option.
* BIGNUM extension => Current clients won't be helped by it, how does it
  deal with current clients?  "Old" clients won't be able to read any
  articles >2^32-1.  A benefit is that they won't crash.  I guess we
  have different opinions on the acceptability of this (ie
  likelihood/badness of this).

Regards,
Thomas
-- 
Thomas Gschwind                      Email: [email-masked]
IBM Zurich Research Lab
Saeumerstrasse 4                     Tel: +41-1-724-8990
CH-8803 Rueschlikon, Switzerland     Fax: +41-1-724-8953

---

From: "Clive D.W. Feather" <[email-masked]>
Date: Fri, 12 Aug 2005 16:12:47 +0100

> catch up and document standard practice which would be painful.

Not if we start the work now. I have no objection to starting the work, but
we shouldn't hold up the base document because of it.

> K> there is a relatively simple solution which will push the 

I don't accept that just telling people to use 2^64-1 is a solution.
Existing clients *ARE NOT* going to be updated "just like that", and any
proper solution needs to work reasonably well with such clients.

This is not "a minor change" and I don't believe we can just sneak it into
the document without wider review.

> capable of writing any client software will understand the hint.

Right. That gives us the breathing space we need.

> C> Finally, think how it actually would go into the wording.

> That's only a wording issue and surely can be fixed.

Yes, but I want to see real proposals.

>   unexpected manner.

I *really* don't think wording like this belongs in the document. "Break in
an unexpected manner" should be restricted to clients that violate a MUST.

>   Until "all" clients have been upgraded to handle
>   the larger article number range,

Which is when? IETF frowns on "flag days".

>   news server administrators should be

This would need expanding somewhat.

> option.

Agreed.

> Basically the options are:

Right.

>   provider who might reset the newsgroup if there are too many of "old"

That's not interoperability.

>   likelihood/badness of this).

BIGNUM is very similar to "generate larger numbers", except that it
provides defined behaviour for clients that haven't been upgraded.

-- 
Clive D.W. Feather  | Work:  <[email-masked]>   | Tel:    +44 20 8495 6138
Internet Expert     | Home:  <[email-masked]>  | Fax:    +44 870 051 9937
Demon Internet      | WWW: http://www.davros.org | Mobile: +44 7973 377646
Thus plc            |                            |

---

From: Steve Walker <[email-masked]>
Date: Fri, 12 Aug 2005 11:23:01 -0500

> proper solution needs to work reasonably well with such clients.

Could you explain how it would cause any existing client or 
server to break that wasn't already going to break at the same 
point in time?  My point, as well as several others, is that a 32 
bit client and a 64 bit server will quit working at the exact 
same time that the 32 bit server overflows.  If we advocate using 
64 bit numbers then at least some clients will work when the time 
comes.  The current wording causes all clients to fail.

> the document without wider review.

It wasn't a minor change to add the 32 bit wording either, yet it 
was added.  If you really want to leave the issue open, the new 
32 bit limit need to be removed from the proposed RFC977 
replacement.  By asking people to address this issue in a future 
RFC you are effectively telling software developers to use no 
specified limit (RFC977), then use a 32 bit limit (V2), then use 
xyz limit (V3).  It should be either fixed correctly or not 
changed.  You seem to be ignoring the fact that there are popular 
64 bit clients in use today.  The new wording causes existing 
software to become non-compliant.

Steve.

---

From: Russ Allbery <[email-masked]>
Date: Fri, 12 Aug 2005 09:57:39 -0700

>> This is not "a minor change" and I don't believe we can just sneak it
>> into the document without wider review.

> It wasn't a minor change to add the 32 bit wording either, yet it was
> added.

Yes, it was added eight years ago and went through at least three internal
last calls, multiple public postings to news.software.nntp including one
with complete text, two complete IETF-wide last calls, and an IESG review.

We are not now in the same phase of this process that we were when the
limit was added.

> You seem to be ignoring the fact that there are popular 64 bit clients
> in use today.  The new wording causes existing software to become
> non-compliant.

64-bit *clients* are compliant with the existing wording.

-- 
Russ Allbery ([email-masked])             <http://www.eyrie.org/~eagle/>

---

From: "Charles Lindsey" <[email-masked]>
Date: Sat, 13 Aug 2005 21:30:46 GMT

>point in time?

No client is going to break until some server breaks first.

If we do nothing, then it is a few servers which are going to break. That
is their problem. They will have to come to some arrangement with their
clients what to do about it.

And when we do produce our 'official' solution, it will have to include
some workaround for all those existing clients.

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: +44 161 436 6131 Fax: +44 161 436 6133   Web: http://www.cs.man.ac.uk/~chl
Email: [email-masked]      Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K.
PGP: 2C15F1A9      Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5