Cornishes

[Phillips, Addison]

> 
> > The clock rules we are currently using:
> >
> > - you MUST allow at least two weeks for any given request
> 
> Well, for a technical change to a request, I take it. Formatting of
> bibliography or whatnot would not apply.. or would it?

Under current rules in the RFC, two weeks is for the overall request. Then you must accept, reject, or extend discussion. The current RFC does not talk about editorial (or other) changes to the request. Whether we consider those "part of the original request" (i.e. they don't restart the two weeks) or "new requests" is probably a decision you can make.

The current draft (in last call over on LTRU) recognized some problems could arise (and, in fact, have arisen) from a strict two-week cycle. Many requests come to the list with editorial problems; others (cf. pinyin) engender some discussion that bears on the content of the request. To address this, the draft allows for edits to occur without regard to the two-week clock.

> 
> > - (per 4646bis) the final record must appear at least one week
> prior
> > to submission to IANA
> 
> No objection to that practice; I note we did allow agreed editorial
> corrections during that one-week period.

Under current rules in the RFC, there is no one-week period. We have implemented this informally.

Under the draft rules, the answer would be: 'no'. The *final* record, identical to what is submitted to IANA, must appear on the list for a week. That is, if on the last day of the official two-week period someone (say Doug) edits the text to (for example) remove a period from the Description, the total time before submission to IANA would be three weeks (the two week period plus the one week for the final record). You don't have to give a two-week extension in that case.

The idea here is to reduce friction in the process by allowing discussion on the list to be reflected in the request without resetting the two-week clock: it is still the same request, so restarting the discussion each time is disruptive. This is especially true since most requesters have some minor issues to fix to meet the various rules and so forth. However, it was felt that list participants need to be guaranteed enough time to respond to changes in the request before you make an approval/rejection decision. Hence the one week.

> 
> uccur, ucrcor, kucor, kuacor... There's no real optimization
> possible
> here. Since the user community uses UC and UCR (more then KU and
> KUA)
> it seems prudent to stick with those.
> 

Fine with me, then.

Addison