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

From: Henrik Levkowetz <[email-masked]>
Date: Wed, 22 Sep 2004 19:13:33 +0200

Alex, 

	let's take this one on the list.  Would you send out a summary
of the issue, and your proposal?

	Henrik

_______________________________________________
Tools-team mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/tools-team

---

From: Alex Rousskov <[email-masked]>
Date: Wed, 22 Sep 2004 11:49:42 -0600 (MDT)

Secretariat requirements for the ID Submission tool available at 
http://www1.ietf.org/mail-archive/web/tools-team/current/msg00090.html 
contain Section VI "I-D Status and Version Number".

This section has requirements on rendering drafts in various stages 
such as Active, Expired, Replaced-By, or Withdrawn. These requirements 
talk, in part, about making draft versions visible or invisible to the 
public and about creating tombstones for invisible or future draft 
versions.

I believe these requirements do not belong to the ID Submission draft 
because draft submission is just one of many ways to change the state 
of the draft (and, hence, change how it is rendered).

If we want to document how drafts are rendered and made accessible, I 
would suggest to create a separate "ID Rendering" draft. That draft 
will reflect current Secretariat requirements mentioned above and may 
add more requirements. For example, I would require "latest" draft to 
be accessible by name (not just name-version), document how 
alternative draft formats are made available, and require diffs.

One argument for a separate draft is that it moves the hot issue of 
making draft diffs (and hence old draft versions) available to a 
different document. Doing so may allow us to finish the ID Submission 
draft faster and get it approved/implemented soon.

Other related tools that I would place outside of the ID Submission 
tool scope are small and simple "existing draft manipulation tools":
 	- withdraw a draft
 	- request draft publication (IESG review, etc.)
 	- mark draft as "published" (after IESG review, etc.)
 	- rename a draft (do we really need that?)
All of the above affect draft state, but are not directly related
to draft rendering. Each can go into a separate draft, but they
may be small and related enough to fit into one document.

Questions:
 	1a) Does draft rendering belong to the ID submission draft?
 	1b) Do we need a "Draft Rendering" draft or should we leave
 	    it up to secretariat how to render drafts?

 	2a) Does existing draft manipulation belong to the ID
 	    submission draft?
 	2b) Do we need a "Draft Manipulation" draft OR should we
 	    leave it up to secretariat to provide those tools (or
 	    handle those actions manually via Secretariat ticket
 	    system)?

N.B. There is probably a better term than "rendering" for the "Draft 
Rendering" draft. "Draft Access"?

Thank you,

Alex.

---

From: Henrik Levkowetz <[email-masked]>
Date: Wed, 22 Sep 2004 22:56:13 +0200

Thanks, Alex.

    My comments below are my personal viewpoints:

Alex Rousskov wrote:
> This section has requirements on rendering drafts in various stages such 
> as Active, Expired, Replaced-By, or Withdrawn. These requirements talk, 
> in part, about making draft versions visible or invisible to the public 
> and about creating tombstones for invisible or future draft versions.
> 
> because draft submission is just one of many ways to change the state of 
> the draft (and, hence, change how it is rendered).

I think these requirements capture not the secretariats wishes, but the
rules agreed on and requested from the secretariat from various bodies,
historically.  Whether or not the I-D submission tool is one of several
ways of changing the status of a draft, it will have to confirm to the
current setup, in order to fit in.  Whether or not the current setup 
should be changes is, I think, a valid subject for a proposal of an 
experimental change or parallel implementation of a parallel mechanism.

> would suggest to create a separate "ID Rendering" draft. That draft will 
> reflect current Secretariat requirements mentioned above and may add 
> more requirements. For example, I would require "latest" draft to be 
> accessible by name (not just name-version), document how alternative 
> draft formats are made available, and require diffs.

I think this would be interesting and meaningful, but as a proposal
of an experiment, or a change proposal.

> draft faster and get it approved/implemented soon.

True, but only if we make it a change proposal, rather than documenting
the requirements resting on the secretariat currently.

> Other related tools that I would place outside of the ID Submission tool 
> scope are small and simple "existing draft manipulation tools":
>     - withdraw a draft

--- I think this is only possible in the sense of submitting a draft
    which says "this draft withdrawn" - not by removal from the archive.
    To be able to submit such a withdrawal document could be left to the
    manual fallback option.

>     - request draft publication (IESG review, etc.)

--- New tool, I think.  And useful.

>     - mark draft as "published" (after IESG review, etc.)

--- Internal secretariat tool.  Makes sense to me, but is up to them.

>     - rename a draft (do we really need that?)

--- I think not, creates problems and solves none (?)

>     1a) Does draft rendering belong to the ID submission draft?

Only as a description of what the tool needs to support today, before
any (possibly coming) changes have been defined and agreed upon

>         it up to secretariat how to render drafts?

I think a separate experiment in this direction makes sense

>     2a) Does existing draft manipulation belong to the ID

I think not

>         handle those actions manually via Secretariat ticket

For one part - see above - a submission for publication interface,
I think.

> Rendering" draft. "Draft Access"?

Yes, that's better. Or accessibility, maybe.

	Henrik

---

From: Alex Rousskov <[email-masked]>
Date: Wed, 22 Sep 2004 15:52:31 -0600 (MDT)

On Wed, 22 Sep 2004, Henrik Levkowetz wrote:

>> such as Active, Expired, Replaced-By, or Withdrawn. These 
>> requirements talk, in part, about making draft versions visible or 
>> invisible to the public and about creating tombstones for invisible 
>> or future draft versions.
>> 
>> I believe these requirements do not belong to the ID Submission 
>> draft because draft submission is just one of many ways to change 
>> the state of the draft (and, hence, change how it is rendered).
>
> I think these requirements capture not the secretariats wishes, but 
> the rules agreed on and requested from the secretariat from various 
> bodies, historically.  Whether or not the I-D submission tool is one 
> of several ways of changing the status of a draft, it will have to 
> confirm to the current setup, in order to fit in.  Whether or not 
> the current setup should be changes is, I think, a valid subject for 
> a proposal of an experimental change or parallel implementation of a 
> parallel mechanism.

I am not sure I follow. I-D submission tool is a new tool. It needs to 
support some of the current setup (e.g., draft needs to be posted), 
but does not have to support all of it (e.g., existing draft 
manipulation seems out of scope to me) and may add new functions 
(e.g., accept XML sources).

I am not arguing for any changes in this thread. I am trying to define 
draft(s) scope.

>> If we want to document how drafts are rendered and made accessible, 
>> I would suggest to create a separate "ID Rendering" draft. That 
>> draft will reflect current Secretariat requirements mentioned above 
>> and may add more requirements. For example, I would require 
>> "latest" draft to be accessible by name (not just name-version), 
>> document how alternative draft formats are made available, and 
>> require diffs.
>

I do not understand the practical difference. Either we document how 
drafts should be rendered (including whatever changes we think are 
needed) or we do not document at all. It does not make sense to 
document the current rendering interface because it is already there, 
right?

>> different document. Doing so may allow us to finish the ID 
>> Submission draft faster and get it approved/implemented soon.
>
> True, but only if we make it a change proposal, rather than 
> documenting the requirements resting on the secretariat currently.

Why would TOOLs team want to document current requirements/interfaces 
if not to make changes and adjustments to them? It seems to me that 
all of our proposals are "change proposals". Every new tool or 
interface is a change.

>   To be able to submit such a withdrawal document could be left to the

I got it from the Secretariat document. See "Via this tool, the 
author or the IESG can withdraw an Active I-D" paragraph.

> --- I think not, creates problems and solves none (?)

Agreed, but, again, this came from the Secretariat document. See "Via 
this tool, one can replace an active I-D with a new I-D with a 
different filename" paragraph.

> any (possibly coming) changes have been defined and agreed upon

But ID submission toolset does not have to support any draft rendering 
or any draft manipulation. That is what I am trying to get to. These 
functions seem out of scope. But I need team's decision since these 
functions are in the Secretariat Requirements document. We cannot just 
silently ignore them.

> I think a separate experiment in this direction makes sense

Great. Any volunteers?

>>     2a) Does existing draft manipulation belong to the ID

OK. I will not include it unless there are any objections.

Thank you,

Alex.

---

From: Henrik Levkowetz <[email-masked]>
Date: Thu, 23 Sep 2004 00:51:18 +0200

> On Wed, 22 Sep 2004, Henrik Levkowetz wrote:
 [snip]
>> confirm to the current setup, in order to fit in.  Whether or not the 
>> current setup should be changes is, I think, a valid subject for a 
>> proposal of an experimental change or parallel implementation of a 
>> parallel mechanism.
> 
> 
> support some of the current setup (e.g., draft needs to be posted), but 
> does not have to support all of it (e.g., existing draft manipulation 
> seems out of scope to me) and may add new functions (e.g., accept XML 
> sources).
> 

Agreed.  What I'm saying is that to have a complete set of requirements,
we want to capture also current requirements, not only new, as far as
they apply to this new tool.  Which is why I think it make sense to
include these requirements as received from the secretariat.

>> I think this would be interesting and meaningful, but as a proposal of 
>> an experiment, or a change proposal.
> 
> 
> needed) or we do not document at all. It does not make sense to document 
> the current rendering interface because it is already there, right?

I think it makes sense to make requirements complete, as far as they
may impact the implementation of the tool.

> Why would TOOLs team want to document current requirements/interfaces if 
> not to make changes and adjustments to them? It seems to me that all of 
> our proposals are "change proposals". Every new tool or interface is a 
> change.

Because even if the tool is new, some of the requirements on it are not.
And to be useful for the developers, the requirements need to be
complete

> I got it from the Secretariat document. See "Via this tool, the author 
> or the IESG can withdraw an Active I-D" paragraph.

Mmm.  If that is something that currently can be done manually, it 
may go in.  If not, I'm not sure it's reasonable...

> this tool, one can replace an active I-D with a new I-D with a different 
> filename" paragraph.

Same comment as above.  There may be things here we're not aware of ...

> functions are in the Secretariat Requirements document. We cannot just 

No, we should try to understand the background better - there may be
things here to learn :-)  

	Henrik

---

From: Alex Rousskov <[email-masked]>
Date: Wed, 22 Sep 2004 17:07:23 -0600 (MDT)

On Thu, 23 Sep 2004, Henrik Levkowetz wrote:

> What I'm saying is that to have a complete set of requirements, we 
> want to capture also current requirements, not only new, as far as 
> they apply to this new tool.

Agreed, "as far as they apply to this new tool" is the question of 
this thread.

> Which is why I think it make sense to include these requirements as 
> received from the secretariat.

IMO, the draft rendering requirements (such as creating a tombstone) 
while received from the Secretariat, are not in the ID Submission tool 
scope. They are useful requirements, but for a different 
tool/interface. I want to make sure we do not ignore them, but would 
prefer not to put them in the ID Submission draft.

> may impact the implementation of the tool.

Agreed. I do not see how tombstone or diff creation would affect the 
implementation of the ID submission tool. Do you? Does anybody?

Thanks,

Alex.

---

From: Henrik Levkowetz <[email-masked]>
Date: Thu, 23 Sep 2004 10:16:40 +0200

Alex Rousskov wrote:
> Agreed, "as far as they apply to this new tool" is the question of this 
> thread.
> 
> scope. They are useful requirements, but for a different tool/interface. 
> I want to make sure we do not ignore them, but would prefer not to put 
> them in the ID Submission draft.
> 

Ah, Yes, I think I do know.  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.  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:

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

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

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

		Henrik

---

From: Alex Rousskov <[email-masked]>
Date: Thu, 23 Sep 2004 06:40:06 -0600 (MDT)

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.

> 	  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

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.

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.

---

From: Henrik Levkowetz <[email-masked]>
Date: Thu, 23 Sep 2004 15:08:48 +0200

Hi Alex,

On Thursday, 23 Sep 2004, Alex Rousskov wrote:
> documented in the ID Submission draft. 

I don't think anyone has been arguing that case, either :-)

> You say "same logistics", but 

Oh, I think if you consider "the same logistics" again, you'll find
that it could mean (my intention) to be basically the same sequence
of actions which an external draft submission goes through - meaning
it would make sense to make it a part of this tool.

> rendering should go into one ID Submission tool.

Again, nobody has been arguing this case.

> Secretariat and will allow them to force posting.

Somehow the tool will know, and permit this.  I think we agree.

> seems to be specific to ID Submission draft).

Considering that there may not exist some other automated way of
posting a tombstone, I see no reason at all to prohibit the secratariat
from using this tool to do so.  We can recommend that it be done by
enhancing the ID-tracker, but if the secretariat wants to have the 
option of posting a tombstone manually, I think it makes sense to do
it the basically the same way they do a forced draft posting.

> sink needs to be documented in one draft.

Again, nobody has argued that it should :-)

> . Can we please limit the

If we disregard the secretariat's expressed requirements - or worse,
actively tries to prevent them from having a tool that will cover their
needs, I think we are making a mistake.  And I think it will result in
whatever we produce, however fast, not being well received...

> faster, while not ignoring important requirements. Any objections?

By now, it should be obvious that I think it is a mistake to try to 
push out actions like secretariat forced draft posting and secretariat
forced tombstone posting, which it makes sense *to them* to have as
part of this tool.

I think we need to remember this crucial point:  The secretariat does
desire to build a tool that will help them do their work better and
easier.  We are here to provide input on the *IETF community's
requirements* on tools that are used, or will be used, by the community.

If we feel like recommending alternative designs and courses of action
to the secretariat, that's fine, but if we try to tell them that they
are not allowed to do what they set out to do in the first place,
instead of assisting with the community' side of the requirements, we
are probably not helping forward progress.

	Henrik

---

From: Alex Rousskov <[email-masked]>
Date: Thu, 23 Sep 2004 11:39:38 -0600 (MDT)

On Thu, 23 Sep 2004, Henrik Levkowetz wrote:

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

What I am trying to say is that the rendering and manipulation in 
question do not share the enough of actions/features with the draft 
submission tool. There is some overlap. of course, but not enough to 
justify packing them all into one tool. This is my point of view. 
Since this is about design, this is not something I can formally 
prove; I can only keep coming up with more examples where two tools 
are better than one.

All these tools may share a common library of sorts, of course. Still, 
in my opinion, we should specify their interfaces and requirements 
separately, both from design and our work review/approval process 
points of view.

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

Then I am not sure what case you are arguing for. We can put 
everything into one draft, we can split the way I suggested, or we can 
do something else. If you want something else, please describe what you 
want.

> Somehow the tool will know, and permit this.  I think we agree.

Here, yes. We are talking about the same action -- posting of a new 
draft. However, draft rendering and manipulation are sufficiently 
different actions to describe them separately (and such segregation is 
good from process point of view as well), IMO.

> it the basically the same way they do a forced draft posting.

Again, I do not think that there is a need to explicitly post a 
tombstone. None of the known Secretariat requirements have such an 
action. Tombstone is always a side-effect of some other action. We 
should describe that side-effect when documenting a tool for that 
action. New ID submission does not have such a side-effect.

>> 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:
>

At this time, I am not proposing to disregard Secretariat 
requirements. I propose to address their requirements via a set of 
tools. The ID Submission draft will document new ID submission. Other 
drafts will document ID rendering and existing ID manipulation. What's 
wrong with that approach, and what is the alternative?

> push out actions like secretariat forced draft posting and 
> secretariat forced tombstone posting, which it makes sense *to them* 
> to have as part of this tool.

Hmm... I have explicitly said that forced new draft posting is in 
scope so I am not sure why you are saying "push [it] out". As for 
"forced tombstone posting", I do not see that as a stand-alone action 
in Secretariat requirements. It is always a side-effect of some other 
action, and never a side-effect of posting a new draft action. It is 
also a side-effect of time passing by (which is not in current 
Secretariat requirements?). Did I misinterpreted Secretariat 
requirements?

Finally, and I realize that this may cause a few more needless 
iterations, I have to say for the record that I am not here to 
document what makes sense to Secretariat. I am here to document what I 
think makes sense for IETF-Secretariat interfaces. Hopefully, the 
difference is negligible (if any), but "it makes sense to them" is not 
a _sufficient_ condition for me to document something. The TOOLs team 
was created so that we can evaluate and balance what makes sense to 
several parties and propose what we think is the best solution.

> requirements* on tools that are used, or will be used, by the community.

Agreed.

> If we feel like recommending alternative designs and courses of 
> action to the secretariat, that's fine, but if we try to tell them 
> that they are not allowed to do what they set out to do in the first 
> place, instead of assisting with the community' side of the 
> requirements, we are probably not helping forward progress.

My understanding is that, besides satisfying IETF requirements, 
Secretariat is free to do whatever they want as long as their actions 
do not conflict with the requirements. But I am not sure why we are 
talking about this because I have not proposed to prohibit something. 
So far, I have only been asking to split addressing their requirements 
into several tools/drafts. This is about individual draft scope rather 
than prohibition.

Alex.

---

From: Henrik Levkowetz <[email-masked]>
Date: Thu, 23 Sep 2004 20:21:40 +0200

Alex Rousskov wrote:

> Secretariat is free to do whatever they want as long as their actions do 
> not conflict with the requirements. But I am not sure why we are talking 
> about this because I have not proposed to prohibit something. So far, I 
> have only been asking to split addressing their requirements into 
> several tools/drafts. This is about individual draft scope rather than 
> prohibition.

Ok.  So this draft is about the I-D submission tool.  Either one of 
the following two alternatives is OK with me:

1. Describe the requirements from the IETF community viewpoint, and
   leave the internal secretariat requirements out of it, and say
   so explicitly.

2. Include the internal secretariat requirements unabridged, possibly
   advising that some of them might be as well or better served by
   an alternative implementation.

What I don't think is OK, is to include some of them and exclude some
of them, based on what our viewpoint is on how they should do their
job - especially as it seems we (well, at least you and I) don't have
a common viewpoint on that.

About one or multiple drafts:

I understood you as advocating a different tool, with a different 
draft, for some of the secretariat requirements - I've attempted to
cover that question above.

If on the other hand you are now advocating splitting the requirements
on this one tool into multiple drafts, that is a quite different 
question, which we'll go into if that is your proposal.

Finally, if you are proposing that there are *other* aspects of draft
handling, which are not covered by secretariat requirements, and not
covered by community requirements on the ID-submission tool, then I
think we might be in agreement - but that also means we have to 
consider in what order to go into those aspects, compared to other
proposed tools and requirements.  I suspect that if this is what you
are proposing, then some of the issues could be very basic, and it 
would be of great benefit to lay them out early, while other might
have to wait.

	Henrik

---

From: Alex Rousskov <[email-masked]>
Date: Thu, 23 Sep 2004 13:45:37 -0600 (MDT)

On Thu, 23 Sep 2004, Henrik Levkowetz wrote:

> Ok.  So this draft is about the I-D submission tool.  Either one of the 
> following two alternatives is OK with me:
>

Neither sounds right to me, for different reasons (which I can detail 
if you want). How about this instead:

   1a. In the ID Submission draft, describe draft submission requirements and
      interfaces from our viewpoint, while doing our best to reflect
      corresponding IETF and Secretariat viewpoints. Tell Secretariat
      explicitly which of their known requirements (if any) the ID Submission
      draft does not address.

Let's try to agree on the ID Submission draft scope and then try to 
resolve issues with other drafts.

Thanks,

Alex.

---

From: Henrik Levkowetz <[email-masked]>
Date: Thu, 23 Sep 2004 22:19:46 +0200

Hi Alex,

>       explicitly which of their known requirements (if any) the ID Submission

I'm still very worried that this will lead us into debating points which
are internal secretariat issues, where we will churn a lot - partly
because we individually have insufficient knowledge and quite different
understanding of how things function internally in the secretariat. 

I think we can express the community requirements quite succinctly, and
I would prefer that we do just that if the alternative is to have long
discussions about the appropriateness of certain internal secretariat
requirements, which seems to be where we would be headed otherwise.

	Henrik

---

From: Alex Rousskov <[email-masked]>
Date: Thu, 23 Sep 2004 23:32:00 -0600 (MDT)

On Thu, 23 Sep 2004, Henrik Levkowetz wrote:

> I'm still very worried that this will lead us into debating points 
> which are internal secretariat issues, where we will churn a lot - 
> partly because we individually have insufficient knowledge and quite 
> different understanding of how things function internally in the 
> secretariat.
>
> I think we can express the community requirements quite succinctly, 
> and I would prefer that we do just that if the alternative is to 
> have long discussions about the appropriateness of certain internal 
> secretariat requirements, which seems to be where we would be headed 
> otherwise.

I do not want any long discussions about internal Secretariat 
requirements. As I may have said elsewhere, I do not think we should 
care about Secretariat _internals_ much. However, many draft rendering 
and manipulation requirements sent to us by Secretariat are not 
internal to Secretariat: many affect community as much as Secretariat. 
For example, having access to latest draft version, XML draft sources, 
draft meta-data, and diffs is in direct community interest (and is a 
part of the draft rendering/access interface we should define).

Thus, I suggest that we keep doing what you think we have been doing 
so far -- expressing the community requirements. I will continue to 
make sure that external Secretariat requirements (if any) are 
expressed as well.

If you ever get a feeling that we are debating an internal Secretariat 
issue, please raise a red flag, and we will decide wether that issue 
is internal or external before continuing with the debate. I believe 
we will not see too many red flags, but if we do, we can come back to 
this discussion and revise the agreement.

I think we share the desire to avoid discussing Secretariat internals. 
Would this simple solve-problems-as-they-arise procedure work for you?

Thanks,

Alex.

---

From: Henrik Levkowetz <[email-masked]>
Date: Fri, 24 Sep 2004 11:14:31 +0200

Hi Alex,

> part of the draft rendering/access interface we should define).

Ok.

> so far -- expressing the community requirements. 

You're mistaken in your assumption of what I think we have been doing.
Please leave it to me to express what I think.

I think we have been merging secretariat and community requirements
into one draft, and I see us being in danger of ratholing on it.

> I will continue to 

Let's clear the current issue up first, please.

> this discussion and revise the agreement.

Ok.

> I think we share the desire to avoid discussing Secretariat internals. 

Good.

> Would this simple solve-problems-as-they-arise procedure work for you?

No, I think we right now have a problem which we still haven't solved, 
and we should deal with it now, rather than push it in front of us.

And please, remember - the secretariat needs this tool yesterday.

* I would like to have one draft from the tools team which deals with
  the requirements for the I-D submission tool.

* Proposed *changes* to availability of drafts, XML sources, meta-data 
  etc. to go in a different draft - these are not I-D submission tool
  issues, and as they are changes, they require both buy-in from the
  IETF community and leadership, and prioritisation versus other tools.

* The I-D submission tool draft uses one of the approaches mentioned
  before (since we seem to be in danger of ratholing on merging
  requirements - I have no basic preference for these over the merging
  approach):

  1. Describe the requirements from the IETF community viewpoint, and
     leave the requirements received from the secretariat out of it, 
     and say so explicitly.

  2. Include the requirements received from the secretariat unabridged, 
     possibly advising that some of them might be as well or better 
     served by an alternative implementation.

	Henrik

---

From: Alex Rousskov <[email-masked]>
Date: Fri, 24 Sep 2004 09:36:15 -0600 (MDT)

> into one draft, and I see us being in danger of ratholing on it.

AFAICT, there are no requirements that are exclusive to Secretariat in 
the current draft. I certainly did not put any intentionally, and I 
was not going to start doing that. There are some requirements that 
community and Secretariat share, but, technically, we can still assert 
that the draft expresses community requirements and does not talk 
about Secretariat requirements.

> And please, remember - the secretariat needs this tool yesterday.

I thought you did not want to discuss internal Secretariat needs :-). 
IETF needs this tool yesterday, and this is one of the reasons to keep 
ID Submission draft scope tight.

>  the requirements for the I-D submission tool.

We have it now. It needs more work, of course, but I think the current 
scope is right.

>  IETF community and leadership, and prioritisation versus other tools.

I disagree that any feature should be scoped out just because it is 
not currently supported by Secretariat manual efforts. After all, the 
tool itself is a change. IMO, we should define the scope not based on 
what is a new or different compared to the current practice (most 
things are, in some sense).

For example, if the tool accepts a few draft formats (because 
Secretariat already does), I think it is counter-productive not to 
accept XML sources as well. It buys you virtually nothing to scope XML 
sources out (as far as short-term documentation and implementation 
efforts are concerned). It may buy you a lot to include them (as far 
as IETF infrastructure needs are concerned). However, it is a good 
idea, IMO, to say that first versions of the tool can accept just 
plain text. There is a difference between draft scope and 
implementation priority.

I agree that some changes, like draft archiving and diffs do not 
belong to the ID Submission draft. But not because they are changes. 
They do not belong because they have nothing to do with draft 
submission. They are about existing draft rendering and manipulation. 
That is why I have been arguing that they should not be included in 
the ID submission draft. I does not look like we disagree on that 
point.

>     leave the requirements received from the secretariat out of it,

Question: What do we do with those IETF and Secretariat requirements 
that overlap? If we include them, you get my proposal 1a. If we 
exclude them, you get an incomplete specification. That is what I am 
trying to say in the last two e-mails or so.

Thanks,

Alex.

---

From: Henrik Levkowetz <[email-masked]>
Date: Mon, 27 Sep 2004 16:20:56 +0200

Hi Alex,

> about Secretariat requirements.

Ok, good.

> things are, in some sense).

I'm not saying that any changes are out of scope, above.  I'm talking
of changes outside of the I-D submission tool needing buy-in and
prioritisation.  

Ok.

> trying to say in the last two e-mails or so.

Ok.  If they are indeed community requirements, they go in - that's the
way I have been thinking about option 1 above, so it seems we may be
in agreement.

	Henrik

---

From: Alex Rousskov <[email-masked]>
Date: Mon, 27 Sep 2004 10:41:58 -0600 (MDT)

On Mon, 27 Sep 2004, Henrik Levkowetz wrote:

>> Question: What do we do with those IETF and Secretariat 
>> requirements that overlap? If we include them, you get my proposal 
>> 1a. If we exclude them, you get an incomplete specification. That 
>> is what I am trying to say in the last two e-mails or so.
>
> Ok.  If they are indeed community requirements, they go in - that's 
> the way I have been thinking about option 1 above, so it seems we 
> may be in agreement.

Great. I will resolve a few XXXs in the ID Submission draft 
accordingly.

Does anybody want to start an "ID Access/Rendering" draft? If there 
are no volunteers, I can start a draft or at least a wiki page to move 
corresponding requirements from ID Submission draft notes to that new 
draft/page.

Thanks,

Alex.