Re: I-D ACTION:draft-carpenter-newtrk-questions-00.txt
Just a reminder that we will spend a little time on the question asked by this draft in plenary on Wednesday. Brian ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: I-D ACTION:draft-carpenter-newtrk-questions-00.txt]
On Sun, 2006-06-18 at 22:05 -0700, C. M. Heard wrote: [ follow-ups to IETF discussion list please] Of the three possible ways forward suggested by this draft, I think that the only one that's likely to get done is this one: 1. Agree that, apart from day to day efforts to improve efficiency, the problems with the existing standards track are not serious enough to justify the effort needed to make substantial changes. Conclude that [RFC3774] exaggerated the problem and we only need to make a relatively minor set of clarifications to BCP 9 [RFC2026]. I say this because the newtrk WG has already tried to do the other two things that were suggested (focusing on document relationships and reworking the standards track) and failed. The deafening silence on the WG mailing list suggests to me that the energy has run out of this WG and it should be closed. I believe that two modifications (not clarifications) to RFC 2026 would suffice: - drop the expectation that a document will necessarily ever advance, and drop the requirement for periodic reviews of documents at PS or DS; - drop the no normative downrefs rule. This last should be done with an absolute minimum of fuss and with no imposition of requirements to put special notes in the documents about downrefs. If we can't agree on that, then I would settle for just the first modification. That would at least get our documented procedures more in line with the reality that we practice. There isn't necessarily a lack of energy. How to deal with the confusion created by a system failing to organize information? It does not appear to be a satisfactory solution describing the lack of maintenance related to document categorization lame and leave it, as this appears to suggest. When the newtrk wg had last met, there did appear to have been progress made defining a method to formally describe the relationship between sets of documents. Had that proceeded, stable and serialized references would have been established for organized sets. From those references, less effort would be needed to process the categorization, by looking down from the top, rather than by lookup up from the bottom. These two views are very different, and describing a document as a thing unto itself often makes little sense. RFC3377 is an example of an effort to define a set, but this type of approach is clumsy and adds little visibility. Perhaps this organizational effort needs to move elsewhere. The direction that was envisioned for the SRD proposal was to ensure the IETF members compose those sets without altering the individual documents. A follow-on categorization of these sets would cull out the best and most meaningful by raising the status of those sets appropriately. This should overcome maintenance issues and avoid downref problems. Newtrk could still contribute by taking meaningful steps to transform the ever flattening and broadening landscape that offers ever fewer landmarks, by providing form and dimension. RFC DS PS and BCPxx can be improved by providing the minimalist organization of these documents into Name.Serial sets. XML seems to be a natural way to achieve that goal, which should also be integrated into the IETF HTTP presentations. The construction of the XML documents could even be developed using web-based tools, rather than expecting everyone to use their own XML editors, or to know how to read and check the required syntax. The SRD proposal also allowed a temporary prefix. This prefix conveyed Work In Progress to impose fewer barriers for those wishing to take advantage of these tools at the conception of an idea. The organization of documents into sets could help at very early efforts, all the way to completion. This becomes a forward/downward perspective, as opposed to the current backward/upward perspective, where it become hard to see the forest for the trees. -Doug ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: I-D ACTION:draft-carpenter-newtrk-questions-00.txt]
[ follow-ups to IETF discussion list please] Of the three possible ways forward suggested by this draft, I think that the only one that's likely to get done is this one: 1. Agree that, apart from day to day efforts to improve efficiency, the problems with the existing standards track are not serious enough to justify the effort needed to make substantial changes. Conclude that [RFC3774] exaggerated the problem and we only need to make a relatively minor set of clarifications to BCP 9 [RFC2026]. I say this because the newtrk WG has already tried to do the other two things that were suggested (focusing on document relationships and reworking the standards track) and failed. The deafening silence on the WG mailing list suggests to me that the energy has run out of this WG and it should be closed. I believe that two modifications (not clarifications) to RFC 2026 would suffice: - drop the expectation that a document will necessarily ever advance, and drop the requirement for periodic reviews of documents at PS or DS; - drop the no normative downrefs rule. This last should be done with an absolute minimum of fuss and with no imposition of requirements to put special notes in the documents about downrefs. If we can't agree on that, then I would settle for just the first modification. That would at least get our documented procedures more in line with the reality that we practice. Mike Heard ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: [Fwd: I-D ACTION:draft-carpenter-newtrk-questions-00.txt]
My perception is that often in the IETF, protocol and process design works best that codifies and regularizes what is already being deployed. I disagree with this characterization. If a protocol that is already being deployed is well-designed, IETF generally does a good job of documenting it and cleaning up the nits. However just because a protocol is already being deployed does not mean it is a well-designed protocol, and IETF generally has a difficult time fixing poorly-designed protocols that are already being deployed. In my experience it is rare that a protocol that is already being deployed is well-designed - usually they are lacking in scalability or security or both. IETF has more trouble designing protocols from scratch than if there is already a well-designed protocol that it can use as a starting point. But IETF can often design a better protocol than one that is already being deployed. Not surprisingly, it takes longer to design a new protocol than to tweak a good protocol that already exists. But it takes even longer to try to fix a poorly-designed protocol. The general circumstances under which IETF has trouble designing new protocols are either or both of these: 1. When there are substantial conflicts between major industry players about strategic direction in that area. 2. When the working group set up to design this protocol has poorly-defined or inappropriately-defined scope. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
[Fwd: I-D ACTION:draft-carpenter-newtrk-questions-00.txt]
I invite the IETF community to read this draft and discuss the choices it suggests, between now and the Montreal IETF. Brian Original Message Subject: I-D ACTION:draft-carpenter-newtrk-questions-00.txt Date: Fri, 09 Jun 2006 15:50:01 -0400 From: [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] To: i-d-announce@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Questions about the standards track Author(s) : B. Carpenter Filename: draft-carpenter-newtrk-questions-00.txt Pages : 10 Date: 2006-6-9 This document sets out some thoughts about three possible directions for further work on the evolution of the IETF standards track. Its purpose is to stimulate community discussion leading to a choice between these three directions. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-carpenter-newtrk-questions-00.txt ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: [Fwd: I-D ACTION:draft-carpenter-newtrk-questions-00.txt]
My perception is that often in the IETF, protocol and process design works best that codifies and regularizes what is already being deployed. The model that seems to be emerging is that we now have a lot of revisions of first-generation protocols, with the recent slew of LDAP announcements as one example. They are typically marked as 'rfc1234bis'; the I-D database currently lists around 85 of these drafts as being active. The act of revising an earlier RFC presumably indicates that there is sufficient community interest in the technology and that this is maintenance based on implementation experience rather than a new protocol development. By default, declaring that '*bis' efforts are the second level of maturity unless there is an objection during last call would be sufficient to differentiate them from first, largely pre- implementation specs. (Naturally, RFCs that were perfect on first try could get petitioned into the second maturity level, with a simple method of collecting support from N independent parties, convincing and AD and based on a last call.) I don't see why the grouping/labeling of RFCs can't proceed in parallel, but in a different group. This seems much more mechanical and tools-oriented and could probably be done more readily on an experimental basis. If whatever mechanism is chosen doesn't work out, we can phase it out or supplement it with something else. Such experimentation seems harder to do, without major confusion, for standards maturity levels. On Jun 10, 2006, at 3:17 AM, Brian E Carpenter wrote: I invite the IETF community to read this draft and discuss the choices it suggests, between now and the Montreal IETF. Brian ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
