[15:21:18] --- LOGGING STARTED
[20:24:23] --- chopps has joined
[20:29:00] --- sob has joined
[22:06:26] --- michael has joined
[22:40:50] --- galvinjamesm has joined
[22:55:09] --- warlord has joined
[22:57:40] --- tonyhansen has joined
[23:01:35] --- mrose has joined
[23:02:49] --- jlcjohn has joined
[23:07:07] --- Bob.Hinden has joined
[23:07:32] --- galvinjamesm has left
[23:11:38] --- galvinjamesm has joined
[23:12:29] --- kenh has joined
[23:12:31] --- falk has joined
[23:13:03] --- Ted Faber has joined
[23:13:03] <Bob.Hinden> Chair asked for jabber scribe. Jeff volunteered. Needs to get computer going....
[23:13:11] --- hartmans has joined
[23:13:13] <Bob.Hinden> Reviewed agenda. No changes
[23:13:20] --- Ralph has joined
[23:13:27] --- admcd has joined
[23:13:43] --- JoelMHalpern has joined
[23:13:52] --- mankin has joined
[23:14:25] <Bob.Hinden> Also, Scott Bradner could not be here. Steve Bellovin will chair meeting
[23:14:29] --- avri has joined
[23:14:36] --- leslie has joined
[23:14:40] --- smb has joined
[23:14:41] <sob> scott is on jabber though
[23:14:48] <warlord> hi scott
[23:14:50] <mankin> Spencer Dawkins has gone up to give his presentation. Hi Scott!
[23:15:01] <smb> No agenda changes. Spencer is starting.
[23:16:02] <smb> wg snapshot proposed after ietf57
[23:16:16] <smb> intermediate between i-d and Proposed standard
[23:16:31] --- shep has joined
[23:16:39] --- jhutz has joined
[23:16:56] <jhutz> OK; here I am
[23:16:56] <sob> actually WG snapshot was proposed quite a whiile back
[23:17:01] <smb> lots of reasons for snapshots
[23:17:19] <jhutz> ... back to "pesky details"...
[23:17:34] --- Melinda has joined
[23:17:39] <jhutz> WG makes determination to do WGS.
[23:17:58] <jhutz> feedback - need more eyes than just WG.
[23:18:11] <jhutz> Proposed IESG interaction: WG notifies IESG that next draft will be WGS
[23:18:23] <jhutz> IESG can provide warning for bad ideas
[23:18:41] <jhutz> Porposed timeline - similar to I-D's - 9mos, ephemeral
[23:18:45] --- anewton has joined
[23:18:53] <jhutz> feedback: need help finding WGS, [missed this; can't see slide]
[23:19:07] <jhutz> - Do we need something like WGS or not?
[23:19:23] <sob> note that ephemeral does not meet some of the reasons for a WGS
[23:19:31] <jhutz> - Can WG's declare WGS on their own or not? Slippery slope - don't slide into "proposed standard"
[23:19:49] <jhutz> Are there ane prereq's or not. Must it be a WG draft.
[23:19:57] <jhutz> Is WGS ephemeral or not?
[23:20:00] --- randy_g has joined
[23:20:15] <jhutz> [I can't see the slides well enough]
[23:20:34] <avri> i can't see the point if they are ephemeral
[23:20:51] <jhutz> ...
[23:21:04] <jhutz> Most controversial proposal - that WGS is _not_ ephemeral
[23:21:38] <jhutz> - We really want feedback - now, during open mike, on mailing list - don't be shy
[23:21:50] <jhutz> - we've been talking about this for a while
[23:21:59] <jhutz> - we want text for one round of revisions
[23:22:07] <jhutz> Comments from here?
[23:22:23] <jhutz> [Folks should note this is a multicast session...]
[23:22:33] <sob> is he asking for authors?
[23:22:57] <hartmans> No, not authors, just feedback; he thinks he can have text by end of April if he gets consensus/feedback
[23:23:11] --- Jukka has joined
[23:23:27] <sob> tnx
[23:23:30] <jhutz> Question - should there be backward compatibility?
[23:23:56] <jhutz> speaker - no; this is a way to indicate it's ready for review; the reviewers may tear you to shreds; backward compatibility would be the wrong thing
[23:23:57] <sob> what does 'backward compatibility" mean in stds trk?
[23:24:22] <hartmans> I'm really curious what would have happened in krb-wg if we had had wgs. We had major backward incompatible changes and rolled back about 2-3 years of work when we realized it was all borken
[23:24:23] --- BP has joined
[23:24:34] <hartmans> Trying to keep compatible with that would have been impossible.
[23:24:40] <BP> Does this room exist?
[23:24:45] --- BP has left
[23:24:49] <sob> did any vendors implent the "broken" IDs?
[23:24:50] <jhutz> question - but it _is_ part of the standards process; isn't part of the point to get implementation experience? won't vendors implement and then complain and say you can't change it?
[23:25:09] <jhutz> [is there someone here who can relay questions to the mic; I can't do both well]
[23:25:20] --- Jukka has left
[23:25:33] --- anewton has left
[23:25:33] --- BP has joined
[23:25:45] <hartmans> sob - sort of. Cable Labs.
[23:25:59] <jhutz> Speaker - No; you declare the purpose for each WGS, and if the point was early review, and a vendor implements it, you say "sorry; that was the wrong thing to do".
[23:26:06] <hartmans> And most of the WG didn't realize they were broken until very late in the process.
[23:26:45] <jhutz> [allison?] ... If our various reforms could get documents published sooner, would this still be necessary?
[23:27:41] <jhutz> Speaker [who?] - There's different reasons you do WGS. If one reason is "we're going to start interop testing", then is issuing an informational or experimental RFC each time the right thing? My understanding is that once the answer was "yes"
[23:27:56] <Ted Faber> That is Allison.
[23:28:00] <falk> speaker: Allison mankin
[23:28:09] <falk> Transport AD
[23:28:14] <jhutz> allison - maybe this shouldn't be overloaded -
[23:28:14] <sob> to allison - note that my original ID said that WGS was needed because vendors thought that waiting for PS was too long
[23:28:35] <sob> if process changes could fix that it would help
[23:28:40] <jhutz> [thanks smb for relaying scott's comments]
[23:29:47] <jhutz> dave crocker - I see WGS as a simple, general tool, used in a number of ways. Not overloaded; just a general too.
[23:30:28] <jhutz> ... The tool is for internal WG coordination, not a public status
[23:30:35] --- hta has joined
[23:30:42] --- mattz has joined
[23:31:04] <BP> Jonne: Thinks that the WGS tool is a good idea.
[23:31:22] <jhutz> [didn't catch name] - I think this is a good idea. ... No, I don't think there should necessarily be backward compatibility, but it can be used as a tool to say "if we're going to change this, we need good reasons"
[23:32:22] <BP> Jonne: Says that a lightweight approach for the snapshot may be better.
[23:32:29] <jhutz> Jonne: Other comment - you had many proposals how to declare a snapshot. I was wondering if something less heavyweight would be better...
[23:32:53] <jhutz> Jonne: ... just let the WG declare a snapshot
[23:33:00] <BP> Spencer: Smart WGs will use the tool well
[23:33:05] <jhutz> Spencer: Smart working groups will use it well; those that don't are not smart WG's.
[23:33:38] <jhutz> XXX: If we don't create a new document series, we can easily try it out
[23:33:54] <jhutz> Charles Perkins: a couple of scenarios where everything is needed...
[23:34:31] <jhutz> ... - if you have interop tests, and everyone implements the same draft, then something like a WGS that's easily available from the WG page would make it easy to find the thing people implemented, instead of an ephemeral I-D.
[23:34:45] <avri> not if it is ephemeral
[23:35:20] <admcd> ['XXX' was Lars-Erik Jonsson]
[23:35:26] <jhutz> ... - Supppose you have a document that is basically done, but there's a need for a normative reference to something that's not going to be done for a while. If you make a WGS, it can stay around for a while instead of expiring while waiting for the other document.
[23:35:39] <jhutz> ... A WGS is something that the WG has experience with
[23:36:10] <jhutz> [avri are you in the room?]
[23:36:11] --- dcrocker has joined
[23:36:23] <avri> yes
[23:37:18] <jhutz> Spencer channeling john loughney...
[23:37:37] <jhutz> - We are good at generating RFC's, but not so good at generating/maintaining standards
[23:38:03] <jhutz> - at 3600+ RFC's, outsiders don't always have a clear view of some protocols
[23:38:38] <jhutz> - the transport area has spun up a WG to sort out the various [XXX dim slide changed too fast]
[23:38:48] <jhutz> Proposal:
[23:38:57] <jhutz> - RFC numbers are not significant in themselves
[23:39:01] <sob> tsv WG is on TCP
[23:39:11] <jhutz> - STD label can "lump" a set of RFC's together
[23:39:19] <jhutz> [Several more bullets; but slide changed before I could read it]
[23:39:27] --- warlord has left: Disconnected
[23:40:04] --- BP has left
[23:40:11] <jhutz> [sorry; I haven't been able to follow the presentation]
[23:40:33] <sob> jhutz - tnx for trying - I have a copy of the slides
[23:41:06] <jhutz> Oh; wonderful. For those who don't know; it looks like we're talking about draft-loughney-what-standards-01.txt
[23:42:46] --- warlord has joined
[23:43:37] --- jm has joined
[23:43:53] --- galvinjamesm has left: Replaced by new connection
[23:43:53] --- galvinjamesm has joined
[23:43:53] --- galvinjamesm has left
[23:44:09] --- galvinjamesm has joined
[23:44:15] <jhutz> [who's at the mike]
[23:44:36] <Ted Faber> Aaron Falk, from RFC Editor
[23:44:57] <Ted Faber> ...and other places. :-)
[23:45:10] <hartmans> Discussion about whether this lives in a web page or in the rfc
[23:45:25] <jhutz> Aaron: I think this is an important point to get clarified (where will this be?)....
[23:45:28] <jhutz> smb: take to list
[23:45:33] <sob> rfc is not a living document - its fixed when published
[23:45:39] <hartmans> Aaron is concerned about the split between what goes in the document and ephemeral things like multiple implementations
[23:45:42] --- randy_g has left: Disconnected
[23:46:00] <jhutz> James Polk: While I can see usefulness in this for SCTP, on this page, I'd question how this would be used for e.g. IPsec
[23:46:26] <jhutz> ... I think every laptop in this room is using IPsec; yet, it's not widely deployed.
[23:46:42] <jhutz> ... second, there need to be reasons for updating/obsoleting; this could get very large and hard to manage
[23:46:49] --- klensin-ietf has joined
[23:47:01] <sob> seems that it would be better for IPSec to have a web page than to have the security roadmap RFC that it now has (and which is very out of date)
[23:47:24] <jhutz> [David ???]: I want to follow up on what Aaron said about being subjective. "deployed widely" and "known harmful", particularly wrt I-D's, will be concepts that are hard to manage.
[23:47:34] <smb> David Black
[23:47:39] --- leslie has left: Replaced by new connection
[23:47:45] <jhutz> Spencer: My understanding from John is that this is a mockup, and he said that was a challenge; deferring to next round doing this for real.
[23:48:08] <sob> implementation details? :-)
[23:48:20] --- leslie has joined
[23:48:38] <jhutz> Harald: We have states where is makes sense, and some where it doesn't. "deployed widely" is always false when we invent the technology.
[23:48:56] <jhutz> ... "write once read many" probably best when ...
[23:49:01] <jhutz> [harald fill in your text]
[23:49:40] <jhutz> Next: Allison Mankin
[23:50:35] <hta> "write once read many" is probably better for the internet than "every user of IETF technology has to figure out all this stuff on his own"
[23:50:52] <jhutz> [yes; that was it; thank you]
[23:51:00] <jhutz> Waiting for Allison's laptop to start working
[23:53:01] <hta> swaptop lap.
[23:54:05] --- mrose has left
[23:54:32] --- mankin has left: Disconnected
[23:54:44] --- ludomp has joined
[23:54:50] --- galvinjamesm has left
[23:55:08] <hta> so touching charlie's laptop with spencer's laptop made it work?
[23:55:24] <jhutz> Allison: "RFC Primary Marking"
[23:55:55] <jhutz> Issue is the informational and experimental RFC's that come in through the RFC-editor of non-IETF origin
[23:56:32] <jhutz> the most obvious cases where these are confusing is wheree they are very similar to IETF products.
[23:57:11] <jhutz> ... any random document that was worked on by the WG may be submitted later through the rfc-editor process and may look very much like a standard, and it's not clear to the public what the difference is
[23:57:58] <jhutz> rfc2026 states that iesg reviews only ensure they are not overlapping to "inimical" to IETF efforts.
[23:58:09] <jhutz> currently IESG does full technical review for this purpose
[23:58:39] <jhutz> for the most part they have a fair consistency with ietf documents, but they're not ietf documents, and the fact that they look similar can be confusing
[23:58:49] <jhutz> iesg review - new look...
[23:59:09] <jhutz> iesg has just revisited rfc2026 words.
[23:59:14] <jhutz> only light review. "secondary marker" planned.
[23:59:29] <jhutz> we've started a dialogue with rfc-editor about this; harald will talk at plenary
[23:59:46] <jhutz> they will not be as similar to ietf documents because they won't get the full review