Hi, Jari,
I had replied to Russ offlist, but since you're also thinking about ways to
relax this restriction...
You do need new code if you want to enforce everything automatically.
Alternatively, we could assume that anyone with a draft they want to
"pseudo-submit" is posting it on some random website and posting a link to
the
working group mailing list anyway ...
(am I the only person who sees "until this draft is announced, it's
available here" postings?)
... so the only drafts we're throttling are the ones that we need to REALLY
submit, so we can progress them toward publication ...
... so we might just decide that this is just as bogus as "drafts disappear
after six months", for the same reasons, and remove the block completely,
and trust WG chairs to ensure that drafts discussed in the meetings WERE
announced early enough for participants to read them.
Thanks,
Spencer
I am in favor of relaxations in this area. I realize that new code would be
needed in the submissions tool, but I don't think it would be too hard
either. We already treat expirations differently depending on the tracker
state. I have not looked at the submission tool code, but I would be
surprised if it cannot access drafts database and tracker contents.
I currently have several drafts in a state where the IESG, authors, and
the WG are talking about the changes needed to approve the document. In
one case we have a very long list of RFC Editor notes that appear
satisfactory. In theory we could approve the draft with those, but I would
like to use RFC Editor notes for minor corrections, and this one is not...
so a new draft would be preferred. Yet it cannot be posted at this time.
Having the new draft would also make it easier to have a discussion with
the WG, because then the usual tools diffs etc would be available.
So, my suggestion would be to add a change to our long list of tool
development tasks. In its simplest form, submissions should be allowed
even after the deadline has passed if tracker state > pubrequest. Other,
more complex policies might also be possible, but they would need more
discussion. For instance, chair decision, allowing updates of drafts that
have already been updated shortly before, etc.
Jari
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf