iddspec BoF minutes IETF 79, Beijing 2010-11-08, 1300-1500 Chair and minute-taker: Paul Hoffman Note: text on slides is not reproduced here Slides are at Draft is draft-ietf-genarea-datatracker-community Slide 1: Cover slide Slide 2: Overview Slide 3: High-level overview Russ Housley: This is very draft-focused because the IETF is draft-focused Are changes to WG charters also notable events? Paul: they could be Sean Turner: RFCs have events like errata being published, that would be good to cover as well Also later RFCs that obsolete or updates one Paul: Will add these in the next version Henrik Levkowetz: The new database scheme is based on a "document", not a draft We should not focus on just drafts Kurtis Lindqvist: This is more of a workflow tool. Maybe we can follow IANA registries Henrik: We will have a generic workflow container for different situations Leslie Daigle: Drafts are the basis for all RFCs Not all RFCs are IETF work Is this a tracker just for IETF workflows? Paul: no, definitely not A WG might need to follow ITU work; maybe we can follow them Unicode versions This project might be more about tracking your reality as an IETF participant How do you keep track of everything, well, a large number of things We are not keeping track of the content, just the changes Also need to be able to see the history to date Two major components: let me see history, tell me when something changes Slide 4: Requirements for this work With new additions from today, this is wider than drafts We're not changing the data model for Henrik, so that makes it easier to implement Henrik: More "documents" are agendas, minutes, reviews Aaron Falk: What is the process for making these requirements? Paul: I'll put it in the draft and it will get discussed on the list The IAOC will decide what goes into the RFP Russ: The IAOC will look at the draft that comes out of this effort If it looks like it can be done as one chunk, it will all go in Otherwise, it will be split up into a phased deployment How is the judgement made whether the community likes this stuff? Russ: IETF last call There is no need for consensus, is that correct? Paul: Yes, I'll just do my best Slide 5: Preliminaries Henrik: The UI challenges are greater Please specify what is needed, not how it should look It is OK to discuss UI ideas, but they probably won't make it into the draft Tero Kivinen: Use case scenarios would be really useful Aaron Falk: How many other drafts are there that set requirements for the Datatracker? Is there a page that pulls them all together? Paul: Maybe we can set up a wiki page Russ: If I choose to solve this, the original Datatracker document was never published as a draft Is it worth publishing those original specs? Aaron: Not to me Paul: can set up a wiki page on genarea Slide 6: Statement of work (1) Jim Schaad: Can this cover every single draft? Paul: Only if there is a technical reason not to Slide 7: Statement of work (2) Dave Crocker: Is this about notifications, or also display? Paul: Both Like being able to do a search, save it, and it changes dynamically Paul: Plus notifications Tero: It might be useful to know why someone added something to a shared list Paul: A comments field Slide 8: Should we be doing this at all? Spencer Dawkins: There are times I want to follow something that doesn't yet exist Is this harder with an Atom feed? Paul: No Slide 9: High-level operation Scott Bradner: Is this anyone who has a login? Anyone can create a list Paul: Hold that for a later slide Tero: Who is owner of the list, who can change it: Paul: Hold that for a later slide Slide 10: List creation Henrik: Dynamic containing of other lists can avalanche Could lead to huge numbers of notifications unexpectedly Paul: Maybe add rate limiting or warnings Slide 11: List maintenance Tero: If you delete a list that someone else is using, what does that do to them? Henrik: Easier is to ship notifications when they happen Bunching them up is much harder Delaying anything, even adding to a list, is harder Maybe don't have any delay Kurtis: A WG list would contain a predictable set of drafts If I follow a personal list, I don't see the difference between him removing the items and removing the whole list You can't detect if a list is unused Paul: You can by seeing if they haven't looked at it in two years How will you distinguish this from Google looking at it? Maybe it doesn't matter Scott: How will you deal with users deleting a list from becoming DoS attacks? Paul: We'll get to that later in the session Andy Malis: If I use my list to get email updates but I never go back to the Datatracker, how do you know it is unused Paul: Maybe we send them mail every few years, or we may decide to let them live forever If we decide to cull, we need to have a sensible way to do it. We might decide not to cull Tero: We need to check for email bouncing Important to get just a digest mail, not every time something is updated Paul: Then you should use the Atom feed We might have batched email, or we might not Henrik: If you give this document to a contractor, they will read this suggestion as a rule Paul: We can take out this suggestion Digest will be valuable, but don't queue things gratuitously Slide 12: Adding needs to be easy Some of these are not perfect: best effort from the Tools team Henrik: We don't currently have "All drafts that are referenced by a particular RFC, a particular draft" Paul: But you can add that Maybe can get this from RFC Editor from their current workflow; we can ask for it It would nice if we didn't have to do the scraping ourselves (Discussion of "authoritative" data coming from the RFC Editor) Tero: It will be expensive to keep up with "search for word" Paul: Not necessarily, because we will know all the strings anyone is looking for This might be dynamic with best effort: no guarantee Slide 13: Lists should be able to be private Best effort at privacy Henrik: Predefined lists should be public Paul: The list of all the drafts in a WG is not a list, it is an attribute Barry Leiba: Where is the secrecy Paul: We are not guaranteeing secrecy, just best effort at privacy Scott: There should be a way for a WG chair can make a list called "WG list" Paul: Two different chairs might disagree This is terminology, and I don't particularly care about it Doesn't want the IETF to spend a lot of time to help people's private functionality Against it unless it is a byproduct of of the work for the public lists, particularly for WG chairs Is OK with it as long as it is not much overhead The thrust seems to be about private lists, and that is the wrong thrust Kurtis: Strongly disagrees with Scott Wants priority to help private use of tool Tero: Making lists public is the more expensive operation Making them private is easy Giving permission to chairs is harder Scott: Doesn't agree that it is less work Slide 14: Ideas for making lists private Leslie: This is not a "private" list: better term would be "anonymous" You are not providing the privacy for it Paul: We can change the word used Scott: There are various types of access lists Changing the list, getting on the feed, and so on Need to add robots.txt to say don't walk this tree Slide 15: Some lists should be public Maybe have different ACLs: seeing vs. changing Can make the seeing ACL public Scott: I would hate for a public list to rely on 128-bit random number Don't want to force people to rely on copy-and-paste Needs to have a human-friendly name to get to it Paul: Might have human-friendly redirects for public lists Thinks that the default should be public, not private Henrik: Does that mean listed and discoverable? Yes to both Barry: Other think that the default should be private Maybe the UI has radio buttons to choose, and private is the default Tero: Should be more effort to create a public list, especially if they will be enumerated If they are going to be human-readable, people will possibly pick confusing name Paul: Maybe someone gets to decide whether the names are OK Leslie laughs Henrik: Going from "human-friendly" to "being able to name" creates a huge headache To satisfy both requirements, gets unfriendly identifier by default, but I can click on them in my page Maybe stash in a cookie Scott: There is a real need to create these kinds of lists for IETF activities Some way for a WG chair to say "this is the technology relevant" WG chairs should have special powers Doesn't care about naming of truly personal lists Also lists that you might tell others about so they can follow For that one, it would be unfortunate to have it have a 128-bit number Paul: It would also be unfortunate to have it have a name that is handed out Not an easy problem to solve Leslie: Accessing the authoritative lists for activities Might be done with naming, maybe with aliases Henrik: We can give every WG chair a namespace Tero: Personal lists can also be tied to the login to the Datatracker Slide 16: Tracking changes to drafts in a list Scott: Sees this as going to a URL, not to the front page of the Datatracker Could have links on WG pages to these lists Slide 17: Automatic notification Henrik: Doesn't think this is the easiest thing Should instead help people filter on events Need to define a second (and third...) level of granularity Scott: Only a human can determine what "significant" means Paul: Whoops, will fix in the document Henrik: People can specify which events they want to see Spencer: Do we know about WG state changes in the Datatracker? Paul: No, but we will before this is done. Also, we will know about the state changes for IRTF, IAB, and ISE streams Slide 18: Atom feed Slide 19: Mail stream Slide 20: Display in the Datatracker Henrik: Maybe separate requirements into different implementation groups Wants to see deployment before we get to this level of fanciness Tero: We could do this later Want to see "nice but not necessary" comments on the mailing list Slide 21: File display Don't need to pull down the HTML and parse it Slide 22: Open issue intro Slide 23: Known open issues (1) Barry: +1 to dashboard proposal Scott: Me too to dashboard proposal Slide 24: Known open issues (2) Scott: What do you mean by legal issues Specific current wording is bad But we need to think about this Leslie: It would be good to know where this draft will be discussed at the upcoming meeting Applicable to both WG and non-WG drafts Means we need more structure to the agendas Scott: Tool could be used to generate an agenda Spencer: Agrees with Leslie Knowing which draft is targeted to a particular WG Paul: That is highly subjective We do this by file naming now by including it in the draft name Barry: This was controversial in Ed's BoF Aaron: Field called "of interest to" Tagging field Anybody can filled in by anybody Scott: WG chairs can do this for the group Different than anyone doing this Henrik: Has a tool that HTMLizes current agenda, but it finds a lot of errors New idea: create an agenda-creating tool that will know about drafts Slide 25: Known open issues (3) Slide 26: Open mic Leslie: Scrambling to perceive what the whole will be Doesn't think it will necessarily be a one-off BoF Paul: Will be two virtual interims, if needed Next step will be -02, hopefully within two weeks If the group thinks we need to meet in Prague, we can ask about that Finished a bit early