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

"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.

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.

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.

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.

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