[EMAIL PROTECTED] Guerilla Party Events for Wednesday
[EMAIL PROTECTED] Guerilla Party Events for Wednesday **Euro Sticker Day** Euro stickers are those lovely country labels you see on autos whilst visiting our European friends as opposed to the rectangular car art we have in the States slamming or promoting a political candidate of choice. W 04 anyone? Today, you can join IETF Country with your very own Euro-style sticker that says: IETF, Internet Engineering Task Force, 20 years of rough consensus and running code. Wondering what to do about that little dent on your car? Now you have the answer. Wondering what to stick on your computer to cover up that company logo? Again, you have the answer. Pick up your sticker at the [EMAIL PROTECTED] table. I will remind you that these are first-come, first-served and will be placed on the table at random times during the day. Be kind and allocate fairly. [EMAIL PROTECTED] Gone Wild** Observe the IETF65 A-listers today at the [EMAIL PROTECTED] table. Video shot on Monday will be available for your viewing complete with grey beards and Bert. For the folks that arent onsite, well be archiving the video on the web in a week or two. Crack a brew and watch on your monitor. [EMAIL PROTECTED] Trivia** Visit todays trivia event at http://ietf20.isoc.org/trivia/. Take a minute or two to test your knowledge of the IETF and get a chance to be one of 20 lucky people each day to receive a bag filled with [EMAIL PROTECTED] goodies. For today's (Wednesdays) drawing, we will select the first submitter, 10 random names and the 9 last submitters from all entries. Ahhh, procrastination, aint it grand? If you were a winner for Tuesdays event, you should have received an email from me telling you so. Pick up your prize during the course of the IETF65 meeting in the ISOC office. Office hours will be posted with the winners list on the [EMAIL PROTECTED] table. The ISOC office is at the Opal Room on Tower lobby floor across from Business Center. **Stories of the IETF** Help us celebrate the [EMAIL PROTECTED] by sharing your favorite story or stories from your IETF experiences over the last 20 years. Tell us about a memorable experience at the IETF funny, momentous, notorious, life changing, etc. CIDR versus TUBA. SNMP fun of the early 90s. The striptease. The genesis of OBE. Your first meeting. Everyones got a favorite story. This is our chance to collectively illustrate the culture and successes of the IETF. Lets document our own little bit of history, okay? Submit your story in plain text at http://ietf20.isoc.org. Hate writing? Send us a video or an audio file (but verify in advance at [EMAIL PROTECTED]). Were collecting submissions and publishing them on the web. Well also be publishing a printed book comprising some of the stories that best illustrate the breadth and depth of IETF culture and activities. The stories will be accepted throughout 2006. ISOC is sponsoring this because it should. **Miscellany** [EMAIL PROTECTED] Guerilla Partying is sponsored by ISOC for IETF65. This is for amusement. None of your registration fees were used to support these activities. No insects were harmed during the planning process. Yes, there will be different activities each day. And, if you dont want to pay attention to the [EMAIL PROTECTED] stuff because it makes you feel too fun or you are busy trying to convince people that the weather in Minneapolis is a darn sight better than Dallas in March, delete these messages. **Tuesdays Trivia** 1. One IETF attendee appeared on more than a dozen IETF name badges at the Stanford IETF -- name him or her. Milo Medin. I have no idea why. 2. Which IETF area no longer exists? User Services. April and team, we miss you. 3. For some of us, getting bombed had a different meaning. Up until about 2 years ago, this game was the semi-official game of the IETF. Name it. Nuclear War. Get your own deck at http://www.flyingbuffalo.com/nucwar.htm 4. The first IETF t-shirt was designed and printed at what IETF meeting? Hawaii -- Nerds in Paradise. It was pink and everything and I vaguely remember flamingos. Wish I had one. 5. Dave Clark once said of an IETF meeting: 'It was the kind of meeting where the blood on the floor came from biting your tongue.' True or false? True. Scary, eh? **Die-Hard Attendees 50 Meetings** This list is still growing. I did like the suggestion from Carsten Bormann who said: Actually, I'd propose an IETF pain index, which is: sum of squares of the number of time zones between place of work and place of IETF meetings attended. Heres the Die-Hards as of Tuesday night: Ole Jacobsen (58) Scott Brim (55) Ross Callan Vince Fuller Tony Hain (51) Bob Hinden Allison Mankin Matt Mathis Keith McCloghrie Yakov Rekhter Mike St. Johns (60+) Jeff Schiller Lixia Zhang But remember this: the IETF's work is the sum of the whole -- each
Re: [EMAIL PROTECTED] Guerilla Party Events for Wednesday
I should point out that Mike St. Johns has 63 IETFs under his belt closely followed by Ross Callon at 61 or 62. It would be interesting to know how many airline miles the 3 of us have collected as a result of going to IETF meetings. My current United total since I signed up in 1987 is 1,462,415 but this is not only from IETF meetings :-) Ole PS Trivia for yesterday: Bach's birthday 3.21 born 321 years ago in 1685. Ole J. Jacobsen Editor and Publisher, The Internet Protocol Journal Cisco Systems Tel: +1 408-527-8972 GSM: +1 415-370-4628 E-mail: [EMAIL PROTECTED] URL: http://www.cisco.com/ipj ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: [EMAIL PROTECTED] Guerilla Party Events for Wednesday
airline miles Don't know, but related trivia: On the IETF pain scale, I have crossed 230.5 timezones (and, apart from Dallas, the same number back) on the way to IETF meetings so far, which would be equivalent to going around the earth nearly 20 times just for IETF meetings (not countint Interims). There may be some Australians who can top this significantly :-) Gruesse, Carsten PS.: Yes, the half timezone was Adelaide. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: [EMAIL PROTECTED] Guerilla Party Events for Wednesday
--On Wednesday, March 22, 2006 8:24 AM -0800 Stephen Casner [EMAIL PROTECTED] wrote: 4. The first IETF t-shirt was designed and printed at what IETF meeting? Hawaii -- Nerds in Paradise. It was pink and everything and I vaguely remember flamingos. Wish I had one. Claudio Topolcic organized the T-shirt printing on the fly during the meeting. His wife drew the artwork. I was hoping to see someone wearing one at the social. Maybe the shirts have become too small over the years. :-) There was at least one on David Borman. Jim ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: [EMAIL PROTECTED] Guerilla Party Events for Wednesday
Stephen Casner wrote: On Wed, 22 Mar 2006, Susan Estrada wrote: [snip] **Tuesday's Trivia** 1. One IETF attendee appeared on more than a dozen IETF name badges at the Stanford IETF -- name him or her. Milo Medin. I have no idea why. This was a small revolt against pressure to wear a name badge during the IETF meeting. I don't recall who picked Milo's name to be the one that was replicated, but I can say that it is a shame we don't have Milo partcipating in IETF any more. Related... at the London IETF, the security area was seen sporting name badges showing the name Steve. It was somewhat disconcerting to converse with some of them, for instance Steve Frasier. [snip] 4. The first IETF t-shirt was designed and printed at what IETF meeting? Hawaii -- Nerds in Paradise. It was pink and everything and I vaguely remember flamingos. Wish I had one. Claudio Topolcic organized the T-shirt printing on the fly during the meeting. His wife drew the artwork. I was hoping to see someone wearing one at the Dave Borman was wearing one. I guess he's been keeping in shape :-) ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: draft-santesson-tls-ume Last Call comment
Kurt: Okay. I think I get your point. I'll try one more time, but if that does not satisfy you, then you will have to respond with proposed text. I'm trying to address Pasi's comment too. Based on updates from a previous comment, the document will say: The domain_name parameter, when specified, SHALL contain a domain name in the preferred name syntax, as specified by RFC 1123. I think that this resolves your concern about the encoding of domain_name. I propose the following text to handle the same concern for user_principal_name: The user_principal_name parameter, when specified, SHALL contain an Unicode UPN, encoded as a UTF-8 string. Now, for the rest: This document does not specify how the server stores the user_principal_name, or how exactly it might be used to locate a certificate. For instance, it might be appropriate to do a case-insensitive lookup. It is RECOMMENDED that the server processes the user_principal_name with a stringprep profile [STRINGPREP] appropriate for the identity in question, such as Nameprep [NAMEPREP] for the portion domain portion of UPN and SASLprep [SASLPREP] for the user portion of the UPN. Russ At 10:04 AM 3/22/2006, Kurt D. Zeilenga wrote: At 12:03 AM 3/22/2006, Russ Housley wrote: Kurt: Would text like the following (which is largely stolen from draft-ietf-tls-psk) solve your concern: No. While the language does address part of the question: how/where canonical of the user_principal_name string is performed? it neither addresses this question: how/where canonical of the domain_name string is performed? nor address the question: what character set/encoding is used on the wire in transferring these character strings? I also suspect that the selection of SASLprep here, which is intended to be used for simple usernames and passwords, is appropriate for all of the user_principal_name string. My understanding is that the user_principal_name is composed of both a simple username part and a domain part. Components of the latter likely should instead be prepared by nameprep (if allowed to carry IDNA components). Also, as the user part of the user_principal_name is, it appears from casual examination of various MS documents, to be case insensitive, SASLprep should not be used. Kurt This document does not specify how the server stores the user_principal_name, or how exactly it might be used to locate a certificate. For instance, it might be appropriate to do a case-insensitive lookup. It is RECOMMENDED that the server processes the user_principal_name with a stringprep profile [STRINGPREP] appropriate for the identity in question, such as SASLprep [SASLPREP]. Russ At 12:19 PM 3/21/2006, Kurt D. Zeilenga wrote: At 11:06 AM 3/21/2006, Stefan Santesson wrote: Kurt, I've spent some time over this topic with Russ Housley and Paul Hoffman here at the IETF and the conclusion is that we should not specify any granular encoding or matching rules for the hints. The client's use of the name hint requires the client to know its account name and as such the client will also know in what form the server needs it. What about character set/encoding? - Kurt The client should never send the name hint in a way where the server needs to process it in order to map the hint to an account. There reference will be fixed (or removed). Stefan Santesson Program Manager, Standards Liaison Windows Security -Original Message- From: Kurt D. Zeilenga [mailto:[EMAIL PROTECTED] Sent: den 7 mars 2006 18:35 To: ietf@ietf.org Subject: draft-santesson-tls-ume Last Call comment I note the IETF last call was issued for rev. 2. That revision no longer exists, hence I reviewed rev. 3. This document specification of a User Principal Name, I believe, is inadequate. The I-D indicates that a user_principal_name is a sequence of 0 to 65535 bytes in the form of [EMAIL PROTECTED] However, such a form implies the value is a character string, but there is no mention of what character set/encoding is used here. I would think interoperability requires both client and server to have a common understand of what character set/encoding is to be used. Additionally, there is no discussion of UPN matching. Are byte sequences that differ only due to use of different Unicode normalizations to be consider the same or differ? Are values case sensitive or not? etc.. The domain_name field suffers not only from the above problem, but is flawed due to use of the outdated preferred name syntax of RFC 1034. This syntax doesn't allow domains such as 123.example. The text should likely reference the RFC 1123 which updates the preferred name syntax for naming hosts. Additionally, no mention of how International domain names (IDNs) are to be handled. I recommend ABNF be used to detail the syntax of each of these fields and that the I-D detail how values of these
Re: [EMAIL PROTECTED] Guerilla Party Events for Wednesday
On Wed, Mar 22, 2006 at 08:24:45AM -0800, Stephen Casner wrote: Claudio Topolcic organized the T-shirt printing on the fly during the meeting. His wife drew the artwork. I miss Claudio at the IETF as well (though I've seen him recently, given he works not far from my home). I left mine at home, it was getting a bit threadbare (and yes, it still fits!). -Jeff -- = Jeffrey I. Schiller MIT Network Manager Information Services and Technology Massachusetts Institute of Technology 77 Massachusetts Avenue Room W92-190 Cambridge, MA 02139-4307 617.253.0161 - Voice [EMAIL PROTECTED] signature.asc Description: Digital signature ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Appeal of AD Decision to uphold Atompub ban
On 3/19/06, Sam Hartman [EMAIL PROTECTED] wrote: Remember suspensions are a tool to improve efficiency of working groups, not punishments to punish people for bad behavior. Sam, thank you for your calm remarks. After spending a week thinking about this suspension, I have decided to withdraw my appeal, even though I still believe it was an unjust decision. The appeal is too distracting for the Atompub WG, who are supposed to be getting work done right now. I am skeptical that Atompub will get any work done, since I believe they have inaccurately identified the cause of their problems, but I wish them luck with the text I wrote for them. IESG members, please consider the appeal withdrawn. Thank you, and I apologize for the waste of time. Robert Sayre ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: [EMAIL PROTECTED] Guerilla Party Events for Wednesday
On Wed, 22 Mar 2006 11:21:37 -0600, Jeffrey I. Schiller [EMAIL PROTECTED] wrote: On Wed, Mar 22, 2006 at 08:24:45AM -0800, Stephen Casner wrote: Claudio Topolcic organized the T-shirt printing on the fly during the meeting. His wife drew the artwork. I miss Claudio at the IETF as well (though I've seen him recently, given he works not far from my home). I left mine at home, it was getting a bit threadbare (and yes, it still fits!). I have indeed seen Jeff wearing his at comparatively recent IETFs... --Steven M. Bellovin, http://www.cs.columbia.edu/~smb ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Last Call: draft-ietf-pana-framework-06
I have no doubt that an implementation can be made to work, when one has control of all the layers. The question is whether PANA bootstrap will work when all that is supplied is a PANA layer that must operate above an existing, presumably standards compliant, 802.1X/802.11i implementation. When one can bypass a restriction of 802.11i (which says to drop non-802.1X frames on the uncontrolled port), then PANA bootstrap is possible. However, what authority has PANA to change a standard developed in an entirely different standards organization? -Bob -Original Message- From: Alper Yegin [mailto:[EMAIL PROTECTED] Sent: Wednesday, March 22, 2006 7:19 AM To: 'Yoshihiro Ohba'; 'Sam Hartman' Cc: ietf@ietf.org Subject: RE: Last Call: draft-ietf-pana-framework-06 We (Samsung) have an implementation as well. Alper -Original Message- From: Yoshihiro Ohba [mailto:[EMAIL PROTECTED] Sent: Wednesday, March 22, 2006 12:02 AM To: Sam Hartman Cc: ietf@ietf.org Subject: Re: Last Call: draft-ietf-pana-framework-06 If implementability of the specification is an issue, my company has an implementation of bootstrapping 802.11i PSK mode based on running PANA over Uncontrolled Port. The implementation works without modifying a WiFi hardware or its firmware. We have a plan to publish the source code of the implementation in Open Diameter project. Regards, Yoshihiro Ohba On Tue, Mar 21, 2006 at 11:45:25AM -0500, Sam Hartman wrote: Yoshihiro == Yoshihiro Ohba [EMAIL PROTECTED] writes: e email discussion over Yoshihiro the EAP mailing list quoted below, I had a short Yoshihiro conversation on this issue with Jesse Walker during Yoshihiro IEEE 802 interim meeting in January in order to Yoshihiro follow-up the email discussion and understand the input Yoshihiro from Jesse more. As far as I understand, he seemed to Yoshihiro agree on this possible interpretation while he Yoshihiro mentioned that there is no existing 802.11i Yoshihiro implementation that uses 802.1X Uncontrolled Port for Yoshihiro non-802.1X frame exchange, but I may be still Yoshihiro misunderstanding something. Also, for the sake of Yoshihiro completeness of the email discussion over the EAP Yoshihiro mailing list, the following email that I sent in Yoshihiro response to msg03872 should be quoted as well: Yoshihiro http://lists.frascone.com/pipermail/eap/msg03879.html.] So, the implementability of our specifications is a significant concern. If we do not expect there to be environments in which a feature of our spec will be implementable, then we should remove that feature. Implementability is sufficiently important that RFC 2026 explicitly gives the IESG the ability to request an implementation report even for publication at proposed standard when it has questions about whether a particular feature can be implemented interoperably. --Sam ___ 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 ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: [EMAIL PROTECTED] Guerilla Party Events for Wednesday
This list is still growing. I did like the suggestion from Carsten Bormann who said: Actually, I'd propose an IETF pain index, which is: sum of squares of the number of time zones between place of work and place of IETF meetings attended. On the other hand, those of us whose body clocks are set to Silicon Valley Nerd Standard Time (SVNST) - where we typically start work at 10 or even 11am - get jet-lagged even when the IETF is on the US/Canada West Coast :-) Ross (who's looking forward to the next time the IETF is in Hawaii) ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Clarification of my comment on giving up on process issues
Hi. I gave a presentation at genarea today and commented that I strongly felt like giving up on any participation in process change efforts as a lost cause. I want to explain what is frustrating me and to explain what is not frustrating me. Several people said that I need to get more review of my draft. That's reasonable and I'll work on that. I admit significant frustration that concerns about lack of review were not raised during last call. However that's par for the course; last call comments including recommendations for more review come in up to the point that a document is approved and we're all used to that. Also, if people believed that the basic approach I'm taking--delegating power to the IESG--was wrong, that would be fine. People disagree with each other all the time. What I am frustrated by is that it looks like we're headed for the same sort of deadlock that we've had with all the process proposals. I suspect that I can get my draft published and that it will not be too difficult to do so. However I don't think we're building the sort of community consensus behind RFC 3933 as an approach to breaking process reform deadlock that it will actually be useful to us. What happens when John submits his nomcom proposal as an RFC 3933 experiment? Would there be any plausable way he could move forward on that proposal using RFC 3933? If the answer is that RFC 3933 is not the solution, then what is? We did not have consensus behind pesci at IETF 64.We've not had consensus behind what process priorities were appropriate in other cases. So, I'm close to concluding that we don't have mechanisms for getting consensus on larger process changes and that perhaps the right approach is to just move on with our existing processes. They mostly work after all. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Nokia 770?
Hi, Is there any way a non-US citizen can buy one of the promotional 770's available at the event and walk out with a receipt in their name? -- Tim/::1 ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Nokia 770?
On Mar 22 2006, at 13:00, Tim Chown wrote: non-US citizen Sure, get a credit card from a US bank with a US billing address. No comment (to forestall incessant ranting about *DELETED* 20th century policies). Gruesse, Carsten ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Last Call: 'Experimental Procedure for Long Term Suspensions from Mailing Lists' to Experimental RFC
I know that these comments are late for IETF LC, but Brian Carpenter indicated that I should share them here, anyway... I generally support publication of this draft as an Experimental RFC, and I hope that the IESG will use this mechanism to support more moderate and more effective mailing list control over the next 18 months. I consider this a good stop-gap measure to provide the IESG with more flexibility while we take longer-term steps to determine what type(s) of mailing list control are acceptable and reasonable for use within the IETF, and until we can update our BCPs to reflect those decisions. This experiment will also give us an opportunity to try some different mechanisms for mailing list management and to gain valuable experience regarding what works and what doesn't. During the Gen Area meeting today, it was asserted that if this experiment is successful, this document might become a BCP essentially as written. I did not realize that was being considered until we got to the Gen Area meeting, and while I consider it reasonable to offer some relief for an 18-month period while we determine what else we should do, I have some major concerns about the idea that we would be running this experiment with a goal of making this particular draft a BCP. First, I am not sure how/if the community will have enough visibility into the results of this experiment to reasonably determine whether it has been successful. Will the IESG be expected to provide any reports on which types of experimental mailing list control do/don't work? Do we have any measures, even subjective ones, that could be used to determine whether things get better or worse during the period of this experiment? Also, I don't think that it is a good idea to effectively give the IESG absolute, unilateral control of our mailing list management, including the discretion to use different rules for different lists and change those rules over time. To put this in the terms that Brian defined in the Gen Area meeting (see his slides in the proceedings if you weren't there), this document gives the IESG broad discretion over both the process and procedures that will be used for IETF mailing list control, and it does not assert any principles that should be used to guide those processes and procedures. Every situation is different. So, IMO, it is important to provide the IESG with substantial discretion to determine the right types of mailing list control for each situation. I believe that our current BCPs are much too restrictive in this regard. However, we also need to remember that these cases are highly emotionally charged, and often involve well-established IETF participants on one side, such as WG chairs and ADs, and less well-established participants on the other. There are a lot of things that we hope that our WG chairs and mailing list administrators will try before considering a suspension of posting priveleges, such as meeting with the individual(s) involved and trying to work through the issues that are causing disruption. ADs also tend to get involved in those discussions, and by the time an individual situation comes to the attention of the IESG, the WG chairs and ADs involved may be tired of the issue, frustrated or angry with the offending participant and/or impatient for action to be taken. The involved ADs may also feel that a negative decision on the proposed action may be seen as insulting or insensitive to the WG chairs being affected by a participant's behaviour. It is not expected that the involved ADs will recuse themselves from discussion or voting on these issues, and it is quite possible (I don't think it has happened, but it could happen) for these factors to lead to a lynch mob mentality. Because of the emotional nature of these situations, I think that we need some well-understood principles and processes to guide the actions of the IESG in these situations, and to provide some framework for appeals by the targets of these actions in the event that those principles and processes are violated. So, I think that the community needs to determine the right balance between defined processes and IESG discretion, and I personally think that this document errs too far on the side of complete IESG discretion than would be appropriate for a long term solution. Margaret ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Clarification of my comment on giving up on process issues
Ed == Ed Juskevicius [EMAIL PROTECTED] writes: Ed I wonder if part of the reason is we often resort to a modus Ed operandi of let a thousand flowers bloom and let the market Ed decide for contentious issues. While that *might* work for a Ed technology spec, it clearly is not a workable means of Ed progressing process change proposals. My argument is that proliferation of competing process change proposals may well be an appropriate mechanism for RFC 3933 experiments--even when these are significant process experiments. I think recruiting the stakeholders will provide enough of a gate. But this is only true if the community buys into the approach . ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Nokia 770?
On Wed, 22 Mar 2006, JORDI PALET MARTINEZ wrote: Agree ... Is not fair. I think it should be a rule, a very simple one: Is ok to take the opportunity for the host to promote or sell products related to IETF protocols, and I even will encourage it, but certainly, it should be in such way that EVERYONE, despite his/her nationality, have equal access to it. You got it in europe 6 weeks before it arrived in the US. Mine didn't arrive until December 14... Regards, Jordi De: Carsten Bormann [EMAIL PROTECTED] Responder a: [EMAIL PROTECTED] Fecha: Wed, 22 Mar 2006 13:21:34 -0600 Para: Tim Chown [EMAIL PROTECTED] CC: Carsten Bormann [EMAIL PROTECTED], ietf@ietf.org ietf@ietf.org Asunto: Re: Nokia 770? On Mar 22 2006, at 13:00, Tim Chown wrote: non-US citizen Sure, get a credit card from a US bank with a US billing address. No comment (to forestall incessant ranting about *DELETED* 20th century policies). Gruesse, Carsten ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ** The IPv6 Portal: http://www.ipv6tf.org Barcelona 2005 Global IPv6 Summit Slides available at: http://www.ipv6-es.com This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf -- -- Joel Jaeggli Unix Consulting [EMAIL PROTECTED] GPG Key Fingerprint: 5C6E 0104 BAF0 40B0 5BD3 C38B F000 35AB B67F 56B2 ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Clarification of my comment on giving up on process issues
I have a growing feeling that part of the problem here is that many Working Groups are in effect maintenance activities. The three tier PROPOSED-DRAFT-STANDARD scheme has many accepted flaws, not least the fact that grandfathered specs aside practically nothing ever makes the final step from DRAFT to STANDARD. I think that a bigger problem may well be the fact that RFC 822 is officially THE standard while for all meaningful purposes the real standard is RFC 2822. I think that one of the flaws in the scheme is that the original proposal was designed for specs like IPv4/TCP etc which are effectively fixed for all time on deployment. Most specs are not like that, continuous maintenance is required. If the spec does not require any maintenance it probably indicates that it should probably be shuffled off to HISTORIC. I would like to see a two tier scheme for standards (i.e. eliminate the illogical and misleading status 'DRAFT') but on the understanding that standards require periodic review. By periodic I mean that there should be fixed windows that are scheduled in advance when the standard will be reviewed. There would be a fixed interval in which defect reports could be submitted. One of the topics of the general session for each area would be a report on the defect reports and discussion of whether a new revision WG was required. It might be easier to close WGs down if this was not quite so final. Allowing a 'fast track' for defect reports would encourage proposers to come to the IETF with complete proposals with a substantial degree of consensus in the user and developer communities. If the defect report is justified the need should be widely felt, if as is likely the report is describing existing field practice addressing that need there should not be a need for substantial discussion. In some cases it would be appropriate to reactivate the working group concerned, in others a mini-WG might address multiple protocols. The need is most common in the security area where crypto practices need to be revised every 5 years or so. An area wide activity describing use of SHA-256 would be an example. smime.p7s Description: S/MIME cryptographic signature ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Clarification of my comment on giving up on process issues
On Wed, Mar 22, 2006 05:00:14PM -0800, Hallam-Baker, Phillip allegedly wrote: I would like to see a two tier scheme for standards (i.e. eliminate the illogical and misleading status 'DRAFT') but on the understanding that standards require periodic review. By periodic I mean that there should be fixed windows that are scheduled in advance when the standard will be reviewed. There would be a fixed interval in which defect reports could be submitted. One of the topics of the general session for each area would be a report on the defect reports and discussion of whether a new revision WG was required. It might be easier to close WGs down if this was not quite so final. Allowing a 'fast track' for defect reports would encourage proposers to come to the IETF with complete proposals with a substantial degree of consensus in the user and developer communities. If the defect report is justified the need should be widely felt, if as is likely the report is describing existing field practice addressing that need there should not be a need for substantial discussion. In some cases it would be appropriate to reactivate the working group concerned, in others a mini-WG might address multiple protocols. The need is most common in the security area where crypto practices need to be revised every 5 years or so. An area wide activity describing use of SHA-256 would be an example. It seems to me that if we can't motivate people to review/evaluate/fix a proposed|draft standard once, how can we motivate them to commit to doing so periodically? Are you saying that if we allow them to slap a standard together and declare it done more easily, that they will be more willing to come back and fix it later? ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
