Re: [Tools-team] Re: Agenda item: rendering of drafts

On Thu, 23 Sep 2004, Henrik Levkowetz wrote:

> Consider this: The secretariat may also wish to use this tool 
> internally, in order to do some things which have much the same 
> logistics as draft submissions - such as setting tombstones.

I agree that Secretariat needs a tool or tools for internal use. I 
still have not heard any arguments why all those tools should be 
documented in the ID Submission draft. You say "same logistics", but 
that is not precise enough to make scoping decision. All these tools 
revolve around drafts, but that does not mean there should be a single 
tool doing all things. You have already agreed, for example, that 
"request to publish" tool should be separate.

> The requirement which has not been made explicit would then be that 
> the tool has two modes, one public and one internal, where the 
> internal mode permits the secretariat to do a number of things:

Internal use by Secretariat is already explicit in the ID Submissions 
draft (but needs more details, see below). However, I do not think 
that every known internal activity related to draft manipulation and 
rendering should go into one ID Submission tool.

> 	* Post a draft which does not pass the nits check cleanly, but
> 	  has been manually checked and found Ok

The documented "Adjust and submit to Secretariat" path gets the draft 
to the Secretariat attention. That path lets the Secretariat post the 
draft (if appropriate) using the same toolset. The tool code will know 
(most likely via HTTP authentication) that it is being executed by the 
Secretariat and will allow them to force posting.

> 	* Post a tombstone, which should not be possible through the
> 	  public interface.

I cannot think of a case where posting a tombstone would be explicit. 
It is always a side-effect of some state changes (and this whole 
recent tombstone practice may need serious revisions, but none of that 
seems to be specific to ID Submission draft).

> 	* Other admin stuff - I assume this is where the rename etc.
>         comes in.

Right, but I still do not understand why everything and the kitchen 
sink needs to be documented in one draft. Can we please limit the
scope of the ID Submission draft to "getting the draft to the 
draft repository"? This is the currently documented scope. Expanding 
it to rendering and posted draft management will, IMO:

 	- delay final draft publication (because there will be
 	  a lot more stuff to document and argue about)

 	- delay draft approval (because more controversial
 	  changes will be pulled into the draft)

 	- delay implementation (because there will be more things
 	  to implement)

Instead, I suggest that we provide a map between all currently known 
Secretariat requirements and drafts, but do not bloat the ID 
Submission draft:

 	- "getting the draft from IETFer to draft repository":
 	  "ID Submission" draft

 	- "manipulating a posted draft":
 	  "ID Manipulation draft" or drafts

 	- "displaying draft and its metadata":
 	  "ID Access" draft

This way we can make visible progress now and get tools implemented 
faster, while not ignoring important requirements. Any objections?

Thank you,

Alex.

_______________________________________________
Tools-team mailing list
Tools-team@ietf.org
https://www1.ietf.org/mailman/listinfo/tools-team