Re: Complaining about ADs to Nomcom (Re: Voting (again))
This is a good suggestion in the sense that as far as I can see, it would fall within the current BCP rules, and could be implemented easily soon. Then we could take a bit more time to update the BCP in parallel, while perhaps also getting some early experiences on how well the new model works. --Jari How about when someone tosses their hat in the nomcom ring, they indicate if their name can be made public. Nomcom publishes a list of these names & a note about the number of candidates who are anonymous. The genereal IETF than has a somewhat better idea of who to provide comments on & candidates can remain anonymous. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: improving WG operation
Tom> Wouldn't a system of mutual endorsements (a web of trust), Tom> suitably loudly broadcast, be an alternative to elaborate Tom> committee procedures? > Yes, but it would not really be the IETF. There's IETF in theory and IETF in practice. Also note that I believe that a discussion of whether this alternative is a good idea should probably move off the ietf list fairly quickly. I agree. As I said, I'm trying to strongly tend to "return to my seat". I object to the implied assertion that IETF *couldn't* go in this direction and remain IETF. As I also said: I think this time in history is a unique opportunity to do so. I'm mostly repeating myself, so: thanks for listening. -t ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: improving WG operation
> But if you aren't interested, why are you here? What's your interest? I > don't understand your point. Are you here to convince the rest of us that > the IETF is irrelevant? Absolutely not. Nearly the opposite. I hope that if you look back at some of my other messages in this thread that's clear. >> You're complaining that some application-layer stuff like IM >> isn't as orderly as you'd like. > Disorder isn't good for the users, either. Its not just a personal > view of orderliness. And it isn't good for the market to have such > unnecessary and gratuitous disorder. That's why standards of any > form exist. I'm not so sure IETF can help user's other than by producing very good, easily accessed documents with available reference implementations. An endorsement/trust-based system for calling attention to good standards seems like all you've ultimately got -- why not institutionalize *that*? Why *isn't* the rest of the governance simply noise? Why *isn't* the rest of the governance simply a game a professional organization has agreed to play that will ultimately turn it into just another consortium? Isn't the rule-mongering just a very indirect attempt to find rules that coincidentally create the effects an endorsement/trust system would render in a more naked form? What's the "value add" of anything beyond an endorsement/trust system? My answers to those questions are clear and that's why I say: strike while the iron is hot -- while there are still recognizable names who roughly essentially deserve trust? -t ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Voting (again)
Lars-Erik Jonsson (LU/EAB) wrote: Joe> delegation) or make their work smaller (by encouraging Joe> feedback to be directional - as in 'take to WG X' - rather Joe> than technical review). Sam: I'll certainly remember this when reviewing documents you author;) Seriously, I think most people would be really annoyed if I wrote up a discuss of the form "this sucks for foo reason; please coordinate with bar wg until they are happy then I'll clear." They would be even more unhappy if I wrote up the more realistic "please take this to bar wg and when they are happy I'll re review." Actually, I would consider a diplomatically-worded version of the former very useful. The latter is the problem - it lacks the reason the WG is being added as a hurdle. IMO, anytime a doc is held-up via Discuss, the reason for the discuss That is visible in the tracker. and the criteria under which it can be cleared should both be required. The IESG plans to publish a draft about what are, and are not, valid criteria for a DISCUSS. I fully agree with Joe, that kind of direct and concrete feedback would at least make me much happier than what we have today, when I have to find out myself whether there were any discuss comments, who made them, hopefully to some degree understand what the issues were about, and make qualified guesses on what I (as chair or author) am expected to do to address them. The theory is that WG Chairs and authors *should* be copied on the DISCUSS comments, since otherwise they can never be resolved. However, we lack some automation, so it does still depend on the ADs generating email. Brian ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: text suggested by ADs
This is a combined response to a number of messages under the same subject field: Ralph Droms wrote: ... Which is why I suggest ADs provide technical input in open mailing lists during last calls, to make sure their technical input is on the same footing as everyone else's technical input. I agree that the IESG's job is to ensure correctness, completeness, etc. That feedback should be provided earlier, in an open forum. That doesn't scale, since all ADs are at least in theory supposed to look at all drafts that land on the IESG's table. They will only be able to engage earlier (pre and during Last Call) in a very small fraction of cases. As long as the IESG is the back-stop, there *will* be late feedback - it's inevitable. Hallam-Baker, Phillip wrote: ... > Once again we come back to one of the core problems with the IETF > processes being a complete lack of information on the Web site. That's hyperbole, but we are very much aware that the web site needs a rethink. And we're also aware that that is a costly and complex process. John Loughney wrote: > Bill, > > When is a DISCUSS not a discuss? When it is a "You have to fix > this and I'm holding a DISCUSS until it's fixed." I've seen variations > on there as a draft editor and it's not always clear. In the past, > this has been an issue with ADs who have not engaged the WG. It helps > to have an explanation of the DISCUSS. Somewhat oversimplifying, I think you will find two types of DISCUSS in the tracker: 1. Problems that need fixing, are fairly easy to fix, and most people will agree on the fix once it is pointed out. These very often get fixed very quickly - quite possibly during the week between the document being placed on the IESG agenda and the time of the telechat - and cause little pain. 2. Problems whose validity and/or solution is contentious. Unless you want to remove the IESG's role as a back-stop, there is no painless way to resolve these. Somebody is going to have change their mind. I can only agree with those who say that open discussion is the best way to deal with these cases. It's the document shepherd, I think, who has to make sure that discussion happens ASAP. Brian ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Complaining about ADs to Nomcom (Re: Voting (again))
Jari, Jari Arkko wrote: I tend to agree with Leslie that it would be better to update the BCP. (I can volunteer to edit an update, if there are no other takers.) You may live to regret that statement :-) But I believe the update should simply allow the nomcom to publish this information. As has been stated before, a lot of this information is already around us, so many of the potential downsides would already be a problem, if they really would be problems. And given that we still prefer the nomcom to be in charge, I do not think that we will have a significant issue with electioneering. I hope that the nomcom does more than counts positive and negative inputs! In fact, it's remarkably easy to ignore a stream of very similar emails in praise of the same candidate. Of the arguments against publishing the list, the electioneering threat is the weakest, imho. As Leslie noted, apart from the unknown effect on the number of willing nominees, another tricky point is exactly when the list is published and how nominations after that date are handled. Brian --Jari Leslie Daigle wrote: Actually, I'm not sure I agree (that it's a good plan, or better to do it this way than update the BCP). When the NomCom WG was discussing this as part of creating RFC3777, I was initially a proponent of the "publish the candidate list!" perspective. I will admit to having been swayed by the arguments that it increases the likelihood of scaring off potential candidates, requires the freezing the candidate list, exposes the nomcom to second guessing, and inevitably provokes electioneering. Further, I also wonder what happens *after* the NomCom selections are done. I.e., how many people will not have complaints taken seriously because "they're just mad they were not selected". So, 1/ I'm not sure it's better to have a website that "interested people" can subscribe to at the cost of agreeing to maintain confidentiality than what we have today or going to a full open model. It has the chance of significantly increasing the "whisper group", and doesn't really solve any of the negatives listed above. 2/ If we want to change the model, we should update the BCP, and take the time to consciously re-evaluate the upsides and downsides we know to exist with closed or open candidate lists. If we (the IETF community) genuinely want more openness, we should do that, and get on with dealing with the negative sides we know will exist. Let's not just go halfway and get the worst of both models. Leslie. Brian E Carpenter wrote: Soliman, Hesham wrote: > At 01:10 PM 5/4/2005, Soliman, Hesham wrote: > > > One way to open up the process would be to allow any participant > > > to personally request a list of candidates from Nomcom, against > > > a personal non-disclosure promise. (Not my idea; this > was suggested > > > during last week's IESG retreat.) > > > >=> If we do that we may as well put the list on the web. > How do we define > >"participant"? > > There is a difference between having participants who are > interested in > providing feedback ask for a copy of the list, with a promise of > confidentiality, and give feedback - versus having that information > publicly available. This sounds useful to me. > > I don't think that "participant" really needs to be defined. > Those who > will be interested are those who are involved. Currently, > to obtain input > from a more diverse set of people, Nomcomm has to guess who > is appropriate > to ask & hope that a reasonable sampling of them will be > willing/interested > in responding. => Ok, since I think it will lead to the same effect (widely known nominees) I'm fine with that suggestion. Personally, I don't see the difference between doing what you describe above and sending the list of nominees to this mailing list. But either option is definitely better than what we have today IMHO. One difference is that we wouldn't have to update the BCP, since there would be no overt breach of confidentiality. So next year's NomCom could simply do this without further bureaucracy. I'm going to ask this year's Nomcom chair to see if this year's candidates can answer the question "would you have run if your name had been made public?" Brian ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Moving forward on IETF problems
[EMAIL PROTECTED] wrote: Brian, and others, I do have experience of WGs that care about DS. So do I. But this has not been the norm in my experience. If you think back to when we were discussing a one-stage standards track in newtrk, I at least was arguing for the importance of interoperability reports even in a one-stage system. The value in the DS label is surely the knowledge that an interop report has been presented and accepted. And that's why I conceded that I could live with a two-stage process (although I still think one stage plus interop reports would be just fine). Brian (speaking only for myself) ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Proper WG chairs (Re: Voting (again))
Dave Crocker wrote: But I would suspect that we aren't careful enough for Chair positions in being certain that the candidate has enough free time and full support from their employer. Not that it would guarantee anything, but it might be useful to have a candidate for working group chair formally agree to something in the style of a contract, mostly to make sure they read a list of requirements and expectations for the job. Such things as the average amount of time required could be included in the document. If we're after transparency, maybe this should simply be noted in the WG Charter. "The co-chairs have each agreed to provide approximately x% of their working time for this effort." Brian ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Complaining about ADs to Nomcom (Re: Voting (again))
Brian E Carpenter wrote: As Leslie noted (...) another tricky point is exactly when the list is published and how nominations after that date are handled. Agreed. If you make the publication at the end of the nominations period then its not useful as a tool for other potential candidates to decide if they want (or need!) to run for the position. But it seems complicated to publish the list several times. And if we are open about the list of candidates, we can't have nominations coming in after the last publication of the list. Its a tricky decision, but if it were up to me I'd probably just publish it once, at the end of the nominations period. --Jari ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: text suggested by ADs
On Sun, 8 May 2005, Margaret Wasserman wrote: (1) When an AD has an open discuss that he or she does not clear during the telechat, he or she could send a copy of that discuss to the WG mailing list directly. This is quite direct, but might be a bit tricky in practice due to spam filters, etc. because the AD may not be a member of the mailing list in question. It is also more likely to suffer from human error or omission, because the tracker is set-up to show us the documents for which we are responsible AD, not those for which we currently hold discusses. - or - (2) After the document appears on a telechat, the responsible AD could send any remaining IESG discusses and comments to the WG mailing list (probably in a single message), cc:ing the ADs who entered those discusses or comments. I sometimes do this already, and it typically seems to work well. [] Both of these are problematic, because they add more work to people on the IESG. I'd support the document shepherd (NOT either shepherding AD or the AD writing the discuss) being responsible for initiating the dialogue. If the comments by different ADs don't overlap, each AD's comments should be discussed separately. -- Pekka Savola "You each name yourselves king, yet the Netcore Oykingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
New root cause problems?
Having finally read the list traffic up to date, I have a question. Can anybody identify a *new* "root cause problem" at the same level of abstraction as those identified in RFC 3774? Or is it the case that (at that level of abstraction) we have only been re-discussing the RFC 3774 problem set? (Please try to be succinct... or change the subject header if you want to change the subject.) Thanks Brian ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Moving forward on IETF problems
> Date: 2005-05-10 07:44 > From: Brian E Carpenter <[EMAIL PROTECTED]> > The value in the DS label is surely the knowledge > that an interop report has been presented and accepted. The report is (or should be) mere mechanism for verifying the process which provides the true value -- elimination of unused provisions and ensuring full interoperability. > And that's > why I conceded that I could live with a two-stage process > (although I still think one stage plus interop reports would > be just fine). > > Brian (speaking only for myself) As I pointed out on NEWTRK, merely saying "feature X isn't widely supported" is very different from removal of feature X from the specification, particularly w.r.t. any latent security vulnerabilities in X. Beyond DS, there is additional value to full Standards, among other things in ensuring that widespread deployment doesn't interfere with other Internet operations. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: New root cause problems?
I have one new "root cause" issue that I don't believe was included in the original Problem Statement: It takes too long to publish an RFC after final approval. It currently takes several months for an RFC to be published after it is approved by the IESG. This results in several problems: - RFCs come out much later than they should, contributing greatly to the perception that the iETF is slow. The time to move from approved I-D to RFC is often a significant percentage (perhaps averaging 20% of more?) of the time required to develop and publish a specification. - Stable references are not available until months after a specification is fully approved, resulting in ambiguity about the status of a document and encouraging the use of I-D names as references, thus blurring the distinction between WG I-Ds and approved specifications. - Too many changes are made to documents after WG and IESG approval (copy editing, changes to reflect updated thinking/terminology, etc.). These changes are often not reviewed or approved by the WG or the community. - Some RFCs are already out-of-date by the time they are published. The document then contains the RFC publication date, which may result in a mistaken impression about when the IETF held a specific view or encouraged a particular practice. I believe that the IETF should consider modifications to our document handling process to reduce or eliminate the delay in publishing approved specifications. Margaret At 2:36 PM +0200 5/10/05, Brian E Carpenter wrote: Having finally read the list traffic up to date, I have a question. Can anybody identify a *new* "root cause problem" at the same level of abstraction as those identified in RFC 3774? Or is it the case that (at that level of abstraction) we have only been re-discussing the RFC 3774 problem set? (Please try to be succinct... or change the subject header if you want to change the subject.) Thanks Brian ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Complaining about ADs to Nomcom (Re: Voting (again))
Jari Arkko wrote: Brian E Carpenter wrote: As Leslie noted (...) another tricky point is exactly when the list is published and how nominations after that date are handled. Agreed. If you make the publication at the end of the nominations period then its not useful as a tool for other potential candidates to decide if they want (or need!) to run for the position. But it seems complicated to publish the list several times. And if we are open about the list of candidates, we can't have nominations coming in after the last publication of the list. Its a tricky decision, but if it were up to me I'd probably just publish it once, at the end of the nominations period. Actually, I think there is a slightly better way, somehow analagous to the 'petition period' used by the ISOC NomCom process. On day N, publish the list of willing nominees so far and invite further nominations before day N+14. On day N+28, publish the final list of willing nominees and invite feedback. This would, if we wanted to publish the names, give 2 weeks for extra nominations and another 2 weeks to check their willingness to serve. Brian ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Complaining about ADs to Nomcom (Re: Voting (again))
> On day N, publish the list of willing nominees so far and invite further > > nominations before day N+14. > > On day N+28, publish the final list of willing nominees and invite > feedback. > > This would, if we wanted to publish the names, give 2 weeks for extra > nominations and another 2 weeks to check their willingness to serve. seems pretty reasonable. d/ --- Dave Crocker Brandenburg InternetWorking +1.408.246.8253 dcrocker a t ... WE'VE MOVED to: www.bbiw.net ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: New root cause problems?
Adding to this - and I'm not sure this is the kind of thing you were looking for, but it adds to the overall problem - is that IDs timeout after 6 months (which is fine), but that includes IDs that are in the RFC-Editor queue process too. For example, look at the RFC-Editor queue site: http://www.rfc-editor.org/queue.html and try and look at a document that has a original submission date more than 6 months ago (from today)? The search link will fail, and this is a problem. Some of these are quite valuable (especially to their WGs), yet the IETF process eliminates their viewing. Solution: perhaps an exception to the 6 month timeout should be made for every document upon entry into the RFC-Editor's queue such that every document remains until the document has been published as an RFC (or won't be). At 09:36 AM 5/10/2005 -0400, Margaret Wasserman wrote: I have one new "root cause" issue that I don't believe was included in the original Problem Statement: It takes too long to publish an RFC after final approval. It currently takes several months for an RFC to be published after it is approved by the IESG. This results in several problems: - RFCs come out much later than they should, contributing greatly to the perception that the iETF is slow. The time to move from approved I-D to RFC is often a significant percentage (perhaps averaging 20% of more?) of the time required to develop and publish a specification. - Stable references are not available until months after a specification is fully approved, resulting in ambiguity about the status of a document and encouraging the use of I-D names as references, thus blurring the distinction between WG I-Ds and approved specifications. - Too many changes are made to documents after WG and IESG approval (copy editing, changes to reflect updated thinking/terminology, etc.). These changes are often not reviewed or approved by the WG or the community. - Some RFCs are already out-of-date by the time they are published. The document then contains the RFC publication date, which may result in a mistaken impression about when the IETF held a specific view or encouraged a particular practice. I believe that the IETF should consider modifications to our document handling process to reduce or eliminate the delay in publishing approved specifications. Margaret At 2:36 PM +0200 5/10/05, Brian E Carpenter wrote: Having finally read the list traffic up to date, I have a question. Can anybody identify a *new* "root cause problem" at the same level of abstraction as those identified in RFC 3774? Or is it the case that (at that level of abstraction) we have only been re-discussing the RFC 3774 problem set? (Please try to be succinct... or change the subject header if you want to change the subject.) Thanks Brian ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf cheers, James *** Truth is not to be argued... it is to be presented. Alas, few *truths* exist without the math. ...all else is a matter of perspective ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: New root cause problems?
> I have one new "root cause" issue that I don't believe was included > in the original Problem Statement: > It takes too long to publish an RFC after final approval. I agree with this. Over the last year especially, I'm seeing a significant number of cases where it is taking much more time to get an RFC published than seems justified. One example (and I'm just using it because it was it comes to mind, and one that I think is symptomatic of the broader problem): The DNSSEC bis document set (RFCs 4033-4035). October 15, 2004: IESG approves 4-document set. Within one week: authors send xml source to RFC editor March 10, 2005: IESG requests expedited processing (target date: March 31) March 29, 2005: RFCs published Total time between IESG approval and publication, 5 1/2 months. And to get to Margaret's other points, I agree that these delays damage the IETF. It contributes to the perception that we are too slow, causes additional confusion about a document's true status, etc. Implementors and other SDOs need access to the final RFCs in a timely fashion. Thomas ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: New root cause problems?
> The time to move from approved > > I-D to RFC is often a significant percentage (perhaps averaging 20% > of more?) of the time required to develop and publish a specification. Let's say that it averages 4 months to go from IESG approval to RFC publication. (I'm choosing that number because it is big enough to indicate a problem, but small enough not to insult the RFC Editor.) Using your estimate of 20% for this step, that means that working groups average 16 months to do their part of the work, from start to finish. However that does not match either general impression or that statistics that were produced awhile back. If we averaged 16 months for working groups to go from start to finish, we would not have serious and consistent complaints that the IETF is too slow. So the actual, incremental delay for the RFC publication process is probably no worse than 10% and I wouldn't be surprised if the real statistic were more like 5%. As much as it is worth trying to make everything better, it is difficult to see a 5 or 10% overhead to the process as being one of our strategic problems. d/ --- Dave Crocker Brandenburg InternetWorking +1.408.246.8253 dcrocker a t ... WE'VE MOVED to: www.bbiw.net ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: New root cause problems?
On 5/10/2005 12:45 PM, Thomas Narten wrote: > One example (and I'm just using it because it was it comes to mind, > and one that I think is symptomatic of the broader problem): > October 15, 2004: IESG approves 4-document set. > Within one week: authors send xml source to RFC editor > March 10, 2005: IESG requests expedited processing (target date: March 31) > March 29, 2005: RFCs published > > Total time between IESG approval and publication, 5 1/2 months. That was expedited. Better example is iSCSI. Draft-20 was approved Feb 2003 [http://www.ietf.org/IESG/Announcements/draft-ietf-ips-iscsi.ann] but published as RFC3720 in April 2004, for a lag time of 14 months. I have no knowledge of this process and maybe there were a lot of changes needed or something, but for a whole year there were vendors releasing products marketed as conformant with "draft 20" -- Eric A. Hallhttp://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/ ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: New root cause problems?
At 12:45 PM 5/10/2005 -0400, Thomas Narten wrote: Total time between IESG approval and publication, 5 1/2 months. And to get to Margaret's other points, I agree that these delays damage the IETF. It contributes to the perception that we are too slow, causes additional confusion about a document's true status, etc. Implementors and other SDOs need access to the final RFCs in a timely fashion. so do customers who feel an ID isn't sufficiently stable to specify as a customer requirement (for an RFP, for example) I have already had a customer get so frustrated with the IETF process they wrote an extension themselves into H.323 and got it ratified in 9 months (H.460.14) and our effort (that was first presented at the Adelaide meeting) just went to the IESG for review 5 years and 2 months later. Thomas ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf cheers, James *** Truth is not to be argued... it is to be presented. Alas, few *truths* exist without the math. ...all else is a matter of perspective ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: New root cause problems?
In message <[EMAIL PROTECTED]>, "Eric A. Hall" writes: > >On 5/10/2005 12:45 PM, Thomas Narten wrote: > >> One example (and I'm just using it because it was it comes to mind, >> and one that I think is symptomatic of the broader problem): > >> October 15, 2004: IESG approves 4-document set. >> Within one week: authors send xml source to RFC editor >> March 10, 2005: IESG requests expedited processing (target date: March 31) >> March 29, 2005: RFCs published >> >> Total time between IESG approval and publication, 5 1/2 months. > >That was expedited. Better example is iSCSI. Draft-20 was approved Feb >2003 [http://www.ietf.org/IESG/Announcements/draft-ietf-ips-iscsi.ann] but >published as RFC3720 in April 2004, for a lag time of 14 months. > >I have no knowledge of this process and maybe there were a lot of changes >needed or something, but for a whole year there were vendors releasing >products marketed as conformant with "draft 20" > A delay of that length is generally due to dependencies -- normative references to other documents that are held up. When a document is in the RFC Editor queue, you can query its state via their web site. --Prof. Steven M. Bellovin, http://www.cs.columbia.edu/~smb ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: New root cause problems?
"Eric A. Hall" <[EMAIL PROTECTED]> writes: > On 5/10/2005 12:45 PM, Thomas Narten wrote: > > One example (and I'm just using it because it was it comes to mind, > > and one that I think is symptomatic of the broader problem): > > October 15, 2004: IESG approves 4-document set. > > Within one week: authors send xml source to RFC editor > > March 10, 2005: IESG requests expedited processing (target date: March 31) > > March 29, 2005: RFCs published > > > > Total time between IESG approval and publication, 5 1/2 months. For the record, I cited this one because as AD shepherd for this one, I am certain there were no normative dependencies, the IANA work was relatively minor (no new allocations where made), the authors didn't ask for massive changes during 48 hours, and I know there was frustration/puzzlement from the editors directed at me while we waited for the document to pop out. More generally, there are a number of reasons why documents get hung up after IESG approval. They include: 1) normative references to IDs that are not also in the queue. Unfortunately, there are too many cases of this, and IMO, the IESG (and WGs) should really not be approving such documents. Too often, once they are in the RFC queue, people forget about the normative depedencies which may themselves be stalled. As AD, I saw this _many_ times. :-( 2) IANA considerations. IANA needs to do its part before an RFC can be published. IANA delays have also stretched into multiple months at times. 3) Additional "changes" requested by the WG and or authors. I know of several cases where WGs/authors submitted extremely large sets of "editorial changes" during 48 hours. Because all those changes need to be vetted appropriately, this can set back documents a long time. E.g, the l2tpv3 base spec ended up going back to the WG for review of all 250+ changes... 4) And of course the RFC editor processing itself. > That was expedited. Better example is iSCSI. Draft-20 was approved Feb > 2003 [http://www.ietf.org/IESG/Announcements/draft-ietf-ips-iscsi.ann] but > published as RFC3720 in April 2004, for a lag time of 14 months. In the case of this document, one or more normative references accounts for part of the problem. Here is the history, as indicated by the RFC Editor's queue: draft-ietf-ips-iscsi 20030212 category WORKING GROUP STANDARDS TRACK (by date received) draft-ietf-ips-iscsi 20030212 current status EDIT draft-ietf-ips-iscsi 20030212 entered queue at 2003/02/11 (1 days in unknown state) draft-ietf-ips-iscsi 20030212 is version 20 draft-ietf-ips-iscsi 20030503 entered status IANA draft-ietf-ips-iscsi 20030503 was in EDIT since 20030212 (80 days) draft-ietf-ips-iscsi 20030506 entered status RFC-EDITOR draft-ietf-ips-iscsi 20030506 was in IANA since 20030503 (3 days) draft-ietf-ips-iscsi 20030619 entered status REF draft-ietf-ips-iscsi 20030619 was in RFC-EDITOR since 20030506 (44 days) draft-ietf-ips-iscsi 20040120 entered status RFC-EDITOR draft-ietf-ips-iscsi 20040120 was in REF since 20030619 (215 days) draft-ietf-ips-iscsi 20040323 entered status AUTH48 draft-ietf-ips-iscsi 20040323 was in RFC-EDITOR since 20040120 (63 days) draft-ietf-ips-iscsi 20040421 entered status AUTH draft-ietf-ips-iscsi 20040421 was in AUTH48 since 20040323 (29 days) draft-ietf-ips-iscsi 20040429 no longer in queue draft-ietf-ips-iscsi 20040429 was in AUTH since 20040421 (8 days) draft-ietf-ips-iscsi 20040429 was in queue since 20030212 (442 days) >From the above, one can see that the REF issue added 215 days. But that accounts for only about 1/2 of the total time. Plenty of other delays there. Thomas ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Complaining about ADs to Nomcom (Re: Voting (again))
Seems resonable to of as well. The good thing about mobile email is that t9 forces you to be brief. --- original message --- Subject:Re: Complaining about ADs to Nomcom (Re: Voting (again)) Sender: Dave Crocker <[EMAIL PROTECTED]> Date: 05/10/2005 5:27 pm > On day N, publish the list of willing nominees so far and invite further > > nominations before day N+14. > > On day N+28, publish the final list of willing nominees and invite > feedback. > > This would, if we wanted to publish the names, give 2 weeks for extra > nominations and another 2 weeks to check their willingness to serve. seems pretty reasonable. d/ --- Dave Crocker Brandenburg InternetWorking +1.408.246.8253 dcrocker a t ... WE'VE MOVED to: www.bbiw.net ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Complaining about ADs to Nomcom (Re: Voting (again))
Brian E Carpenter wrote: Actually, I think there is a slightly better way, somehow analagous to the 'petition period' used by the ISOC NomCom process. On day N, publish the list of willing nominees so far and invite further nominations before day N+14. On day N+28, publish the final list of willing nominees and invite feedback. This would, if we wanted to publish the names, give 2 weeks for extra nominations and another 2 weeks to check their willingness to serve. Ok. --Jari ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Complaining about ADs to Nomcom (Re: Voting (again))
Brian, This works for me, too. FWIW. Actually, I think there is a slightly better way, somehow analagous to the 'petition period' used by the ISOC NomCom process. On day N, publish the list of willing nominees so far and invite further nominations before day N+14. On day N+28, publish the final list of willing nominees and invite feedback. This would, if we wanted to publish the names, give 2 weeks for extra nominations and another 2 weeks to check their willingness to serve. Brian ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: improving WG operation
On Tue, 10 May 2005, Tom Lord wrote: > > > But if you aren't interested, why are you here? What's your interest? I > > don't understand your point. Are you here to convince the rest of us that > > the IETF is irrelevant? > > Absolutely not. Nearly the opposite. I hope that if you look back at > some of my other messages in this thread that's clear. > > >> You're complaining that some application-layer stuff like IM > >> isn't as orderly as you'd like. > > > Disorder isn't good for the users, either. Its not just a personal > > view of orderliness. And it isn't good for the market to have such > > unnecessary and gratuitous disorder. That's why standards of any > > form exist. > > I'm not so sure IETF can help user's other than by producing very > good, easily accessed documents with available reference > implementations. The IETF doesn't produce documents that are meant to be accessible to users. Nor does it produce reference implementations. IETF documents are meant to be accessible to engineers and operators, creating and running interoperable services of various types. One and possibly two implementations are usually required for a standard to be acceptable. The point of this is to require that specifications be both implementable and complete. > An endorsement/trust-based system for calling attention to good > standards seems like all you've ultimately got -- why not > institutionalize *that*? The trust-based system we have has a track record of obtaining good specifications. We have institutionalized that, vaguely though it might be. This doesn't mean this process can't be improved, nor that it shouldn't be critically examined. But I don't see that this has anything to do with calling attention to good standards. The IETF has no marketing or promotion department to call attention to anything it does. It is all through word of mouth and the interaction with participants. I don't think such a department is necessary. > Why *isn't* the rest of the governance simply noise? Why *isn't* the > rest of the governance simply a game a professional organization has > agreed to play that will ultimately turn it into just another > consortium? Isn't the rule-mongering just a very indirect attempt to > find rules that coincidentally create the effects an endorsement/trust > system would render in a more naked form? What's the "value add" of > anything beyond an endorsement/trust system? My answers to those > questions are clear and that's why I say: strike while the iron is hot > -- while there are still recognizable names who roughly essentially > deserve trust? I'd offer one point: Name recognition has nothing to do with trust. In the past few years, we've seen some very recognizable and previously highly trusted names turn out to be untrustworthy in a number fields, endeavors, and organizations. Whether someone is still trustworthy is also something that needs to be critically examined now and again. An organization's trust assets only remain assets if they remain trustworthy. Trusted staff isn't the only thing going for the IETF, but it is a critical component. But untrustworthy staff can be replaced without damage so long as they are replaced promptly. It is usually delay in replacement of trusted staff that creates the most damage for organizations that depend on trust. So far as "striking while the iron is hot", well, "urgency" is usually and historically a sign of weak technical arguments that won't hold up to careful and critical scrutiny. There is nothing here that needs attention so urgently we can't analyze the problem and the proposed solutions. So far as I am aware, in _every_ case where "urgency" was cited as a reason for foregoing analysis, it has been found both that there wasn't any urgency, and that the proposal was seriously flawed. --Dean -- Av8 Internet Prepared to pay a premium for better service? www.av8.net faster, more reliable, better service 617 344 9000 ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: New root cause problems?
Hi Dave, My impressions are, of course, based upon my own experiences... I checked the time spent in the "In RFC Editor Queue" state for the last 10 RFCs that have been published from my I-D Tracker queue, and the details are included below. According to my numbers, these ten documents spent a combined total of 201 months in the IETF process after -00 publication, which typically approximates when the WG accepted the work item (about 20 months per document). These documents spent a combined total of 50 months in the "In RFC Editor Queue" state (an average of 5 months per document) or just about 25% of the total time from WG acceptance to document publication. Therefore, given my own experience, I will stand by my impression that about 25% of the IETF's processing time for a given document is being spent in the RFC Editor Queue. This number may not capture the full extent of the issue, as my longest-standing documents in the "In RFC editor Queue" state haven't had a chance to emerge yet. I've only been an AD for about 22 months, and I am responsible for 11 documents that have been in the RFC Editor Queue for over 6 months, including 2 that have been in the RFC Editor Queue for over a year. Please note that I do understand that not all of the time spent in the "In RFC Editor Queue" state can be attributed to the RFC Editor, any more than all of the time spent "in the IESG" can be attributed to the IESG. Some of this time is spent waiting to resolve references, waiting for author feedback on IANA issues, waiting for author response to AUTH48, etc. However, I do believe that far too much time is being spent during the "In RFC Editor Queue" phase of the process. This phase of the process is too opaque for me to identify the specific reasons why this is taking so long, but I strongly believe that we need more visibilityy into this part of the process and that we need to apply our efforts to making this period shorter. Margaret draft-carpenter-obsolete-1888: (TOTAL TIME: 8 months) In RFC Editor Q: 2004-11-02 to 2005-04-26 (5-1/2 months) -00 Published: August 2004 draft-ietf-dhc-agentopt-radius: (TOTAL TIME: 36-1/2 months) In RFC Editor Q: 2004-09-27 to 2005-02-24 (5 months) -00 Published: 2002-02-14 draft-ietf-dhc-auth-suboption: (TOTAL TIME: 33-1/2 months) In RFC Editor Q: 2004-09-21 to 2005-04-06 (6-1/2 months) -00 Published: 2002-06-23 draft-ietf-dhc-dhcpv6-opt-nisconfig: (TOTAL TIME: 32 months) In RFC Editor Q: 2004-06-02 to 2004-10-12 (4-1/2 months) -00 Published: 2002-02-17 draft-ietf-dhc-rapid-commit-opt: (TOTAL TIME: 16 months) In RFC Editor Q: 2004-11-02 to 2005-04-06 (5 months) -00 Published: 2003-11-28 draft-ietf-dhc-reclassify-options: (TOTAL TIME: 11 months) In RFC Editor Q: 2004-07-12 to 2004-12-03 (4-1/2 months) -00 Published: 2004-01-05 draft-ietf-dhc-subscriber-id: (TOTAL TIME: 20 months) In RFC Editor Q: 2004-09-16 to 2005-03-22 (6 months) -00 Published: July 2003 draft-ietf-dhc-vendor: (TOTAL TIME: 14 months) In RFC Editor Q: 2004-07-12 to 2004-11-04 (4 months) -00 Published: September 2003 draft-ietf-eap-rfc2284bis: (TOTAL TIME: 17 months) In RFC Editor Q: 2004-02-29 to 2004-06-22 (4 months) -00 Published: January 2003 draft-ietf-ipv6-deprecate-site-local: (TOTAL TIME: 13 months) In RFC Editor Q: 2004-04-16 to 2004-09-21 (5 months) -00 Published: 2003-08-16 At 10:01 AM -0700 5/10/05, Dave Crocker wrote: The time to move from approved I-D to RFC is often a significant percentage (perhaps averaging 20% of more?) of the time required to develop and publish a specification. Let's say that it averages 4 months to go from IESG approval to RFC publication. (I'm choosing that number because it is big enough to indicate a problem, but small enough not to insult the RFC Editor.) Using your estimate of 20% for this step, that means that working groups average 16 months to do their part of the work, from start to finish. However that does not match either general impression or that statistics that were produced awhile back. If we averaged 16 months for working groups to go from start to finish, we would not have serious and consistent complaints that the IETF is too slow. So the actual, incremental delay for the RFC publication process is probably no worse than 10% and I wouldn't be surprised if the real statistic were more like 5%. As much as it is worth trying to make everything better, it is difficult to see a 5 or 10% overhead to the process as being one of our strategic problems. d/ --- Dave Crocker Brandenburg InternetWorking +1.408.246.8253 dcrocker a t ... WE'VE MOVED to: www.bbiw.net ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: text suggested by ADs
On 5/9/05, Lars-Erik Jonsson (LU/EAB) <[EMAIL PROTECTED]> wrote: > More direct communication with > individual ADs (especially ADs from other areas who do have > comments on what a WG has produced) would hopefully also reduce > the number of myths about IESG/AD operations. Indeed. Of course, the idea of having someone in the middle is really that they will *facilitate* the discussion, so maybe we can find a way to keep both aspects - direct communication and facilitation. On 5/9/05, John Loughney <[EMAIL PROTECTED]> wrote: > When is a DISCUSS not a discuss? When it is a "You have to fix this and I'm > holding a DISCUSS until it's fixed." I've seen variations on there as a draft > editor and it's not always clear. Well, for things like "This misuses MIME in a way that will cause problems in the future" or "This type of security has known flaws and it would be better to go this other way", yes, it tends to be "fix this, period." These are the "backstop" issues that Brian mentioned (that the IESG would rather get out of the business of catching). >It helps to have an explanation of the DISCUSS. Certainly. In theory, a DISCUSS without an explanation is not valid, and I think the IESG has worked hard in the last couple of years to provide actual reasons for DISCUSSes. As you may know from a few IETF plenaries, I've been collecting various bits of data; of the 475 DISCUSS evaluations in my database (which, it turns out, includes some that have been resolved; I have to update my data collection methodology), only one has no text associated with it, and that one is one of the ones associated with the buggy methodology, i.e., has been resolved. (Of course, my database has no idea if the text that's there is relevant or useful, but at least we're above the lowest hurdle) Bill ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: improving WG operation
On 22:45 10/05/2005, Dean Anderson said: The IETF doesn't produce documents that are meant to be accessible to users. Nor does it produce reference implementations. IETF documents are meant to be accessible to engineers and operators, creating and running interoperable services of various types. One and possibly two implementations are usually required for a standard to be acceptable. The point of this is to require that specifications be both implementable and complete. Dean, the IETF users are the ones who use the IETF deliverables. And the Internet is made of the adherence to these deliverable (which do not make the best documentation around). So, you cannot know or decide who will be the users. (may be you refer in your mind to "end users"? There are none on the Internet because it is not a centralised network. Just remember that Internet users have designed P2P, VoIP, NATs, etc. for some and that others have more processing and communication powers than the whole AT&T 20 years ago) and you never know who will need what (even if 99.99% will never read an RFC, they will all read RFC quotes and they must be clear and consistent with what their consultant, their ISP, their operator will tell them). What I mean is there is no Internet "gnosis", there should only be an Internet "gospel". There is no shame in it, but the IETF mechanic seems to be more: - a user comes with a working project - IETF starts maintaining it and documenting it what helps its integration and scalability - if the whole common thing is accepted and works it can become a standard. jfc ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Complaining about ADs to Nomcom (Re: Voting (again))
Sorry for late response. > Let me follow this up a bit. > > I've been encouraging people to try to sort through reasons and > things that would make it different on another thread, but I > think we have a "choice of potential candidates" problem today. > The IESG and IAB received "very few real choices" reports from > several nomcoms while I was serving there. Possibly things have > gotten better, but I have my doubts. => I would challenge this assumption. From what I've seen (I saw the list of some of the nominees lately) I don't think we have a shortage. Of course shortage of quality is a matter of personal opinion. But the numbers are there I think. > > Whatever the reasons, we don't seem to have enough plausible > candidates to provide reasonable turnover on the IESG (which, > personally, I think would be healthy). => I agree with the turnover point. > > Even assuming that publishing candidate lists would result in > better-quality feedback and permit the Nomcom to make better > choices among plausibly-appropriate candidates, please look at > the other side. There are people in the community who, for > whatever reassons, find the prospect of a "volunteer, have that > public, and then not be selected" process sufficiently painful > to prevent them from volunteering... => With all due respect to those people, I think it's a shame they feel like that. It seems like the selection decision is perceived as a personal judgement by those people. Good people may not get selected for a million reasons. I hate making blanket judgements but this kind of attitude is probably not a healthy attitude for an AD-to-be. or certainly from > volunteering more than once or twice. There are also subtle > differences in how one can volunteer that can be expressed in > confidence to the Nomcom: "I don't really want to do this, but > will serve if you conclude that it is important and I'm the best > choice" or "I can't work with X and would accept the position > only if X were not selected" are comments that can be made > today, but which don't show up on public lists. I believe that > many of the people who would semi-volunteer with such conditions > would decline to volunteer at all if their names would go on an > undifferentiated public list. => Hmm. I guess the choice we need to make is whether we should design the process to please some of the potential nominees or to advance the community through openness and wide and diverse feedback. The way we have it now, "key people" are seen as the people that the nomcom should use to make their decisions. How "key people" only can be trusted to make this decision is beyond me. In essense, we're assuming that good technical people are good managers and good judges of personalities and personal skills of nominees. This is a dangerous assumption IMO and doesn't take into account that people have diverse skills. Effectively, the process assumes that there are "good people" (good at everything) and "average people" (average at everything). And of course "good people" can also recommend that the nomcom considers other "good people's" opinions about nominees. Can you see where this is going? It can work for a small community but I doubt it would for a community this size. BTW, I'm not someone who was harmed by this process, on the contrary. but I still don't trust it. Hesham > > So, those of you who strongly advocate a public list... What > percentage of the already-too-small potential candidate pool are > you willing to lose? Are you convinced that anyone with > sensitivities or conditions similar to those outlined above > would make a bad AD if selected? Do you think the tradeoffs > are worth it? > > john > > === This email may contain confidential and privileged material for the sole use of the intended recipient. Any review or distribution by others is strictly prohibited. If you are not the intended recipient please contact the sender and delete all copies. === ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: New root cause problems?
> Date: 2005-05-10 13:01 > From: Dave Crocker <[EMAIL PROTECTED]> > Let's say that it averages 4 months to go from IESG approval to RFC > publication. (I'm choosing that number because it is big enough to indicate > a > problem, but small enough not to insult the RFC Editor.) > > Using your estimate of 20% for this step, that means that working groups > average 16 months to do their part of the work, from start to finish. > > However that does not match either general impression or that statistics that > were produced awhile back. > > If we averaged 16 months for working groups to go from start to finish, > we would not have serious and consistent complaints that the IETF is too > slow. OK, I'll bite -- where are the statistics (I know of one WG that has been active for more than 8 years and has set to produce a single document for IESG review; that's got to skew the statistics a bit)? ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: New root cause problems?
On 5/10/05, James M. Polk <[EMAIL PROTECTED]> wrote: > Adding to this - and I'm not sure this is the kind of thing you were > looking for, but it adds to the overall problem - is that IDs timeout after > 6 months (which is fine), but that includes IDs that are in the RFC-Editor > queue process too. I believe it only includes IDs that are independent submissions to the RFC Editor and have not yet been sent to the IESG for its conflict check. mysql> select all_id.status, rfcq.category, count(all_id.status) from rfcq, all_id where all_id.docname = rfcq.docname group by all_id.status, rfcq.category; +---+-+--+ | status| category | count(all_id.status) | +---+-+--+ | active| INDEPENDENT SUBMISSIONS UNDER RFC EDITOR REVIEW (by date received) |7 | | expired | INDEPENDENT SUBMISSIONS UNDER RFC EDITOR REVIEW (by date received) | 18 | | rfc | IAB DOCUMENTS (by date received) |1 | | rfc | NON-WORKING GROUP INFORMATIONAL/EXPERIMENTAL/BCP (by date received) | 25 | | rfc | NON-WORKING GROUP STANDARDS TRACK (by date received) | 10 | | rfc | WORKING GROUP INFORMATIONAL/EXPERIMENTAL/BCP (by date received) | 24 | | rfc | WORKING GROUP STANDARDS TRACK (by date received) | 56 | | withdrawn | NON-WORKING GROUP INFORMATIONAL/EXPERIMENTAL/BCP (by date received) |1 | | iesg | IAB DOCUMENTS (by date received) |1 | | iesg | INDEPENDENT SUBMISSIONS UNDER RFC EDITOR REVIEW (by date received) | 12 | | iesg | NON-WORKING GROUP INFORMATIONAL/EXPERIMENTAL/BCP (by date received) | 21 | | iesg | NON-WORKING GROUP STANDARDS TRACK (by date received) |2 | | iesg | WORKING GROUP INFORMATIONAL/EXPERIMENTAL/BCP (by date received) | 47 | | iesg | WORKING GROUP STANDARDS TRACK (by date received) | 61 | +---+-+--+ 14 rows in set (0.04 sec) Forgive the too-wide presentation; but as you can see, all 18 expired documents are in the Independent Submissions category. (The status "rfc" documents are because the rfcq database doesn't age out old entries.) The oldest document in each category: mysql> select min(all_id.lastup) as "Updated", rfcq.category from rfcq, all_id where all_id.docname = rfcq.docname and all_id.status != 'rfc' group by rfcq.category; ++-+ | Updated| category | ++-+ | 2004-10-22 | IAB DOCUMENTS (by date received) | | 2003-07-01 | INDEPENDENT SUBMISSIONS UNDER RFC EDITOR REVIEW (by date received) | | 2001-07-24 | NON-WORKING GROUP INFORMATIONAL/EXPERIMENTAL/BCP (by date received) | | 2004-10-01 | NON-WORKING GROUP STANDARDS TRACK (by date received) | | 2002-10-11 | WORKING GROUP INFORMATIONAL/EXPERIMENTAL/BCP (by date received) | | 2002-09-11 | WORKING GROUP STANDARDS TRACK (by date received) | ++-+ 6 rows in set (0.03 sec) so clearly, given that there are I-Ds in the queue that were last updated in 2001 and 2002, the 6 months expiration is not a universal concern for documents in the RFC Editor's queue. [These databases are available from https://rtg.ietf.org/phpmyadmin/ ; login ietf password ietf] Bill ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: New root cause problems?
Argh, I should have known better than to hope that gmail wouldn't munch the tables. The category/status table is: mysql> select all_id.status, substring(rfcq.category, 1, 40) as "Category", count(all_id.status) as "Num" from rfcq, all_id where all_id.docname = rfcq.docname group by all_id.status, rfcq.category; +---+--+-+ | status| Category | Num | +---+--+-+ | active| INDEPENDENT SUBMISSIONS UNDER RFC EDITOR | 7 | | expired | INDEPENDENT SUBMISSIONS UNDER RFC EDITOR | 18 | | rfc | IAB DOCUMENTS (by date received) | 1 | | rfc | NON-WORKING GROUP INFORMATIONAL/EXPERIME | 25 | | rfc | NON-WORKING GROUP STANDARDS TRACK (by da | 10 | | rfc | WORKING GROUP INFORMATIONAL/EXPERIMENTAL | 24 | | rfc | WORKING GROUP STANDARDS TRACK (by date r | 56 | | withdrawn | NON-WORKING GROUP INFORMATIONAL/EXPERIME | 1 | | iesg | IAB DOCUMENTS (by date received) | 1 | | iesg | INDEPENDENT SUBMISSIONS UNDER RFC EDITOR | 12 | | iesg | NON-WORKING GROUP INFORMATIONAL/EXPERIME | 21 | | iesg | NON-WORKING GROUP STANDARDS TRACK (by da | 2 | | iesg | WORKING GROUP INFORMATIONAL/EXPERIMENTAL | 47 | | iesg | WORKING GROUP STANDARDS TRACK (by date r | 61 | +---+--+-+ 14 rows in set (0.05 sec) and the date table is: mysql> select min(all_id.lastup) as "Updated", substring(rfcq.category, 1, 50) as "Category" from rfcq, all_id where all_id.docname = rfcq.docname and all_id.status != 'rfc' group by rfcq.category; +++ | Updated| Category | +++ | 2004-10-22 | IAB DOCUMENTS (by date received) | | 2003-07-01 | INDEPENDENT SUBMISSIONS UNDER RFC EDITOR REVIEW ( | | 2001-07-24 | NON-WORKING GROUP INFORMATIONAL/EXPERIMENTAL/BCP ( | | 2004-10-01 | NON-WORKING GROUP STANDARDS TRACK (by date receive | | 2002-10-11 | WORKING GROUP INFORMATIONAL/EXPERIMENTAL/BCP (by d | | 2002-09-11 | WORKING GROUP STANDARDS TRACK (by date received) | +++ 6 rows in set (0.04 sec) Bill ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: improving WG operation
> Just remember that Internet users have designed P2P, VoIP, > NATs, etc. for > some and that others have more processing and communication > powers than the > whole AT&T 20 years ago) and you never know who will need > what (even if > 99.99% will never read an RFC, they will all read RFC quotes > and they must > be clear and consistent with what their consultant, their ISP, their > operator will tell them). What I mean is there is no Internet > "gnosis", > there should only be an Internet "gospel". Exactly, do I have to send an engineer to every IETF WG meeting just to make sure that they don't decide to delete some feature of some protocol that I am depending on? ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: improving WG operation
On 01:50 11/05/2005, Hallam-Baker, Phillip said: > Just remember that Internet users have designed P2P, VoIP, > NATs, etc. for > some and that others have more processing and communication > powers than the > whole AT&T 20 years ago) and you never know who will need > what (even if > 99.99% will never read an RFC, they will all read RFC quotes > and they must > be clear and consistent with what their consultant, their ISP, their > operator will tell them). What I mean is there is no Internet > "gnosis", > there should only be an Internet "gospel". Exactly, do I have to send an engineer to every IETF WG meeting just to make sure that they don't decide to delete some feature of some protocol that I am depending on? They do not not only delete. I suggest you just come to the WG-ltru where they have decided to document RFC 2277 charsets into RFC 3066 langtags. So you can enjoy charset conflicts, something you never though about, I presume. You cannot stop progress. jfc ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: improving WG operation
From: Dean Anderson <[EMAIL PROTECTED]> > I'm not so sure IETF can help user's other than by producing very > good, easily accessed documents with available reference > implementations. The IETF doesn't produce documents that are meant to be accessible to users. Nor does it produce reference implementations. IETF documents are meant to be accessible to engineers and operators, creating and running interoperable services of various types. (a) please don't be so classist. (b) please don't put words in my mouth, even by implication of your reply. Thanks, -t p.s.: > Why *isn't* the rest of the governance simply noise? Why *isn't* the > rest of the governance simply a game a professional organization has > agreed to play that will ultimately turn it into just another > consortium? Isn't the rule-mongering just a very indirect attempt to > find rules that coincidentally create the effects an endorsement/trust > system would render in a more naked form? What's the "value add" of > anything beyond an endorsement/trust system? My answers to those > questions are clear and that's why I say: strike while the iron is hot > -- while there are still recognizable names who roughly essentially > deserve trust? I'd offer one point: Name recognition has nothing to do with trust. Right. Trust has only a role in drawing attention. People still have to think for themselves. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: improving WG operation
Hi - > From: "JFC (Jefsey) Morfin" <[EMAIL PROTECTED]> > To: "Hallam-Baker, Phillip" <[EMAIL PROTECTED]> > Cc: > Sent: Tuesday, May 10, 2005 5:29 PM > Subject: RE: improving WG operation ... > They do not not only delete. I suggest you just come to the WG-ltru where > they have decided to document RFC 2277 charsets into RFC 3066 langtags. So > you can enjoy charset conflicts, something you never though about, I > presume. You cannot stop progress. ... I guess Jefsey is upset because the WG rejected his proposal to expand our scope to include charsets. The ltru WG is most emphatically *not* confusing charsets with language tags. Randy, ltru co-chair ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
a way toward homograph resolution ? (was "improving WG operation")
On 04:43 11/05/2005, Randy Presuhn said: From: "JFC (Jefsey) Morfin" <[EMAIL PROTECTED]> > To: "Hallam-Baker, Phillip" <[EMAIL PROTECTED]> > Cc: > Sent: Tuesday, May 10, 2005 5:29 PM > Subject: RE: improving WG operation ... > They do not not only delete. I suggest you just come to the WG-ltru where > they have decided to document RFC 2277 charsets into RFC 3066 langtags. So > you can enjoy charset conflicts, something you never though about, I > presume. You cannot stop progress. ... I guess Jefsey is upset because the WG rejected his proposal to expand our scope to include charsets. The ltru WG is most emphatically *not* confusing charsets with language tags. I am not upset :-). To the countrary I find extremely interesting that some people were able to rename charsets "scripts" in order to insert charsets into languages descriptions while claiming they dont (cf. above). Obviously they are unhappy when I expose the trick. Anyway the result is great fun: people will be prevented from accessing a page they know to read, if they do not know the language. This cacologic however might be a good way to solve the IDN homograph issue and the phishing problem. If we revert from those famous "scripts" to what they are, i.e. unicode partitions, hence stable and well documented charsets (http://www.unicode.org/Public/4.1.0/ucd/Scripts.txt) , using them browsers can expose the homographs not related to the page charset in IDNs, and kill the risks of phishing. This only calls for the browsers to extract the charset, I mean the script name from the langtag, call this file, read the list of codes points in the charset/associated to the script, and display the URL accordingly, indicating the characters which are no part of the script/charset. This relieves the ccTLD/TLD Manager from responsibilities he cannot fulfil at 3+level. There are howver still (minor) points to address: - there are some minor disparities between the "script" name in the langtag, and the script name in the script.txt file should be reduced over time. I suppose that if this is a major issue, there will be help. - the script.txt file is currently supported on the Unicode site. Even in caching it (92 K) it will be called everytime people will start their browser. This may therefore represent several billions of access a day. - the WG-ltru only realy wants to address XML issues, related to old XML libraries. Some coordination with other WGs or interests could be fruitful. They plan the language tags registry to extend to scripts and to register them. I suppose other WGs could benefit from this (all those involved in a way or another with internationalisation and languages). jfc ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: a way toward homograph resolution ?
Hi - Let it suffice for me to say that I believe the gentleman is mistaken. I do not intend to waste additional bandwidth on this thread. Those interested in ltru and its work will find our charter at http://www.ietf.org/html.charters/ltru-charter.html and our archives at http://www.ietf.org/mail-archive/web/ltru/index.html Randy, ltru co-chair - Original Message - > From: "JFC (Jefsey) Morfin" <[EMAIL PROTECTED]> > To: > Cc: > Sent: Tuesday, May 10, 2005 9:08 PM > Subject: a way toward homograph resolution ? (was "improving WG operation") > > On 04:43 11/05/2005, Randy Presuhn said: > >From: "JFC (Jefsey) Morfin" <[EMAIL PROTECTED]> > > > To: "Hallam-Baker, Phillip" <[EMAIL PROTECTED]> > > > Cc: > > > Sent: Tuesday, May 10, 2005 5:29 PM > > > Subject: RE: improving WG operation > >... > > > They do not not only delete. I suggest you just come to the WG-ltru where > > > they have decided to document RFC 2277 charsets into RFC 3066 langtags. So > > > you can enjoy charset conflicts, something you never though about, I > > > presume. You cannot stop progress. > >... > > > >I guess Jefsey is upset because the WG rejected his proposal > >to expand our scope to include charsets. The ltru WG is most > >emphatically *not* confusing charsets with language tags. > > I am not upset :-). To the countrary I find extremely interesting that some > people were able to rename charsets "scripts" in order to insert charsets > into languages descriptions while claiming they dont (cf. above). Obviously > they are unhappy when I expose the trick. Anyway the result is great fun: > people will be prevented from accessing a page they know to read, if they > do not know the language. > > > This cacologic however might be a good way to solve the IDN homograph issue > and the phishing problem. > > If we revert from those famous "scripts" to what they are, i.e. unicode > partitions, hence stable and well documented charsets > (http://www.unicode.org/Public/4.1.0/ucd/Scripts.txt) , using them browsers > can expose the homographs not related to the page charset in IDNs, and kill > the risks of phishing. > > This only calls for the browsers to extract the charset, I mean the script > name from the langtag, call this file, read the list of codes points in the > charset/associated to the script, and display the URL accordingly, > indicating the characters which are no part of the script/charset. This > relieves the ccTLD/TLD Manager from responsibilities he cannot fulfil at > 3+level. > > There are howver still (minor) points to address: > - there are some minor disparities between the "script" name in the > langtag, and the script name in the script.txt file should be reduced over > time. I suppose that if this is a major issue, there will be help. > - the script.txt file is currently supported on the Unicode site. Even in > caching it (92 K) it will be called everytime people will start their > browser. This may therefore represent several billions of access a day. > - the WG-ltru only realy wants to address XML issues, related to old XML > libraries. Some coordination with other WGs or interests could be fruitful. > They plan the language tags registry to extend to scripts and to register > them. I suppose other WGs could benefit from this (all those involved in a > way or another with internationalisation and languages). > > jfc > > > > > > > ___ > Ietf mailing list > Ietf@ietf.org > https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
