[01:39:26] --- sob has joined
[01:56:26] --- Jim Galvin has joined
[01:56:49] <Jim Galvin> Hi Scott!
[01:57:39] --- yushun has joined
[01:58:04] <sob> hi jim - early here
[01:58:33] <sob> no audio yet
[01:59:31] --- shima has joined
[02:01:01] <sob> there is teh audio
[02:02:01] <Jim Galvin> I'm in Paris but not in the meeting room. I'm at the ISOC AC meeting listening to newtrk.
[02:02:26] --- jlcjohn has joined
[02:02:56] <sob> anything happing in isoc ac?
[02:05:02] --- taiji-k has joined
[02:06:05] <sob> say hi to Harald
[02:06:57] --- dotis has joined
[02:07:30] --- tonyhansen has joined
[02:11:39] <jlcjohn> Anyone here not have audio?
[02:12:54] --- arifumi@jabber.org has joined
[02:14:20] --- hartmans has joined
[02:14:27] --- bert has joined
[02:14:32] --- Bill has joined
[02:15:01] <sob> I'll send if I hear anything to send about
[02:15:02] --- becarpenter has joined
[02:15:03] --- resnick has joined
[02:15:38] <becarpenter> sob: harald knows you are in the room
[02:15:53] <becarpenter> projector keeps cutting out
[02:15:56] --- klensin has joined
[02:16:13] <becarpenter> engineer working on projector :-)
[02:16:26] <sob> yup I heard harald say that
[02:17:31] <sob> hand not raised for harald's question - I agree with John K - they are different in findemental ways
[02:19:40] <sob> added or not - we need to get the basic question of meta documents 1st
[02:19:50] --- leslie@ecotroph.net has joined
[02:21:00] <hartmans> What are meta documents?
[02:21:07] <becarpenter> ISDs and such
[02:21:19] <sob> what he said
[02:24:16] --- hta has joined
[02:24:27] <sob> morning harald
[02:24:31] --- falk has joined
[02:24:35] <hta> 0 – agenda bashing – 10m 1 - introduction & status - chair - 10m 2 - discussion on the issues with ISD proposal raised by the IESG and others - 60m What is ISD? What is SRD? What do we want? 3 - future of ISD proposal – 20m Larry’s implementation report idea – 5 min 5 - next steps with de-cruft – 30m 4 - next steps in newtrk - 30m How/when to discuss 1step/2step
[02:24:50] --- fanf has joined
[02:25:43] --- pigdog has joined
[02:26:07] <sob> harald - you can just read my note to the list on what ISD is
[02:26:34] --- resnick has left: Disconnected
[02:27:25] <hta> sob - give subject line, please
[02:28:25] <sob> In my mind those ideas are: 1/ a meta document that is *the* definition of an IETF standard i.e. the document that people in and out of the IETF would point to to indicate a particular standard (for example purchasing agents and other standards organizations) 2/ the meta document would point to RFCs and other documents but would not necessarily be published as a RFC 3/ the meta document would be last-called in the same way that current standards track documents are whenever it changed 4/ standards creators or modifiers (usually working groups but sometimes individuals) would be responsible for the creation and modification of the meta documents for new or revised standards and thus there would be little additional work for the IESG - this process might even reduce the IESG workload by continuing the movement of responsibilities to WG chairs. 5/ meta documents would not be universal - the more complex standards (e.g. TCP) might take more effort than the return would warrant and there might not be anyone interested in making meta documents for some of the old but not much used standards 6/ the meta document would include some type of maturity description for example, a pointer to interoperability reports and a statement of significant usage (the things that currently define Draft and Internet Standards) 7/ the meta document provides an anchor for authoritative and non-authoritative errata and a mechanism for distinguishing between them
[02:28:51] <sob> subject line was "thoughts from the newtrk WG chair"
[02:30:18] --- resnick has joined
[02:30:53] --- pigdog has left
[02:31:05] --- akatlas has joined
[02:31:09] --- gparsons has joined
[02:31:19] --- aschenbruck has joined
[02:33:03] <falk> stupid question: where is the SRD proposal documented?
[02:33:32] <sob> newtrk mailing list
[02:33:45] <falk> thx
[02:34:26] <hta> draft-otis. there is a draft.
[02:35:38] <falk> really? nak:/tmp falk$ ls ~/Documents/id|grep otis draft-chiotis-isdn-netmode-01.txt draft-dougotis-smtp-caa-01.txt draft-dougotis-srv-caa-01.txt draft-otis-ddp-iov-01.txt draft-otis-fc-sctp-ip-03.txt draft-otis-iscsi-fullack-01.txt draft-otis-marid-mpr-01.txt draft-otis-mass-reputation-01.txt draft-otis-network-overhead-01.txt draft-otis-newtrk-rfc-set-00.txt draft-otis-record-delivery-02.txt draft-otis-scsi-ip-02.txt draft-otis-sctp-ddp-02.txt draft-otis-sctp-digest-03.txt draft-otis-tcp-framing-01.txt draft-stewart-otis-sctp-ddp-rdma-02.txt
[02:35:55] <falk> ah, sorry. got it.
[02:36:14] <becarpenter> IESG comments on ISD proposal: http://darkwing.uoregon.edu/~llynch/newtrk/msg00999.html
[02:38:54] <sob> humm - I thought that it was clear that the ISD would be the document that woudl be last-called etc - i.e. it would be the thing that the standards process functions on
[02:39:31] <leslie@ecotroph.net> scott -- yes, but there were discussion about how it was created, reviewed, etc.
[02:40:04] <sob> agree that there may be some confusion there but I thought that the intent was clear (if not the specific process)
[02:40:08] <leslie@ecotroph.net> On a separate, but related, thread -- and one that *has* been discussed at least passingly on the list -- there can be value in having more than one meta document, perhaps put together by different people
[02:40:15] <leslie@ecotroph.net> for different purposes
[02:40:45] <leslie@ecotroph.net> ACK -- and that's why it isn't clear (to me, personally), that ISD is out so much as ISD needs more work
[02:42:05] <sob> any non-iesg/iab commenters (other than jk & spenser)
[02:42:28] <leslie@ecotroph.net> hmmm
[02:42:33] <Bill> dave crocker is in line after Alex
[02:42:39] <akatlas> session is only until 11:30
[02:42:40] <leslie@ecotroph.net> I didn't thnk I (or pete) were commenting from the iab
[02:42:47] <akatlas> sorry
[02:43:00] --- akatlas has left
[02:44:39] <sob> to Alex - the meta document (when it includes implementation reports and statements of deployment) may replace the N-staage standards process
[02:47:22] --- loa has joined
[02:48:10] --- shima has left
[02:49:55] <tonyhansen> people seem to keep forgetting that we already have a meta document description of standards: std-index.txt. The reason we got started down this track is that std-index.txt is: 1) wrong 2) deficient.
[02:50:03] --- leslie@ecotroph.net has left: Replaced by new connection
[02:50:12] --- leslie@ecotroph.net has joined
[02:51:29] * hartmans agrees strongly with Ted
[02:51:54] * resnick agrees with Ted that we disagree on the central issue.
[02:52:58] <hartmans> Who is speaking?
[02:53:05] <resnick> Doug Otis.
[02:53:06] <becarpenter> We know that implementers rely heavily on folklore that "everybody knows." Would this folklore still be folklore, or are we expecting to put all the folklore in the ISDs?
[02:53:48] <sob> imo - folklore should get written into RFCs if its important
[02:54:03] <becarpenter> it should, but often it doesn't
[02:54:46] <klensin> One could at least hint in an ISD that the folklore is out there and is or is not important. _And_ I agree with Scott. Note that standards that can be implemented only by knowing folklore are bad trouble, technically and legally
[02:54:48] <resnick> And this is a time lag wrt folklore because people don't want to re-open old specs just to include folklore.
[02:55:15] --- akatlas has joined
[02:55:23] <hartmans> sob: are you wanting channeling or you just participating in the jabber back channel?
[02:55:37] <hartmans> In general, it would probably be good if you ask for explicit channeling if you want it.
[02:56:02] --- hugo.santos has joined
[02:56:03] <sob> Isam - I'll try t be clear when channeling would be goo (imo)
[02:56:14] <hartmans> resnick: I argue a fairly core probelm is making reopening old specs for small changes esay.
[02:56:34] <becarpenter> goo?
[02:56:51] <hartmans> I don't like the solution of throwing things in ISDs. I realize we have a similar solution of throwing things in updating RFCs, but I think that process has better weighting than throwing things in ISDs
[02:57:01] <sob> I agree with sam - the "small problem" issue is a big problem that ISDs (or SRD) do not fix
[02:58:03] <becarpenter> RFC Editor is 6 months late posting errata- would fixing that remove the need for errata in ISDs?
[02:58:26] <hartmans> sob - I thought ISDs or at least the ISD erata section claimed to fix that problem. Certainly that was raised as an advantage in jck's IESG presentation
[02:58:52] <becarpenter> errata in ISDs sems like duct tape to me. better to associate the errata directly with the RFC
[02:58:54] <resnick> sam: I guess my opinion is that *that* problem is more about the entire document process and not just about which documents are our standards.
[02:59:01] <hartmans> Brian, in at least one case Russ and I were told they simply would not publish the erata
[02:59:09] <bert> brian are they really 6 months behoind? My experience is they post them pretty quick if the erratum is clear
[02:59:20] <becarpenter> Yep, well feed that to the techspec draft
[02:59:24] <hta> bert: they CLAIM to be 6 months behind.
[02:59:32] <becarpenter> bert: they said six months this week
[02:59:46] <resnick> And I don't think we're just talking about errata in the realm of "small changes" that ISDs would do better than the current process.
[02:59:46] <bert> mmm... so there must be some tough ones there.
[03:00:28] <sob> sam - imo the errata section was just the same as teh errata stuff on teh RFC Editor web site - a filterd (by document author/WG/IESG) list of text bugs
[03:00:51] <sob> not a way to change the specifications in any fundimental way
[03:00:55] <hta> I think they've just been stressed enough by our demand for faster RFC processing that they dropped the whole errata processing.
[03:01:06] <becarpenter> sob: sure. And I'd prefer it to be directly hanging off the RFC
[03:01:59] --- dcrocker has joined
[03:03:31] --- hugo.santos has left
[03:03:32] --- shima has joined
[03:03:34] <klensin> One could lose the errata from the ISDs without changing the concept. However, there would be a problem with the RFC Editor's list if it were updated in real time, which is that there is confusion about whether errata assertions were consistent with community consensus or not. For typos, who cares. But, for anything else, the only option for making a normative correction right now is to reissue the RFC.
[03:03:48] <sob> the problem with it hanging on teh RFC is only the finding of them - having them in (or pointed to by) the meta document is a way to make sure that the reader knows they are there
[03:04:21] <sob> agree with JK - the errata is not the key concept
[03:06:01] <hartmans> klensin: I think re issuing the RFC is in fact the right thing to do and we should make issuing rfcs for small but important changes easy.
[03:06:42] <hartmans> And as I said, the erata is actually in fact just a detail.
[03:06:49] <tonyhansen> rfc 2026b, rfc 2026c, rfc 2026d
[03:06:51] <Bill> like for seed?
[03:07:12] <hartmans> I think the differences between ISD and SRD are all just details and really not that many details.
[03:07:13] <hta> fast reissuing of RFCs is a separate-but-also-important problem.
[03:07:22] <hartmans> I think the motivations are fundamentally different
[03:07:31] <hartmans> I also think there is a continuum between SRD and ISD
[03:07:35] <klensin> Sam: easy, sure. Want to see a two-year queue?
[03:07:53] <hartmans> bill: Yes.
[03:08:32] <sob> fast reissuing of RFCs just makes the 'what shoudl be in a purchase order" problem harder w/o some type of authoriative meta document
[03:09:35] <hartmans> hta: You cannot reasonably say foo is a separate problem. This is all inter-related. Scott's example that fast reissue makes metadocuments even more important is illustrative.
[03:09:57] <klensin> sam: I agree, there is a continuum. And, since he first proposed SRDs, they have, IMO, evolved toward ISDs. The main difference, as far as I can tell, is that he believes one can have a ocument with all this stuff in it and have people not treat it is normative... that won't work and is, again IMO, very dangerous
[03:10:02] <hta> "separate" =/= "unrelated", Sam.
[03:10:15] <hartmans> John, We need to solve the RFC queue problem anyway. I strongly suspect we could have significantly faster bandwith for the money we are spending.
[03:10:19] <Bill> klensin: why should adding a paragraph to an already edited document lead to a 2 year queue?
[03:10:41] <leslie@ecotroph.net> Sam -- we *are* working on the queue problem. Ray (IAD) is actively working with them.
[03:11:16] <hartmans> I think that we need to have a serious discussion about update authorization policy for most things in his status database.
[03:11:36] <resnick> sam: It's not just the RFC Editor queue. It's about the IESG queue as well.
[03:11:43] <klensin> Bill: Why? That was just a prediction. And SOB is right, flooding ourselves with nearly-identical RFCs would increase the confusion level, fwiw.
[03:11:49] <sob> sam - I see what you mean - what doug is saying could almost all describe ISDs
[03:11:57] <becarpenter> Try http://www.geocities.com/be1carpenter/smtpSRD.html
[03:12:25] <becarpenter> munged from Doug's I-D
[03:12:30] <resnick> sob/sam: Agree on SRD/ISD approaching eachother.
[03:12:35] <leslie@ecotroph.net> Pete -- then you'd better add in the WG and auth queues, too.
[03:12:49] <hartmans> sob: Yes, but what Doug's proposes somewhat interests me; what ISDs seem to be really sounds like a step in the wrong direction. I find that reaction quite interesting given how close they are.
[03:12:52] <resnick> leslie: absolutely.
[03:13:13] <hta> sam: that's one reason why I have a hard time understanding your reactions.......
[03:13:40] <Bill> klensin: e.g., fixing rfc3667/3668 (which was supposed to take a month and took 1.5 year)
[03:13:40] <sob> sam - so what is it that repells you so much about ISDs when you seem to agree with at least some of the goals
[03:13:54] <becarpenter> sam is in line for the mic
[03:14:47] <becarpenter> larry is muttering
[03:17:37] <becarpenter> while jck is away from his screen: quick understandability of the proposal is one of the differences I see
[03:18:25] <sob> alex - thats in ISD
[03:18:39] <tonyhansen> reference my jabber comment 20 minutes
[03:20:37] <klensin> Alex: the STD numbers are not used because (1) they only exist for full standards and we don't have a lot of those. (2) they have the wrong granularity
[03:21:06] <leslie@ecotroph.net> the consumers are the engineers who *don't* come here
[03:21:13] <leslie@ecotroph.net> and there are more implementers than spec creators
[03:21:27] <leslie@ecotroph.net> and *those* engineers *do* want something; grouping could be it
[03:21:30] <becarpenter> not to mention RFP writers
[03:22:05] * resnick nods head up and down vigorously in agreement
[03:22:40] <sob> sam - even if the text is just the abstract
[03:22:47] <tonyhansen> it would be nice if STD numbers *could* be used. The biggest problem is exactly that they only reference full standards, and because our 3 track process is broken, the usefulness of it has become similarly broken
[03:23:03] <becarpenter> tony: right on!
[03:23:24] <becarpenter> hence the 2 step and 1 size proposals - they fix that
[03:24:12] <sob> channel please - sam - note that the ISD proposal could just use the existing standards action text - no new text might be needed
[03:26:18] <hartmans> Scott, if the text is mandatory, I think you can write srd2isd as a tool that requires no human input
[03:26:35] <hartmans> And probably isd2srd as a tool that strips out text.
[03:27:22] <sob> sam - agree (see my stds trk ISD for an example that could fit the auto-extract model)
[03:27:43] <becarpenter> ineed, the one I put up just now gets a 404 error on the status link
[03:27:51] <sob> sam - even if that ID is a poster child of what you donlt like :-)
[03:27:53] <becarpenter> that's the hard part
[03:27:58] <hartmans> So, yeah, if you removed erata and required that the text be generated from something else, and had tools to generate ISDs just given a set of document names, then I don't care about the difference between SRD and ISD
[03:28:40] <resnick> sam: I take it you don't mind if someone wants to hand-tune an ISD/SRD?
[03:29:16] <hartmans> Sure. I'm going to like the format that you get from an SRD, but I completely agree that once it is the same information, it does not matter
[03:29:30] <sob> I would also want to be able to support things like the TCP roadmap but not require it
[03:30:19] <klensin> exactly
[03:31:01] <becarpenter> sob: did you want to raise yr hand?
[03:31:05] <hartmans> I believe that supporting the roadmap will slow things down a lot.
[03:31:09] <sob> how many for (4 against)
[03:31:17] <hartmans> If you want to write a roadmap document, just do so.
[03:31:35] <leslie@ecotroph.net> about half the room
[03:31:42] <leslie@ecotroph.net> about 20 people
[03:31:44] <sob> tnx
[03:31:49] <tonyhansen> room has ~40 people
[03:32:05] <Bill> genisd rfc2026 rfc3777 rfc3978 rfc3979 ?
[03:32:24] <becarpenter> bill: are you coding it?
[03:32:44] <hartmans> In particular, if I have a roadmap once, then every time I try to revise that standard I get into discussions about the text in the roadmap.
[03:32:45] --- fanf has left: Disconnected
[03:32:52] <sob> bill see - draft-bradner-stdproc-isd-01.txt
[03:33:03] <Bill> no, my coding skills left me yesterday afternoon and probably won't return until Monday or so
[03:33:13] <leslie@ecotroph.net> sam -- that's in part why I would like to see the roadmap as an overlay, of which there might be several
[03:33:18] <sob> saym - yes - you are right - roadmaps are hard
[03:33:34] <hartmans> However if I have SRDs then I only get into that discussions when I have to because I'm actually revising the text
[03:34:46] <sob> sam - agree - extracted-text or fact-only meta documents are easier - there is still teh question of what documents get included
[03:35:27] <hartmans> Yes, but the question of what documents are included is the fundamental question of grouping. I accept that grouping is valuable
[03:35:44] --- pigdog has joined
[03:35:56] <sob> we are getting closer :-)
[03:37:11] <becarpenter> q1 should they exist?
[03:37:17] <pigdog> {eliot} for reference in a few minutes decruft presentation is at http://www.ofcourseimright.com/~lear/cruft-newtrk63.pdf
[03:37:21] <becarpenter> q2 should they be approved
[03:37:37] <sob> "should" or "how should"
[03:37:39] <becarpenter> q3 should they be ableto contain text
[03:37:53] <becarpenter> q4 should they normally contain text
[03:38:09] <becarpenter> but we got digressed from answering those questions
[03:38:22] <becarpenter> q2: plain should
[03:41:34] <bert> harald inserted a q2.a: Should they be required
[03:42:51] --- jhutz has joined
[03:43:01] <leslie@ecotroph.net> I wonder...
[03:43:13] <leslie@ecotroph.net> if, when you group, you will be able to come up with "the" authoritative standard
[03:43:13] <resnick> who wrote the book of love?
[03:43:29] <falk> resnick: :)
[03:43:54] <leslie@ecotroph.net> i.e., I expect we actually leverage the ambiguity natural in having pieces of standards in different documents, now.
[03:44:23] --- dotis has left: Disconnected
[03:44:25] <leslie@ecotroph.net> that thought was provoked by Doug's assertion of "the grouping" being the only "authoritative" piece
[03:44:35] <leslie@ecotroph.net> authoritative as compared to *what* ?
[03:44:45] <becarpenter> jck: and that is a strong argument why text in ISDs is a clear difference from no text in SRDs
[03:44:52] <Bill> different groupsing including the same set of documents
[03:45:07] <leslie@ecotroph.net> more likely different subsets
[03:45:08] <bert> q1 changed to: Should a type of grouping document exist?
[03:45:11] <hartmans> Someone should sit down with Doug and have the authoritative discussion
[03:45:17] <Bill> yes, sorry, my brain is no longer working
[03:45:26] <Bill> overlapping sets is what I meant
[03:45:29] <becarpenter> SRDs as a list of approved docs does not add normative value; ISDs with text does add normative value
[03:45:34] <leslie@ecotroph.net> bill - yep, exactly
[03:45:36] <Bill> but I think we talked about this long ago
[03:46:06] <leslie@ecotroph.net> I'm not sure which value of "we", and I'm concerned that it not get *lost* as we go along
[03:47:34] <jhutz> Yeah; that seems to be what opsec is spending quite a bit of its time on.
[03:47:40] <sob> yes - bcp could work (process wise)
[03:47:40] <Bill> yeah that "we" was me, sob, jck, ... at a lunch meeting, I think. I think I should shut up because I am being too unclear.
[03:48:02] <resnick> bec: Right.
[03:48:19] <jhutz> And it's an interesting approach I haven't seen before in the IETF, giving operators something they can cite internally and to vendors
[03:49:02] * Bill slinks away at the mention of tools
[03:50:40] <hartmans> Brian, I do think SRDs have strictly greater value than STDs
[03:50:58] <hartmans> ANd I think STDs have some value
[03:51:15] <becarpenter> sam: yes, more value and that is more work
[03:51:50] <jhutz> Brian, I don't think that necessarily follows. It is possible to spend an awful lot of work and get little value.
[03:52:02] <becarpenter> STDs should have value; the problem is that we don't really create it
[03:52:23] <jhutz> Yes.
[03:53:07] <becarpenter> jhutz: of course. But my point is that ISDs *would* require review and approval because they contain potentially normative text
[03:53:15] <hartmans> One of the reasons SRDs have more value than STDs is they are less work
[03:53:24] <hartmans> In that they do not require you get to full.
[03:53:25] <sob> or normative grouping
[03:53:39] <klensin> The reason STDs don't have much value is that simply grouping things without qualification or comment turns into the same problem as one-word maturity level categories
[03:53:44] <becarpenter> but SRDs could be largely robotic
[03:55:02] <klensin> Either could be robotic. Depends on whether any of the text that doesn't appear anywhere else is required
[03:55:05] <hartmans> Brian, I disagree that grouping is robotic
[03:55:34] <becarpenter> sam: yes, you're correct. s/largely robotic/robotic/
[03:55:47] <jhutz> I think the reason STD's don't have much value is that it takes so long for a spec to become one that by the time it happens, no one cares
[03:55:49] <hartmans> I.E. I think deciding where to break the boundary between groups is actually hard.
[03:55:57] <becarpenter> jck: true, but if the text is extracted, why bother?
[03:56:49] * hartmans agrees a lot with jhutz
[03:57:42] <tonyhansen> can STDs *become* the grouping? In other words, can the current definition of STDs be augmented to have what it needs to be useful. One part of that would be to make STDs true to what we feel the standards *really* are (not necessarily *full* standards, but including proposed, etc. flavors).
[03:57:55] <klensin> Brian: Exactly my point. And I agree with Sam that grouping is hard, really hard.
[03:58:10] <jhutz> Well, there certainly are STD's that refer to groups of documents.
[03:58:39] <hartmans> What just happened over here?
[03:59:01] <klensin> And the groupings in STDs have often been controversial (and there is no approval process for them)
[03:59:18] <jhutz> Giving something an STD number before it reaches full standard might have some value. Reducing the length of the standards track might also have some value; I think this WG has been discussing such a thing, but I must admit I don't follow newtrk closely
[03:59:36] --- tonyhansen has left
[04:00:02] <becarpenter> jhutz: yes. That solves the confusion caused by a PS obsoleting a full Standard (e.g. 2822/822)
[04:00:05] --- tonyhansen has joined
[04:00:06] <sob> channel - approval issues: whats in group, is implementation report OK, is maturity statemnt OK
[04:00:58] --- raeburn has joined
[04:01:06] <jhutz> I guess the only STD groups I've noticed have been ones I wouldn't expect to be controversial. But I bet you have a larger sample than I
[04:01:15] <sob> channel - clarification approval == last call & IESG OK?
[04:02:03] --- fanf has joined
[04:02:11] <jhutz> brian: it does? how would you handle the 822/2822 case?
[04:02:19] <sob> brian - if text is just abstracts from RFCs then no different
[04:03:13] <tonyhansen> well, *someone* is making a decision as to what consists a STD grouping. that's essentially the question being discussed in the room right now: who should "approve" the grouping?
[04:03:32] <becarpenter> if the STD n designation was attached to 2822, the obsolete status of 822 becomes much clearer. Today users are confused about the "standard" is.
[04:04:03] <jhutz> Well, except does 2822 replace 822 immediately, or when it reaches full standard status?
[04:04:25] <becarpenter> sob: true but then there needs to be text flagged "new" or "extracted"
[04:04:34] <sob> channel - clarification? text beyond rfc abstracts
[04:04:41] <jhutz> I guess right now my expectation is that when 2822 reaches full standard, it will replace 822 under the same number.
[04:04:59] <becarpenter> jhutz: back to why a 1 stage standards track is much easier to understand
[04:05:04] <falk> sob: I think abstracts & protocol action text, I believe
[04:05:10] --- aschenbruck has left
[04:05:27] <bert> for me, it seems answer to q1 is rougly "yes". Answer to q2 is: do a experiment; fthe answer to the other wuations for me all comes down to: let us see what these "grouping docs look like" and run some tests so we can see what actually gets developed
[04:05:29] <Bill> sob: I asked that earlier, I think the sense was if the text is no different from the abstract & protocol action text then it's not text
[04:05:54] <sob> just wanted to be clear in Harald's question
[04:06:06] <jhutz> Oh, yes, a 1-stage track would definitely make the problem go away.
[04:06:39] <jhutz> But I would sort of like to still have a state that means "no really, this is not a standard yet" that something can sit in while we're waiting for interoperableimplementations.
[04:07:55] <tonyhansen> jhutz: that's because of the current definition of what is included std-index, and hence the need for something alternative because std-index is no longer fitting the role it was originally intended for. My take is that if 3-track were fixed, std-index *could* be made to work again, *AND* we wouldn't really need ISD's, SRD's, etc.
[04:08:07] <akatlas> jhutz: I agree.
[04:08:37] <tonyhansen> jhutz: that's probably the biggest argument against 1-track and for 2-track.
[04:08:40] <jhutz> At this stage in the evolution of the internet, I don't think we need more than 2 stages.
[04:09:25] <jhutz> OF course, no matter what we do it will be really hard to convince people not to think of random RFC's (or I-D's!) as standards.
[04:09:38] <tonyhansen> jhutz: :-)
[04:09:50] <jhutz> But things are easier to evaluate if we only try to change one variable at a time
[04:10:33] <jhutz> What happens to the implementation reports that are needed to reach DS?
[04:10:59] <sob> I thought that was what Larry was talking about
[04:11:24] <jhutz> Yeah; that's why I asked the question
[04:11:44] <pigdog> i think ds goes away under his ideas...
[04:11:53] <pigdog> you get implementation reports
[04:11:59] <pigdog> or not.
[04:12:09] --- RandyG has joined
[04:12:16] <sob> note that DS (and S) are basically indicators of maturity
[04:12:37] <sob> with DS maturirty indicated by a implementation report
[04:12:42] <pigdog> scott, i think what he's saying is to judge maturity by # of implementation/interoperability reports
[04:12:55] <jhutz> Yeah. But I'd like PS to really mean "not a standard yet", rather then just "really immature standard" like it often effectively means today
[04:12:59] <sob> # or existence?
[04:13:11] <sob> (of implementation reports)
[04:13:12] <jhutz> anyway, what I meant was what happens to them today?
[04:13:14] <pigdog> well, that's the difference between 0, 1, and many....
[04:13:44] <tonyhansen> they get sent to the iesg/ADs and blackholed :-)
[04:13:46] <sob> oh - an implementation report is required for move to DS and its put on teh IETF web page
[04:14:23] <sob> http://www.ietf.org/IESG/implementation.html
[04:15:22] <jhutz> Yup; I found them. Thanks
[04:16:03] --- pigdog has left
[04:16:53] <jhutz> implementatioin reports are supposed to be reporting facts, or at least allegations. They don't embody decisions or engineering, so I don't think they should be consensus documents.
[04:17:08] <jhutz> (just as they are not today)
[04:18:07] <tonyhansen> re decruft -- to echo Nike: just do it
[04:18:29] <jhutz> tony: agree
[04:18:29] <sob> the decision part is if the report meets the requirements for such reports (and there are no written descriptions of what those requirements are)
[04:19:14] <jhutz> yeah, so that ends up being mostly an IESG decision - mostly it's about whether they (and the community at large) are satisfied that the requirements for DS have been met.
[04:19:34] <jhutz> I'd love to see a document providing more guidance on what is required for an implementation report
[04:19:55] <sob> yup - in addition a pointer to the implemetation report is included in teh last call for DS
[04:20:19] <sob> I would hope that Larry's proposal will wind up providing that guidance
[04:20:20] --- resnick has left
[04:20:27] <jhutz> me too
[04:21:55] * hartmans wishes we could get RFc 1510 added to this list
[04:22:34] <jhutz> Heh.
[04:23:25] <hartmans> I'm actually quite serious that 1510 needs to go to historic.
[04:23:40] <jhutz> So let's do it
[04:23:48] * hartmans was puzzled that publishing a proposed that obselets a proposed doesn't make the obseleted proposed historic
[04:23:53] <sob> sam - with some replacement or all of kerberos 'just say no'
[04:23:58] <jhutz> We just published its successor at the same maturity level
[04:24:10] <jhutz> The replacement is RFC4120
[04:24:16] <Bill> sob: it has a replacement
[04:24:23] <hartmans> 4120 obseletes 1510
[04:24:59] <Bill> yeah, "obsoletes" vs "historic" is very very subtle
[04:25:06] <sob> 2026 permits obsoleting also moving to historic - why wasn't that done?
[04:25:20] <jhutz> I think an "RFC1510 to historic" document would be within the scope of krb-wg's charter, if someone wanted to submit one
[04:25:29] <Bill> 2822 "obsoletes" 822 but 822 is Standard and 2822 is PS, resulting in much confusion
[04:25:44] <jhutz> sob: mostly because we were dumb and didn't do it
[04:25:57] <sob> I donlt think its needs a document to do that - the WG can jsut send a note to the IESG asking for that
[04:26:13] <sob> so make up for past "dumbness:
[04:26:23] --- klensin has left: Disconnected
[04:26:33] <jhutz> Well, if that's true, I'm sure we can pull that off
[04:26:36] --- yushun has left
[04:27:20] <hartmans> Yeah, jhutz, just last call to historic in krb-wg, and if that is successful I'll enter in the tracker.
[04:28:04] <hartmans> sob: We all assumed that it automatically did that
[04:28:37] <sob> nope - not automatic - because the old version might be OK (i.e. not dangerious)
[04:30:27] --- taiji-k has left: Disconnected
[04:31:20] --- akatlas has left: Replaced by new connection
[04:31:48] --- akatlas has joined
[04:31:49] <jhutz> I've sent a message to the krb-wg list on that topic
[04:31:52] <sob> humm - how much time shoudl it take for the IESG to last call this list and then approval?
[04:32:20] <jhutz> The cruft list? I should think it wouldn't take many IESG cycles...
[04:32:28] <tonyhansen> I've long felt that there is seldom a need for there to be a document published to move a document to historic
[04:33:32] --- falk has left
[04:33:51] <Bill> tonyhansen: yeah, it seems to make sense to just make it happen. (ignoring that I'm the most recent AD to have a "move this document to historic" document)
[04:34:06] <sob> I think there needs to be a doc if we want to say that someting is "dangerious" becuase that message shoudl be a lasting one - but if someting just unused or obsoleeted then I see no reason for a doc
[04:34:07] --- leslie@ecotroph.net has left: Disconnected
[04:35:32] <jhutz> ==sob
[04:35:40] <Bill> sob: in the kerberos case, the new RFC with the new version is enough? i.e., 1510 The Kerberos Network Authentication Service (V5). J. Kohl, C. Neuman. September 1993. (Format: TXT=275395 bytes) (Obsoleted by RFC4120) (Status: HISTORIC)
[04:35:47] --- hartmans has left
[04:36:17] <sob> bill - I'd say so
[04:37:02] <tonyhansen> sob: agree. hence my comment about "seldom"
[04:38:00] --- dcrocker has left: Disconnected
[04:42:46] --- gparsons has left: Disconnected
[04:43:11] --- Bill has left
[04:45:26] --- akatlas has left
[04:45:38] --- raeburn has left
[04:46:03] --- Jim Galvin has left
[04:46:30] <jlcjohn> Whew!
[04:46:32] --- RandyG has left
[04:46:46] --- loa has left
[04:47:34] --- sob has left
[04:47:49] --- hta has left
[04:52:09] --- jhutz has left: Disconnected
[04:52:17] --- arifumi@jabber.org has left
[04:57:01] --- bert has left
[05:01:03] --- fanf has left: Disconnected
[05:04:16] --- shima has left
[05:07:08] --- becarpenter has left: Disconnected
[05:09:20] --- tonyhansen has left: Disconnected
[06:44:16] --- becarpenter has joined
[06:45:19] --- jlcjohn has left: Disconnected
[07:00:13] --- becarpenter has left
[16:08:18] --- bert has joined
[16:08:43] --- bert has left