Re: ISSUE 1583 status (was: Re: January: open issues on USEPRO)

Discussion mostly occurred in late September 2008, under the subject  
line:
ISSUE: Checkgroups control messages

I can't remember whether we had issue numbers at that point, but for  
some reason the original subject line didn't, and nobody fixed it.

I had something to say back then regarding sub-issues 2 and 4 below,  
and had nothing to say at that time about 1 and 3.

On 2 Feb 2009, at 12:43, Russ Allbery wrote:

>
> "Charles Lindsey" <[email protected]> writes:
>> Harald Alvestrand <[email protected]> writes:
>
>>> 1583 USEPRO LC 5.2.3: Checkgroups control messages
>>>   Open. There may be multiple issues here.
>>>   No discussion with "1583" in the subject.
>
>> I think we agreed that the present checkgroups message has a  
>> problem. The
>> draft introduces a new feature which addresses that problem, which  
>> will
>> work fine if checkgroups issuers use it, and it checkgroups receivers
>> recognise it.
>
>> But if it isn't used or recognised, then the original problem will
>> remain, and there is nothing much we can do about it. Therefore I  
>> think
>> no action is needed - the present wording is the best that can be  
>> done.
>
> There are four issues in this ticket.
>
> The first issue is that there's no method in the checkgroups syntax to
> delegate control over a newsgroup whose name matches the  
> subhierarchy.  I
> think we agreed that, yes, this is the case, and there's nothing we  
> can
> really do about it at this stage and while still remaining
> backwards-compatible.

I think someone mentioned something about issuing the delegation in  
the parent checkgroups, but I don't recall the details.

> The second issue was about whether there should be a maximum size of  
> the
> serial number.  I believe we decided that since you can compare serial
> numbers as strings, there wasn't a need to set a limit.

Yes.  Specifically, if you skip any leading zeros, then compare string  
length, then asciibetically compare if strings are the same length,  
you have an ordered integer comparison method, with no need to  
actually use an integer representation at any point.

Given the infrequency of checkgroups, the relative inefficiency of  
this comparison vs integer comparisons is a total non issue.

> The third issue is about what to do when a serial number is  
> specified for
> a hierarchy and then a subsequent control message arrives without a  
> serial
> number.  The current document is silent on what to do in this  
> situation.
> I think it should state what should be done.  My sense of the previous
> discussion was that most people felt that such a checkgroups should be
> ignored, meaning that once an authorized control message sender starts
> issuing checkgroups with serial numbers, subsequent checkgroups for  
> that
> hierarchy must always use serial numbers, which must always be  
> larger than
> the previous serial number.  I'm a little worried about this  
> provision,
> since after long periods of time and a change of hierarchy  
> administration
> it can be potentially difficult to uncover the previous serial number.
> But I don't see a good alternative that preserves the serial number
> semantics.

I don't see any way to do that.  I think it's a reasonable assumption  
that if you can't find a serial number anywhere, including by posting  
in newsgroups and asking newsmasters for what their latest one is,  
then it has probably become irrelevant.  After all, if nobody at all  
knows what their latest checkgroups serial number is, then they can't  
be able to compare with it.

This seems like an "unlikely to be a problem" situation to me.  I  
think we should explicitly say that once you have gone to serial  
numbers, there is no way back to having no serial numbers.

> The fourth issue is whether there should be a mechanism to reset the
> serial number.  I think we decided that we weren't going to specify  
> one.


Yes, I believe we should not specify one - there is no good way to  
specify a reset, and combined with the ability to simply continue  
incrementing into integer infinity, there is no need for a reset.

The closest thing was my suggestion that we could use the DNS serial  
number mechanism of sequence space arithmetic (i.e. a wrap-around -  
see DNS RFCs or the original discussion in september for details if  
needed), but I believe that that is more problematic than simply  
allowing incrementing into infinity.

Ook,

  Thorf

-- 
<a href="http://tertius.net.au/~thorfinn/">[email protected]</a>
The world is coming to an end.  Please log off.  -- BSD fortune file