IETF 77 WGDTSPEC BOF Minutes BOF to Review of Datatracker Specifications to Support WG Chairs and I-D Authors Friday March 26, 2010: 09h00-11h30 BOF Chairs: Ed Juskevicius Russ Housley =================== AGENDA: 1. Agenda Bashing 2. BOF Scope and Goals 3. Review WG Document States and State Diagram 3.1. Introduction to definitions for WG Document States 3.2. Walk through of straw man State Diagram 3.3. Discussion on preferred or "fast track" path of I-Ds through the state diagram 4. Requirements to extend the Datatracker for WG Chairs and Authors 4.1. Intro to strawman set of wgdtspec requirements 4.2. Review of key considerations and assumptions (e.g. who needs to input what and when to ensure the Datatracker is always in sync with WG progress) 4.3. Discussion 5. Next steps 6. Any Other Business =================== MEETING DISCUSSION: 1. Agenda Bashing No changes to the agenda were requested. The agenda was adopted as proposed. 2. BOF Scope and Goals Ed Juskevicius thanked Henk Uijterwaalb for volunteering to serve as jabber scribe for the BOF. Ed then introduced the purpose and goals of the wgdtspec BOF as follows: - to review and discuss revisions to the straw man definitions for WG document “states” proposed in: - to review the straw man “state diagram” and discuss its applicability to typical IETF working group processes; - to identify requirements for extending the IETF Datatracker tool for I-D authors and WG chairs; and - to discuss next steps and any other business. The scope of the BOF was on document states that may be used by working groups to produce IETF Stream documents. The focus is document states that I-Ds may traverse while in the IETF Stream (as defined in Section 5 of RFC4844). Defining any new WG processes or requiring any WG chair to use any of the products or tools that come from the wgdtspec BOF is out of scope. WG document states discussed in this BOF may (optionally) be used at the discretion of a WG Chair to indicate the status of documents in his or her WG. 3. Review of WG Document States and State Diagram RFC2418 specifies that an IETF working group chair has “wide discretion in the conduct of WG business”. A chair may choose to make use of some, all, or none of the document states defined in wgdtspec. Scott Bradner began the discussion. He observed that the states proposed in are incomplete. They do not address standards track documents produced outside of an IETF working group. An example of such a document is one that is produced by an individual and handed to an AD with a request to have the I-D published as a standards track document, or as an informational document, or as an experimental RFC. Russ Housley agreed. The IETF Stream allows for both WG submissions and for Individual Submissions. Russ asked the wgdtspec BOF to focus on Working Group submissions. He said that Individual Submissions would be handled later as part of new work to specify document states for the other streams described in RFC4844 (viz. IAB, IRTF, ISE). There was some discussion about extending the Datatracker to indicate the document stream that every I-D is associated with. Dave Crocker said an author can indicate he wants a WG to consider an I-D by including “draft-wgname-” in the title of the document. It would be cool to have an Independent Status marking. Russ Housley agreed it might be a cool feature but maybe not for day one. Barry Leiba understood we don’t want to specify all of the states of IRTF stream and IAB Stream and ISE Stream documents now, but said putting the basic state so that it’s clear when someone goes to the tracker which stream an I-D is in, would be good. Tony Hansen articulated a need to identify drafts that transition across streams. That happens often in the IETF. An I-D can go from being a non-WG document to becoming a WG-document and then back to being a non-WG or Individual or (sometimes) an IAB stream document. Russ replied that only a few per cent of the documents approved by the IESG might be affected by stream switching, and then agreed a way to support it is needed (e.g. perhaps via the creation of a new “Handoff” state). Tony: The “ID-Exists” state is stream agnostic today. Until an author approaches some entity, you don’t know which stream the I-D belongs in. Russ: Other than filename, that’s right. You don’t know if it is individual or independent. Tony: If the name of an I-D contains draft-IETF, draft-IAB, or draft-IRTF, then it is definitely associated with a working group or the IAB or the IRTF. If it doesn’t, then all bets are off. Paul: This BOF is to specify tools to help WG chairs. Knowing which stream a draft is in and its current state would be good for WG chairs and for the community. I am a WG chair and would like to know when an I-D is ‘at the ISE’ or if ‘the ISE is looking at it’. Henrik Levkowetz: Does this mean we should have the option for people to indicate the ‘stream’ and the ‘Intended WG’ when submitting a draft? Also, should we give Chairs or individual authors the option to indicate a stream switch for their own documents? Russ: I’d rather not burden the Submission tool first go. We should think about this. I think there is going to be an evolution. Scott Bradner: A lot of I-Ds come in under someone’s name today, and then they get educated as to where it can go. Dave Crocker: Right. A lot of documents begin as Independent. Many of them do not get adopted by WGs. Some do. An I-D that starts independently may get picked up, and there are different ways it could get picked up. Having an easy way for I-Ds to start with an Independent label would be an honest depiction of what happens frequently today. Brian Weis: I agree but we need to encourage authors to submit documents. Some authors may not know a lot about IETF processes and streams. Let’s not burden them with too much at I-D submission time. Paul Hoffman: It would be good (for people who don’t understand streams) if the Datatracker could indicate a draft’s ‘last current stream’ and not just its last status in a WG. The current stream that an I-D is in (which might be ‘unknown’ or ‘not yet determined’) would be good information for document authors and WG chairs. Russ: The stream should be clear by the time a draft reaches the IESG, IAB, IRSG or ISE. Prior to that, drafts can and do jump from one stream to another. -------- The next discussion clarified the meaning of some states already programmed into the IETF Datatracker. One commonly reported state is “I-D Exists”. “I-D Exists” is a manufactured state that is displayed in response to a query about any I-D that exists for which the Datatracker has no other status information. Another common state is “Expired”. The Datatracker reports every I-D more than 6 months old that has not been submitted to the IESG or is not being artificially kept alive (by an AD) as “Expired”. “Active” is a document validity state. “Expired” is also a document validity state. Neither is a not formal state in the IESG state machine. A document can be “Expired” or “Active” and be associated with a state in the IESG state machine at the same time. Russ Housley clarified the meaning and common usage of some of the IESG states. He also identified an error in the state diagram at: https://datatracker.ietf.org/images/state_diagram.gif. When an AD decides that a document needs revision, the next state after “AD Evaluation” should be “AD is Watching”. The state diagram incorrectly suggests that “I-D Exists” could be state after “AD is Watching”. “Waiting for Writeup” means the timer for an IETF Last Call has expired and the document that was in Last Call has not been put into another state yet. This is a common state after “In Last Call”. If a Write is entered before the Last Call timer expires, then the “Waiting for Writeup” state is commonly skipped, and the next state bcomes “Waiting for AD Go-Ahead”. “Waiting for AD Go-Ahead” is a common state after “Waiting for Writeup”, and after “In Last Call” for documents that have writeups in the Datatracker when the Last Call timer expires. -------- The next discussion was on the straw man definitions for document states commonly used by IETF working groups. The IETF working group process looks like a big black box to a lot of people. I-Ds go in (to the WG black box) and some may exit the black box after a time interval, along with a request for publication. Some I-Ds never leave the black box. Other I-Ds may get revised, combined, dropped or transferred to another WG. An I-D sent to the IESG for publication may be judged by the IESG to be ‘not ready for publication’ and be sent back to the WG that created it for revision. That often surprises newbies. They expect that documents which have completed a Last Call should not return to a WG for revision. Candidate WG Document --------------------- A common first state for all -00 drafts is “I-D Exists”. Some I-Ds that exist are intended to be considered by a WG. A useful state to identify such I-Ds may be “Candidate WG Document”. Russ Housley observed that a “Candidate WG Document” could be viewed as the equivalent to the IESG’s “Publication Requested” state. It means “WG, will you adopt this document?” A document exists and a Chair could use this state to indicate the WG is trying to decide on giving the I-D official status. Paul: More and more charters these days list “candidate drafts”. When a WG has many drafts to choose from, this can be important. Barry Leiba: Yes. There is also the case where a WG chair asks many authors to write candidate documents. In vwrap we specified several documents in the charter as starting points. The documents came in with funny names so we asked the authors to revise them and to give them names like “draft-author-vwrap”. This was so the documents would be tracked in the tools page. If we’d had a “Candidate WG Document” state, we wouldn’t have had to do that step. It would have been more convenient. Tero Kivinen: Speaking not as a WG Chair but as a WG member, it is often hard to find drafts that are going to be part of a WG effort. If we had this state, it would be easier to find and read drafts before coming to a WG meeting. Scott: Let’s say somebody writes an I-D, and shops it to various WGs. Which WG does the I-D get tagged as being a candidate for? If you have a “Candidate WG Document” you would have to tag it with the name of the WG it is a candidate for. In some working groups (e.g. MPLS) a lot of ideas get expressed as I-Ds to enable a show of hands about the I-Ds the WG wants to adopt. If a WGs receives 20 new drafts per meeting, it would take a lot of work to use this state. I’m not sure “Candidate WG Document” is all that useful because of its complexities. Ed: The Datatracker could handle cases where a document is a candidate for more than one WG. The tool could provide a list of all the working groups that a draft is a candidate for. Scott: It’s a lot of maintenance that I don’t think is going to happen. Unidentified speaker: As a WG Chair, I can see the utility of marking candidate drafts for the benefit of the people in my working group. That is the only reason I would do it. Of course, if I did do this it could help with some auto generation of agendas. I agree that a list of WGs (that a draft is a candidate for) could be generated. Barry: I gave an example in vwrap where it would have been very useful to have this state. Scott gave an example in MPLS where it would be a pain to use this state. I accept both examples. Let’s not burn “Candidate WG Document” just because it doesn’t work for one WG or another. A WG that doesn’t want to use this state does not have to. Ed: Right. A WG chair could move a document directly from “I-D Exists” to “Active WG Document” without using the candidate state. Not a WG Document ----------------- Tony Hansen: We need to be able to identify a “Candidate WG Document” that is not accepted by the WG. We need to be able to send it out of the WG black box. Scott: “Not a WG Document” is only one bit. There are other things that an I-D which is not accepted could become. The I-D could go to the ISE, it could go for information, or it could become other things. Paul: What if a document was a candidate for two working groups? Ed: The Datatracker’s document History (log) could show it and indicate which (if any) WG decided to adopt the document. Scott: “Has Not Been Accepted by a WG” might be a better name for this state. Al Morton: I keep thinking of the ‘Comments’ field. That’s where I would put information to clarify things. I will lean on that heavily. That feature has to be in release 1. Henrik: When I rewrote the initial tracker tool a few years ago, I tried to tease apart states and substates. It was a mess to understand where a document was. There were many tables. It would be better to look at these as independent state machines. There should be one state machine or state diagram for WG documents and the diagram should have one state which is “Not a WG Document”. A document could also have states in many other state machines. If an I-D goes to the IESG, whether it is or is not a WG document, the I-D will have a state in the IESG state machine. It can be sent back, and again go around in a WG or some other state machine. If we keep them as separate state machines then we don’t have to lose state in any of them. Paul: Would it be possible to have a WG state machine for each working group? I ask because this would fix Scott’s problem. If his WG doesn’t want to use “Candidate WG Doc” but I do ... Henrik: That is possible and reasonable. I have already thought of a notation that a Chair could provide to indicate what his state machine is, as long as it is a subset (of all the WG document states we define). Dave: The state diagram has changed its nature. I think it is a project management diagram for stuff the IETF is doing. A state diagram is a good thing, but it leads down some unexpected paths. From the earlier comment of “I write a document and then I want to have it adopted by a WG” it occurs to me there can be the opposite status. We can have a document status without yet having an I-D. A working group can commission someone to write a draft. That situation isn’t in our WG state diagram, but I think it is a fairly important indicator of where things are in terms of larger IETF work. Henrik: If we need another state that says “This is no longer a WG Doc” or some variation, that’s fine, but we still need a null state like “Not a WG Document” so we can represent a file in the database without having to have multiple tables where a document exists in one and it doesn’t exist in another. Paul: I would rather see I-Ds being in some null state versus being “Not a WG Document”. I don’t want “Not a WG Document” to hint at a previous state. Active WG Document ------------------ An “Active WG Document” is an I-D which has been adopted by a working group and is actively being developed. A chair can change the status of any document from “I-D Exists” to any other WG state such as “Active WG Document” at any time. Recall that the use of WG states is optional; a working group chair could decide she/he does not want to use “Candidate WG Document”. Barry: Lemonade had a document that went from being active in Lemonade to being active in the sieve WG. We need a method to indicate when that happens. Parked WG Document ------------------ A “Parked WG Document” is a working group document which cannot be progressed for some reason (e.g. it has lost its author). Paul Hoffman: A chair might want to park a document. This is a state I would never use, but other chairs might. This is a good place to emphasize the optional nature of using WG document states. Russ Housley: I have seen some really big working groups say “We have a lot of good ideas but are going to focus on these 4 documents first.” Scott Bradner: Here is another idea in the same genre. When I was an AD, I saw an I-D created for the information of a WG. It was never intended to progress anywhere. “Parked” was the right state for that I-D, but the wrong name. “On Hold” would not have been the right name either because the document was achieving a purpose: it was ‘for information for the WG’. The I-D was not concluded because it remained somewhat active until the group’s work was completed. Ed: A new state called “For WG Information Only” comes to mind. Paul: I agree with Scott’s concept. We want a way to indicate when a document is not meant to progress but is useful to have inside a WG. Dead WG Document ---------------- A “Dead WG Document” is defined as an I-D that was an active in a WG but has been abandoned. This state is different from the IESG’s “Dead” state. A “Dead WG Document” may be resurrected. As such it may not be permanently dead. A document that is declared “Dead” by the IESG should not available for any further use within any WG. In Working Group Last Call -------------------------- This state identifies an I-D for which a Working Group Last Call (WGLC) has been issued and is still in progress. The use of this state is really optional, especially since WGLC’s are optional within the IETF WG process (per Section 7 of RFC2418). WG Last Call Completed ---------------------- “WGLC Completed” was proposed as a possible next state for an I-D that has complete a WGLC and would require a lot of work (e.g. to resolve comments) to progress it to another state. Several comments and questions about this state were raised. Some people said they might use this state. Others said they would not. Unidentified speaker: I question the need for having a “WGLC Completed” state. I have seen lots of WGs where a timer may have expired but people continued to comment on documents. If we had a way to flag things that have been in a state for a while, I don’t think we’d need this state. Russ: The IESG state machine goes from “Last Call Requested” to “In Last Call” because a Secretariat action is required. The next state after Last Call is either “Waiting for Write-Up” or “Waiting for AD Go-Ahead”. Of course there may be another Last Call if something big came up in the first Last Call. The IESG has no “Last Call Completed” state and we should follow that for the WG state machine. Scott: One nit about having a timer is that a Last Call in a WG has an arbitrary period of time that is defined by the last caller. Having something that could be used to say when a WG Last Call is supposed to be over and to have a flag to indicate that (e.g. to help a WG Chair remember that something happened and so they should do something) is not a bad idea. Russ: What is not obvious from the IESG state machine is that an AD has to enter text for the Last Call into the tracker. Part of the Last Call text is the date the Last Call is supposed to end. When the Last Call notice goes out, the state is “In Last Call”. When the end date arrives, an e-mail ‘nudge’ gets sent to the AD saying “LC Expired”. This does not put the document into a new state. Rather it is a nudge for the AD to go read the mail, figure out what consensus is, and then put the document into the appropriate state (in the tracker). We might want to think about what ‘nudges’ should accompany the working group state machine. Paul: Some people may want to use the “WGLC Completed” state. There was some discussion on the list about that. Ed: Yes. Another point is that a WG document that completes a WGLC without too many comments may not need to be put into the “WGLC Completed” state. A chair could moved it directly to “Waiting for Doc Shepherd Write-Up”. Barry: In the IESG, after Last Call, the parallel we have for what you call “WGLC Completed” is “Waiting for WG Chair Go-Ahead”. Maybe your state just needs to be renamed. A document “In WGLC” could transition into one of two states: “Waiting for Write-Up” or “Waiting for WG Chair Go-Ahead”. Tony: I think “WGCL Completed” should be titled “WGLC Timer Has Expired” and be an attribute on the WGLC. I have been on a number of Last Calls where two weeks have passed and lots of comments are still going on, and the WGLC is not really completed. The Chair should get a nudge (if he programmed a WGLC timer and the timer has expired). The nudge would just mean “the timer has expired”; it would not mean the WGLC is completed. Russ: That’s actually what “Waiting for AD Go-Ahead” means in the IESG. A timer has expired but the AD has not made a consensus call yet. That’s exactly the situation you are describing. The WG Chair is waiting to make the consensus call, or to move the document into another state to resolve issues that have come up. Tony: That’s sounds like a bit for the “In WGLC” state rather than a separate WG document state. Russ: I’m just saying how this works in the IESG state machine. I am not saying which is right. Waiting for Doc Shepherd Write-Up --------------------------------- Al Morton: I think this state should be called “WG Consensus: Document Shepherd Write-Up in Progress”. A good write-up takes time to prepare. Unidentified speaker: Yes. We need this state and the reminders that could come with it. One of the things I discovered this week is that I am a shepherd for a document that has been waiting for a write-up for a year. Dave: The new name that Al proposed for this state retains the information that we are waiting for something, and it adds a really nice indication that something has been accomplished. Paul: An annotation tag that could be used here is “Has been in this state for more than N weeks”. I wouldn’t use this tag for an “Active WG Document” but I might use it on a state I expect to complete in less than N weeks. For example, for a WG Consensus Call, it would be perfectly reasonable to get a nudge that says “Has been in WG Consensus Call for more than a month”. Henrik: It would be perfectly feasible and I think attractive to allow some of these things (e.g. adding tags and actions dependent on tags) to cause an automatic action of some kind. The action might be to send a nudge via e-mail saying “Hey Chair, this document has been in this state or has had this tag for x weeks.” Dave: I like the idea of having a “Time in State” attribute to flag when certain thresholds have been crossed. Bert Wijnen: Are these the only state transitions? Russ: No. These are some normal and most commonly observed transitions. A WG chair should be able to place any document into any state at any time, just like ADs can do in the IESG state machine. Unidentified speaker: Question for clarification. Is the state machine to enforce document shepherd write-ups? What if there isn’t a write-up? Does that mean a document can not get to “Publication Requested”? Russ: This is something I suggested to Ed for an earlier version of the document. The working group state machine can not enforce this because a WG Chair can move a document into any state he wants. However the IESG is now requiring Write-ups, so I would like to see Write-Up text put into a box in the Tracker. WG Document “Substates” ----------------------- The annotation tags (listed on slide 16 presented by Ed during the BOF) were called WG document “substates” in the draft. Henrik suggested the “substates” should be renamed to “annotation tags” in the next draft. Henrik’s suggestion was accepted. Annotation tags are descriptive labels which may be added (one or many at a time) to any document in any state by a Chair if he/she believes that using the tag(s) would help to clarify why a document is in the state it is in, or to indicate who has the token to take action on the document. -------- Barry: There was a discussion on the mailing list that suggested some people think “Held due to IESG concerns” is a bogus substate. Paul: An IESG member with concerns on a WG document should not be any different from any WG member who has concerns with a document. -------- Unidentified speaker: I had a situation where a document went to IETF Last Call and then came back with comments. As a result of one of those comments, the WG took the document back and made significant revisions to the document to address a new problem, and then the WG pushed it forward through their process again starting with a new WGLC. I think we need a tag like “this I-D needs revision because of a new issue that was raised in IETF Last Call”. Russ: I don’t think you will get such a tag because what you’ll do is move the I-D back to being an “Active WG Document” Unidentified speaker: OK, I have another question. I have a case where a second document depends on a first document. The document that came back (which we made major changes to) depends on a first document. We held the first document even though it was done and had no dependencies. We held it in case changes to it might be needed after we revised the dependent document and because we wanted to give both documents to the IESG at the same time. I need a tag to says why we parked the first I-D (e.g. because we wanted to move it forward at the same time as another I-D that depends on it). It was a document we held in case we need have had to change it later, not because it had a dependency on another document. Ed: You want something like the inverse of “Held due to dependency on other document”. Russ: The comment field will be important here. You might hold a document for a dependency on two other documents (or three). Call the tag “dependency hold” or something like that. -------- Scott: The list of annotation tags is incomplete. For example, a WG chair could send a draft to an AD via publication request. After the AD reviews it, he may kick it back and you have a tag for that. If, however, the AD passes the I-D to the rest of the IESG and a DISCUSS is raised by other ADs, the document may come back to the WG at that point not because of “Revision requested by AD” but rather because of “Revision requested by IESG”. Russ: Exactly, but I think “Issue raised” would be more accurate. We should have two tags: “Issue raised by AD” and “Issue raised by IESG”. Paul: This relates to Access Control Lists (ACLs). There is an ACL on “Publication Requested” that is triggered by the AD or the IESG which puts it back into “Active WG Document”. We should have a tag to explain why all of a sudden a draft comes back into the WG. Unidentified speaker: Sometimes a revision requested by an AD or after “IESG Evaluation” can be resolved in a relatively quick way without putting the draft back into “Active WG Document” again. Geoffrey: I had a couple of those this week. In one case we made the requested revision without going back into the WG and in the other case we pushed back hoping not to make any change (in which case we may not need to involve the WG). Barry: Right, it’s a case of whether the change is significant enough to need another WGLC. If it is, then we may need a state change but otherwise we might just leave the document in the IESG state machine. Unidentified speaker: I know of lots of DISCUSSes which are e-mails between authors, or shepherds, and Ads. That is a problem. They are not visible to the WG members. DISCUSSes are quite often discussed between two individuals. So if a document does not go (back) into any of the states in the WG state machine, members of the WG may see new versions of the document coming out and they may query the Datatracker to discover there are IESG DISCUSSes ... but that’s all they would know. I don’t think many people follow this for other documents in the IESG that they are not involved in. Barry: That’s a Chair issue. Russ: Let’s talk about this another time. The question is “Who should be notified when a DISCUSS is filed?” Dave: What frequently comes after “IESG Evaluation” is a DISCUSS and we do not mark that. We should. When one person can hold something for 6 months, we should have that in the record. Russ: Let’s say there is a significant DISCUSS and the WG wants to talk about it and maybe even push back on it. That’s all good. What changes for the document? It’s still in “IESG Evaluation”. The only concern is that if a document comes back to the WG from the IESG, you want to track what the WG does. You want to track WG activity on the document. Dave: Here is the catch. I think we lose track of the nature of the special processes that take place with DISCUSSes and the costs of them and the delays of them and the effort of them. Burying this kind of overhead means we really can’t track them. Russ: I disagree. It’s public and available to anyone. I agree we should pay attention to this, but this is not a WG state machine issue. If you need to find if a document has a DISCUSS against it, that information is available today. If you need to find out what a WG is doing about a DISCUSS, that depends on the state the WG Chair puts the document into after the DISCUSS is filed. Barry: I’ll push on this a little bit. Dave and I have differing but interleaved views of how DISCUSSes should work. I agree that a document blocked by a DISCUSS for a significant time probably should go into another state. There are short-term DISCUSSes such as “I don’t understand something, I need to discuss it with the authors” that can be cleared quickly. Those probably don’t need to trigger a state change. When a quick resolution is not possible, we probably should have another state. Russ: Or a different tag. -------- Paul: Don’t forget Scott and I would like a state or a tag that says “This is an ACTIVE WG document that is not intended for Publication - it is ‘for internal use only’ or something like that”. 4. Requirements to Extend the Datatracker for WG Chairs and Authors Straw man requirements to extend the Datatracker (see slides 21-26) were discussed and the following comments were recorded. Scott: Requirements should be phrased as “We want to see the tool do x”. They should not specify how “x” is to be implemented. This means requirements R1, R2 and R11 need to be rewritten. R3 should be deleted. WG Chairs have to be able to decide for themselves how useful this tool will be for their working groups. If a chairs wantw to use some or all of the proposed WG document states for some, all or none of the I-Ds in her or his working groups, that must be a decision that the chair makes. It can not be a requirement that you specify. R4 needs to be clarified so that many people could be delegated (to input state information on behalf of a WG chair). The number of delegates has to allow for more than just one person. Russ Housley: Inside the IESG, there are many things one AD could do to another AD’s documents however the IESG has a cooperative relationship and the Datatracker’s history log (that shows who did what) is an effective enforcement tool. I think “per WG” may be the right granularity for delegations by a WG chair. If there is an agreement between a WG chair and his designees that particular designees are only supposed to take action on particular documents, and if some designees exceed their delegated authority, the log will show that. The Chair can take appropriate action and move any document into the state the Chair wants to, at any time. One person said R5 should be revised to say “The Responsible AD shall also have the ability to update the status information for WG documents”, instead of saying the IETF Secretatiat shall have the ability to do that. Russ explained the IESG allows the Secretariat to have this ability because sometimes ADs are in a place where they don’t have good web access, and a phone call to the Secretariat (to progress things for a document) is a useful feature. R7 is not necessary. Russ said the IESG lives with the fact that mistakes sometimes happen. When someone inputs the wrong state information, the mistake can be fixes a minute later and the comment log (in the Datatracker) can be used to explain the mistake and the fix. Tony Hansen suggested a requirement is needed to state that a chair should be able to move a WG document from any state to any other state, even if the state transition is not shown on the WG state diagram. The state transitions illustrated in the state machine diagram are common state transition. They are not all of the possible transitions. R9 should be deleted. R10 should be rewritten to clarify that WG document state and history are to be made available for the information of everyone (ie. not just for the WG chairs). Likewise, it would be useful to allow everyone (not just WG Chairs) to query the database about “what a WG done in the last N number of weeks” or “Since the last time I logged in”. The intent of R13 was that it should be possible for the tracker to show the planned next state for a WG document. Russ: In the IESG, when an AD goes to update status information, the Dataracker shows what the current state is and it displays buttons for the “most likely next states” (i.e. more than one). Any arc in the IESG state machine is presented as a button that could be pressed. In addition, if an AD wants to make an arbitrary state change (i.e. to any other state) then a pull-down can be used. Bert Wijnen: I like the idea of having a planned date to trigger an email or something to me as a WG chair to say “Hey WG Chair, you need to pay attention to this document, or you were planning to do something with the document by this point in time”. Barry Leiba: I will second that. I can’t see how I would use R13 but I won’t object to it. I like what Bert just suggested. A chair should be able to input a trigger, and expect to receive an e-mail if a state change hasn’t happened by the trigger date. R14 should be reviewed to drop “WG” from the statement of this requirement. The revised requirement should read: “A field should be available to indicate the intended of each document, with the possible values being:” (the list on slide 26). “Full Standard” (on slide 26) should be changed to “Standard”. In addition, a new “Intended Status” label is needed, along of the lines of “Not intended for publication”. 5. Next Steps The BOF adjourned after a short general of one last point. Bert Wijnen: When we create WG Charters, we specify milestones. Can we link states to the milestones already in a charter? Russ: I think that would be very desirable but the problem is sometimes the milestones require more than one document. We’ve gotten better about that and I agree it would be good to have the linkage. Bert: Also sometimes a WG Chair asks the AD to change the milestones to a later date. Having a record of that would be good. Henrik: I’ve already received the suggestion to link documents to milestones, and milestones to documents and I am thinking about this. Russ: Perhaps nudges could be generated when milestones are missed. -------- The BOF adjourned at 11:35 a.m. Pacific Time. The Minutes of the BOF meeting were prepared by Ed Juskevicius.