Re: text suggested by ADs
At 23:47 30/04/2005, Fred Baker wrote: On #2, when an AD posts a DISCUSS, s/he is now required to post a comment to the id tracker. I don't think you want the AD to have to write it twice. Coming back to a comment that was made earlier (and has been made on [EMAIL PROTECTED], which IMHO is a better place to have this part of the discussion) what you want is an automated note sent to the WG mailing list (or in the case of an individual submission, to the authors) indicating that the draft's tracker entry has been updated and giving a URL to go read it. As a general rule and to make everyone aware of the id tracker, I would suggest it to be netiquette to refer to Drafts though their ULD there - as for any other quoted document. It would simplify the life of everyone, make people more aware of the IESG work and probably increase global efficiency? jfc ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: improving WG operation
Dave, do you have any thoughts about how we can change the IETF culture from presentation to interaction (with or without slides). This is something that the IESG has been talking about, among others, but I'm not sure that we've come up with any really concrete ways to provoke/encourage this change. Margaret, in general I think the issue is stricter meeting planning and management, where the goals and process are more explicit. Of course, good wgs already do that. Off the top of my head: 1. Require that the meeting have a web-posted agenda -- and really enforce the requirement. So, this makes sure others have a chance to evaluate what is going to take place. No agenda a week in advance; no meeting. 2. Require that the deliverables of the meeting be pre-stated and prioritized. 3. Have the agenda include statements about how the deliverables will be met. I guess this is something on the order of stating what the meeting process will be. Hence, interaction with the participants is a component of that process. 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: improving WG operation
People can and do use powerpoint slides in many ways. Some folks will rework text in real-time, based on interaction with the participants. Some folks just talk their slides rather than actually engaging with the participants. A thing to keep in mind is that slides and the jabber activity can be incredibly helpful to folks for whom English not their native language. I think that, in fact, the issue is not powerpoint-vs-no-powerpoint. I think it is exactly and only the concern you raise: meetings need to be for working group interaction. If that is the clear goal and if the meeting is run with that goal enforced, then none of the trappings matter. I completely agree with this. And, I've been to plenty of non-interactive lectures that didn't involve any slides. Dave, do you have any thoughts about how we can change the IETF culture from presentation to interaction (with or without slides). This is something that the IESG has been talking about, among others, but I'm not sure that we've come up with any really concrete ways to provoke/encourage this change. Margaret ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: improving WG operation
Margaret, Dave, et al- Based on the discussion started in the IESG, one thing we are going to try to do in Paris is have a couple of smaller rooms with a different chair setup--herringbone instead of the theater style, a couple more radio microphones, and appropriate-size (smaller than huge) projector screens. I'm working with the secretariat on this. -- Alex I think that, in fact, the issue is not powerpoint-vs-no-powerpoint. I think it is exactly and only the concern you raise: meetings need to be for working group interaction. If that is the clear goal and if the meeting is run with that goal enforced, then none of the trappings matter. I completely agree with this. And, I've been to plenty of non-interactive lectures that didn't involve any slides. Dave, do you have any thoughts about how we can change the IETF culture from presentation to interaction (with or without slides). This is something that the IESG has been talking about, among others, but I'm not sure that we've come up with any really concrete ways to provoke/encourage this change. Margaret ___ 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: improving WG operation
Margaret, The words I hate most when I am in a WG meeting are these: take it to the mailing list That is usually short for we can't agree in person so we'll now continue to disagree by email. Debate has been shut off, and usually prematurely because there is something else on the agenda. I'd rather that never happen. I think it's fair to specify the parameters for a decision and then go to the mailing list so that people could evaluate different solutions based on those parameters, but simply blowing off a topic because the group cannot agree is a failure of leadership. So, in answer to the question you asked Dave, I would agree with him about [1] and [2] in his message. I don't fully understand [3]. I would go a bit further to say that the agendas should be approved by an AD. Why? Because it forces the AD to pay attention to the group. No group should run on auto-pilot. Any AD that cannot do this with little or no effort, should spend more time with the WG in question. The AD gets to approve the order. If agenda bashing shows that the chair missed something, then there was a failure on the mailing list, and corrective action should be taken to fix the problem. I would not penalize a WG for not getting to the end of its agenda. That, in fact, is a call for an interim meeting, perhaps. I would add one more thing. We need whiteboards, ones with erasers. it used to be that we had them years and years ago. Being able to draw out solutions and list and reorder problems is a good thing. So, a not so fictitious example: The ISMS WG is currently struggling to choose between one of three architectures for integrated SNMP security models. A call for consensus has been issued, and thus far there is none. The reason there is none is that people do not yet agree on the underlying requirements, IMHO. This is all good fodder for an in person meeting. If neither mailing list nor in person meeting can solve the problem, then the AD needs to step in and do something. Prior to the meeting there should be a short summary of the issues, pro and con for each alternative, as well as proposed evaluation criteria. The meeting may be a good venue to expand or contract those criteria. Eliot ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Moving forward on IETF problems
This has been an interesting discussion, but somewhat one-sided. Authors, editors, and WG Chairs and participants tend to believe that they produce perfect output, but that is demonstrably not always true. Although the IESG supposedly provides a quality control, it's clearly not working. Rather than vague assertions, I'll mention a couple of specifics: RFC 4021 and draft-fax-esmtp-conneg. RFC 4021 has been published as Standards Track. In accordance with RFC 2026, it contains a section referencing RFC 2119 and the latter's keywords which indicate levels of requirements. However, none of those keywords appear anywhere in the document but the section stating that 2119 in fact defines such keywords! Moreover, the document does not impose any protocol or format requirements and does not lend itself to any implementations (its purpose is to document items being included in an IANA registry); the Standards Track is the wrong category for such a document -- there is no way that it can advance to Draft Standard. This is a spectacular and surprising instance of complete failure of the authors, the IESG, and the RFC Editor to control quality. It is surprising and spectacular because the document structure is so simple and its purpose evident. There is no way that the IESG and RFC Editor should have categorized that RFC as Standards Track. There are many issues with the draft mentioned above; despite having ABNF expertise among the authors, there are at least a half-dozen specific problems with the ABNF. The document lacks discussion of interaction with directly-related protocols (ESMTP submission, e.g.), has no BCP 90 registration forms for message header fields defined, no discussion of internationalization issues, and an inadequate IANA considerations section. The draft has been through at least one Last Call (version -09 and possibly also version -02), and has been approved as a Proposed Standard (-13) despite the known technical omissions, the vagueness which precludes the specification from being well-understood, etc. This is another failure of quality control; the document does not meet the minimal requirements for Proposed Standard (RFC 2026 section 4.1.1). There are clear requirements for the Standards Track; apparently the authors, WGs, the IESG and the RFC Editor aren't taking the necessary time to review documents for compliance with those requirements. I have separately (NEWTRK mailing list) suggested that those requirements should be distilled into a checklist, and have further suggested that some tolls might be capable of highlighting specific problems such as the RFC 4021/2119 issue. Clearly, I'm bemoaning the lack of quality of recent work; others have complained about timeliness. Still others have mentioned relevance and comprehensibility. There have been some allusions to cost (in the form of increased manpower for review). There is a well-known engineering issue: o Quality o Timeliness o Cost Pick any two. Part of the problem with time/quality tradeoff is that many drafts are in such a poor editorial state that it impedes review. One possible way to expedite the technical review would be to ensure that documents are edited for readability and comprehensibility prior to IESG review and Last Call. That may involve cost (somebody has to provide editorial advice). Or the IESG could simply push back documents of poor editorial quality (ideally with a list of resources -- currently scattered among RFCs, presentations, semi- official documents (ID-guidelines, ID-Checklist, ID-nits), etc.). RFC 3774 has been mentioned in this discussion; that document and RFC 3844 discuss some problems and potential solutions, but do not address the generally poor quality of documents entering the review stage. Some of the issues identified have been partially addressed (e.g. RFC 3935 provides the mission statement mentioned as lacking in section 2.1 of RFC 3774 -- but the IETF web site makes no mention of the IETF mission and has no direct link to the mission statement). 3774 also bemoans a perceived lack of assessment based on practical experimentation, ignoring the fact that most RFC categories specifically provide for such practical experimentation (i.e. the Standards Track plus Experimental (and Historic for failed experiments)). 3774 also makes the extraordinary claim that the quality bar has been raised. As mentioned above, a part of the quality problem can be attributed to lack of organization of relevant material in a single place. The NEWTRK ISD effort might be able to help -- but as noted above, many of the relevant information is in documents that are not RFCs, and which may have no clear official status, and moreover, which may change frequently. However, there is a danger that the benefit of consolidating pointers to related information may be diluted by incorporation of unrelated agendas (specific document format issues), and the danger of causing a further
RE: improving WG operation
It seems to me that the fundamental problem is that most of the meeting has not read most of the drafts let alone the latest version under discussion. There is a fundamental IETF tenet that nothing is explained but there is a false assumption that the people in the meetings have read the drafts. Whenever I've seen the chair ask how many hve read the draft, it is usually 5%. I think this is a key issue but the solution is not obvious. Nobody can read the number of drafts that are issued for a meeting. Not even for the subset of attended WGs. Other organizations have proponents explain what they are proposing. IMO this leads to a better quality of discussion. But this limits the number of topics that can be worked on in a week to far less than the IETF tries to cover. Steve Silverman -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Margaret Wasserman Sent: Sunday, May 01, 2005 10:10 AM To: Dave Crocker Cc: ietf@ietf.org Subject: Re: improving WG operation People can and do use powerpoint slides in many ways. Some folks will rework text in real-time, based on interaction with the participants. Some folks just talk their slides rather than actually engaging with the participants. A thing to keep in mind is that slides and the jabber activity can be incredibly helpful to folks for whom English not their native language. I think that, in fact, the issue is not powerpoint-vs-no-powerpoint. I think it is exactly and only the concern you raise: meetings need to be for working group interaction. If that is the clear goal and if the meeting is run with that goal enforced, then none of the trappings matter. I completely agree with this. And, I've been to plenty of non-interactive lectures that didn't involve any slides. Dave, do you have any thoughts about how we can change the IETF culture from presentation to interaction (with or without slides). This is something that the IESG has been talking about, among others, but I'm not sure that we've come up with any really concrete ways to provoke/encourage this change. Margaret ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ This message was passed through [EMAIL PROTECTED], which is a sublist of [EMAIL PROTECTED] Not all messages are passed. Decisions on what to pass are made solely by IETF_CENSORED ML Administrator ([EMAIL PROTECTED]). ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: text suggested by ADs
Keith, The case John outlines is the one I am concerned about as well. [...] And, FWIW, when the AD suggests specific text changes, it's often enough the desire of that AD rather than based on feedback from some other WG. I don't see anything wrong with that. It's the ADs' job to push back on documents with technical flaws. They're supposed to use their judgments as technical experts, not just be conduits of information supplied by others. I think the ADs should continue to be able to raise such issues, but I also think it might be helpful to have better way of resolving such disputes than either let the AD win or let's sit on this until the IESG holds its nose and passes it. Sure - and sometimes other ADs get involved, and it boils down to what can you add/change to appease the other AD rather than what is sensible to add. It's as likely to boil down to how do we get this WG to realize that there really is a serious technical problem with what they've created? How about requiring to produce working code (and perhaps operational experience) ? Yakov. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: text suggested by ADs
It's as likely to boil down to how do we get this WG to realize that there really is a serious technical problem with what they've created? How about requiring to produce working code (and perhaps operational experience) ? working code is valuable in some cases - especially where it appears that the protocol is not easily implemented. but working code won't provide an indication of how well the protocol works in large deployments in the wild. for that, analysis and/or modeling are the best tools we have. Keith ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: improving WG operation
It seems to me that the fundamental problem is that most of the meeting has not read most of the drafts let alone the latest version under discussion. I think that's a symptom; a more fundamental problem is that WGs are trying to do too many things at once. I've lost track of how many times I've seen a WG a) take valuable meeting time to have a presentation about a draft that is only peripherally related to the WG's current task b) get a show of hands how many people think this draft should be a WG work item? c) accept the draft as a WG work item without any discussion of whether doing so will affect the WG's ability to get other work done, or the WG's ability to give adequate attention to the work already accepted Now there are certainly cases in which a WG needs to generate lots of documents in order to fulfill its mission. But to the extent that new work items are identified in the manner described above, it probably indicates a lack of planning. It should be possible to identify early on which topics need to be addressed by WG documents and which ones are either peripheral to the WG's mission or need to wait until the primary deliverables are completed. The initial charter is generally too early to do this, but it would be reasonable for such a work plan to be one of the first deliverables of the initial charter. Once that work plan is established, WGs need to push back on taking on additional work. And the push back probably needs to come from the chairs, or if the chairs won't do it, the ADs. Keith ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: improving WG operation
--On Monday, 02 May, 2005 09:56 -0400 Steve Silverman [EMAIL PROTECTED] wrote: It seems to me that the fundamental problem is that most of the meeting has not read most of the drafts let alone the latest version under discussion. There is a fundamental IETF tenet that nothing is explained but there is a false assumption that the people in the meetings have read the drafts. Whenever I've seen the chair ask how many hve read the draft, it is usually 5%. I think this is a key issue but the solution is not obvious. Nobody can read the number of drafts that are issued for a meeting. Not even for the subset of attended WGs. If it were true that no one can read the drafts relevant to work they are actually materially concerned with (a slightly different definition than yours), and I suggest it is not, then WGs are trying to do too much, and handle too many documents, at once. Others have made that point. As far as the 5% is concerned, we have, it seems to me, a choice: * We can decide to focus on the people who are doing the work and making real contributions. If they have read the drafts, fine. If most of them have not, then it is time to cancel the meeting after that show of hands. Those who are not usefully contributing don't count at all. * We can decide that the people who haven't done the reading shouldn't be in the room and either evict them or impose admission requirements for participation in a WG. Note that many of the other groups to which you refer have such admission requirements, whether they are taken seriously or not. Other organizations have proponents explain what they are proposing. IMO this leads to a better quality of discussion. But this limits the number of topics that can be worked on in a week to far less than the IETF tries to cover. It also, often, leads to much more superficial evaluation of what is being standardized than the IETF has traditionally been willing to tolerate. Note that we still expect most work to be done on mailing lists and between meetings, not in face-to-face no one things about this in between, then we get together and try to make standards meetings. I think either model can be viable, but they are different... and there are still significant contributors to the IETF who have no set foot in a face-to-face IETF meeting in years (if ever). john ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: improving WG operation
--On Monday, 02 May, 2005 05:43 -0700 Alex Zinin [EMAIL PROTECTED] wrote: Margaret, Dave, et al- Based on the discussion started in the IESG, one thing we are going to try to do in Paris is have a couple of smaller rooms with a different chair setup--herringbone instead of the theater style, a couple more radio microphones, and appropriate-size (smaller than huge) projector screens. I'm working with the secretariat on this. Alex, Given other discussions on this list, might I suggest that those rooms also be equipped, if possible, with some mechanism by which interactions within the group/meeting can easily be recorded: Any of overhead projectors with foils and markers, flip charts with markers, or whiteboards would all do the job and all have been mentioned. As others have pointed out, these things can, in theory, all be done in powerpoint, but I suggest that few of us are efficient enough with it to be able to do pictures and serious mark-up in real time (independent of whether we can transcribe text or not). Or, if that isn't feasible for Paris, could it be considered for Vancouver? thanks, john ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: improving WG operation
As others have pointed out, these things can, in theory, all be done in powerpoint, but I suggest that few of us are efficient enough with it to be able to do pictures and serious mark-up in real time (independent of whether we can transcribe text or not). A simple, ad hoc, and useful approach is to make sure someone takes a picture as legacy-technology renditions -- paper, whiteboard, whatever -- are created, and then uploads it or emails it to an agreed-to location. It is procedurally a bit awkward, but already fits into existing practise, albeit not for this purpose. And it does not require any formal support. 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: improving WG operation
Margaret Choose the right chairperson (or having chosen one, train them). I have heard you speak of the roles of the WG chair (and of the editors of I-Ds) and think your ideas are absolutely right. The WGs that I find less effective are those where the chairs, for all their undoubted engineering skills, are less effective at the role of chairmanship of meetings, a role which starts with the agenda, ends with the minutes, and involves making the most effective use of the 'face time' in between. Tom Petch - Original Message - From: Margaret Wasserman [EMAIL PROTECTED] To: Dave Crocker [EMAIL PROTECTED] Cc: ietf@ietf.org Sent: Sunday, May 01, 2005 4:09 PM Subject: Re: improving WG operation People can and do use powerpoint slides in many ways. Some folks will rework text in real-time, based on interaction with the participants. Some folks just talk their slides rather than actually engaging with the participants. A thing to keep in mind is that slides and the jabber activity can be incredibly helpful to folks for whom English not their native language. I think that, in fact, the issue is not powerpoint-vs-no-powerpoint. I think it is exactly and only the concern you raise: meetings need to be for working group interaction. If that is the clear goal and if the meeting is run with that goal enforced, then none of the trappings matter. I completely agree with this. And, I've been to plenty of non-interactive lectures that didn't involve any slides. Dave, do you have any thoughts about how we can change the IETF culture from presentation to interaction (with or without slides). This is something that the IESG has been talking about, among others, but I'm not sure that we've come up with any really concrete ways to provoke/encourage this change. Margaret ___ 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: text suggested by ADs
Keith, It's as likely to boil down to how do we get this WG to realize that there really is a serious technical problem with what they've created? How about requiring to produce working code (and perhaps operational experience) ? working code is valuable in some cases - especially where it appears that the protocol is not easily implemented. but working code won't provide an indication of how well the protocol works in large deployments in the wild. for that, analysis and/or modeling are the best tools we have. How many of such analysis and/or modeling has been produced by the IESG ? Yakov. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: text suggested by ADs
working code is valuable in some cases - especially where it appears that the protocol is not easily implemented. but working code won't provide an indication of how well the protocol works in large deployments in the wild. for that, analysis and/or modeling are the best tools we have. How many of such analysis and/or modeling has been produced by the IESG ? I don't know, and neither do you. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: text suggested by ADs
Keith, I don't see anything wrong with that. It's the ADs' job to push back on documents with technical flaws. They're supposed to use their judgments as technical experts, not just be conduits of information supplied by others. I disagree that the ADs are necessarily that much more technically astute than the rest of us. 1. ADs usually _are_ more technically astute than the average IETF participant (perhaps not you, but the average participant), because ADs are selected for their expertise while IETF participants are self-selecting. (Maybe some are selected by their employers, but I don't think it's generally the practice of most employers to send their best technical people to standards committees. My impression is that many employers - not all by any means - would rather send people who are expendable, and/or who will represent the company's official position rather than their own best judgment.) At the same time for each AD there is more than one person in the IETF who is more technically astute than that AD. So, why should the IETF decision process favor opinion of such AD more than the opinion of these other individual who are more astute that the AD ? 2. ADs also tend to have a broader perspective than the average IETF participant, because ADs are exposed to everything that IETF does while most participants' activity is confined to a narrow topic area. That's not to say that a broad perspective is inherently less valuable than a narrow perspective - they're both valuable, but for different reasons. Suffice to say that ADs do *not* have the monopoly on the broader perspective. Yakov. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: text suggested by ADs
At the same time for each AD there is more than one person in the IETF who is more technically astute than that AD. perhaps. however, it's hard to identify those people, and they may not have either the time/energy or neutrality that are required to do final review. if they do, they're free to put their names in the hat for the next NOMCOM. Keith ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: improving WG operation
- The working group gets to pick at least some of its own chairs. Sorry, but I do not think the last bullet is correct. I was talking about community expectation, which is not always consistent with what is written in the RFCs just like implementations of networking protocols are not always consistent with the RFCs. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: improving WG operation
Keith, [clipped...] 2. There is a considerable cultural inertia within IETF that largely dictates how working groups operate, and which is extremely difficult to change. For instance, community expectations include: - If there is a BOF held and sufficient constituency identified for a working group, the working group must be chartered. - The working group gets to pick at least some of its own chairs. Sorry, but I do not think the last bullet is correct. To the contrary, (quoting from rfc3710): The AD, with the advice of the IESG, is also responsible for selecting chairs for the working group which the AD thinks will be up to the task. Nowhere it mentioned that the WG gets to pick at least some of its own chairs. Yakov. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: text suggested by ADs
On Fri, 2005-04-29 at 09:35, Ralph Droms wrote: Let me restate for clarity - ADs aren't necessarily more technically astute than *all* the rest of us. That is, we need to be careful that technical input from ADs isn't automatically assigned extra weight or control (veto power). Indeed. There will be very technically astute people involved in the IETF who don't want to serve as AD for any number of reasons (have other life-consuming things to do; don't want to deal with the politics, etc.). And I haven't seen sufficient attention paid in this thread to the difference between breadth vs. depth in both knowledge and skill. I would expect that the folks writing the specs would have the most depth with respect to their particular technology while AD's and other generalist reviewers would likely have more breadth and better insight about the interaction between that technology and the rest of the universe. - Bill ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Technically-astute non-ADs (was: Re: text suggested by ADs)
--On Monday, 02 May, 2005 18:26 -0400 Bill Sommerfeld [EMAIL PROTECTED] wrote: On Fri, 2005-04-29 at 09:35, Ralph Droms wrote: Let me restate for clarity - ADs aren't necessarily more technically astute than *all* the rest of us. That is, we need to be careful that technical input from ADs isn't automatically assigned extra weight or control (veto power). Indeed. There will be very technically astute people involved in the IETF who don't want to serve as AD for any number of reasons (have other life-consuming things to do; don't want to deal with the politics, etc.). And some of us who periodically delude ourselves that we are technically astute in at least a few areas have put in our time as ADs and feel as if we have paid our dues and it is someone else's turn. I certainly fall into that category. I can't speak for Keith, Dave Crocker, and other former ADs who have spoken up in this discussion, but I suspect... So I want to pose a different, but related, pair of questions to Bill, Ralph, and others: (1) What would it take to convince you that putting in a term or two as AD --not a life sentence, but a term or two-- was an obligation you, as long-term participants and contributors, owed the community? (2) How, if at all, would the AD job have to change in order to make volunteering on that basis plausible for you? Please don't just answer lower workload: if that is all or part of the answer, what would you get rid of and what would you do with it? john ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RFC 4027 on Domain Name System Media Types
A new Request for Comments is now available in online RFC libraries. RFC 4027 Title: Domain Name System Media Types Author(s): S. Josefsson Status: Informational Date: April 2005 Mailbox:[EMAIL PROTECTED] Pages: 6 Characters: 11676 Updates/Obsoletes/SeeAlso:None I-D Tag:draft-josefsson-mime-dns-02.txt URL:ftp://ftp.rfc-editor.org/in-notes/rfc4027.txt This document registers the media types application/dns and text/dns in accordance with RFC 2048. The application/dns media type is used to identify data on the detached Domain Name System (DNS) format described in RFC 2540. The text/dns media type is used to identify master files as described in RFC 1035. This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to [EMAIL PROTECTED] Requests to be added to or deleted from the RFC-DIST distribution list should be sent to [EMAIL PROTECTED] Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to [EMAIL PROTECTED] with the message body help: ways_to_get_rfcs. For example: To: [EMAIL PROTECTED] Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to [EMAIL PROTECTED] Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. Submissions for Requests for Comments should be sent to [EMAIL PROTECTED] Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the RFCs. ftp://ftp.isi.edu/in-notes/rfc4027.txt ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
RFC 4046 on Multicast Security (MSEC) Group Key Management Architecture
A new Request for Comments is now available in online RFC libraries. RFC 4046 Title: Multicast Security (MSEC) Group Key Management Architecture Author(s): M. Baugher, R. Canetti, L. Dondeti, F. Lindholm Status: Informational Date: April 2005 Mailbox:[EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] Pages: 38 Characters: 97885 Updates/Obsoletes/SeeAlso:None I-D Tag:draft-ietf-msec-gkmarch-08.txt URL:ftp://ftp.rfc-editor.org/in-notes/rfc4046.txt This document defines the common architecture for Multicast Security (MSEC) key management protocols to support a variety of application, transport, and network layer security protocols. It also defines the group security association (GSA), and describes the key management protocols that help establish a GSA. The framework and guidelines described in this document permit a modular and flexible design of group key management protocols for a variety of different settings that are specialized to applications needs. MSEC key management protocols may be used to facilitate secure one-to-many, many-to-many, or one-to-one communication. This document is a product of the Multicast Security Working Group of the IETF. This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to [EMAIL PROTECTED] Requests to be added to or deleted from the RFC-DIST distribution list should be sent to [EMAIL PROTECTED] Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to [EMAIL PROTECTED] with the message body help: ways_to_get_rfcs. For example: To: [EMAIL PROTECTED] Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to [EMAIL PROTECTED] Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. Submissions for Requests for Comments should be sent to [EMAIL PROTECTED] Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the RFCs. ftp://ftp.isi.edu/in-notes/rfc4046.txt ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
RFC 4018 on Finding Internet Small Computer Systems Interface (iSCSI) Targets and Name Servers by Using Service Location Protocol version 2 (SLPv2)
A new Request for Comments is now available in online RFC libraries. RFC 4018 Title: Finding Internet Small Computer Systems Interface (iSCSI) Targets and Name Servers by Using Service Location Protocol version 2 (SLPv2) Author(s): M. Bakke, J. Hufferd, K. Voruganti, M. Krueger, T. Sperry Status: Standards Track Date: April 2005 Mailbox:[EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] Pages: 23 Characters: 48498 Updates/Obsoletes/SeeAlso:None I-D Tag:draft-ietf-ips-iscsi-slp-09.txt URL:ftp://ftp.rfc-editor.org/in-notes/rfc4018.txt The iSCSI protocol provides a way for hosts to access SCSI devices over an IP network. This document defines the use of the Service Location Protocol (SLP) by iSCSI hosts, devices, and management services, along with the SLP service type templates that describe the services they provide. This document is a product of the IP Storage Working Group of the IETF. This is now a Proposed Standard Protocol. This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to [EMAIL PROTECTED] Requests to be added to or deleted from the RFC-DIST distribution list should be sent to [EMAIL PROTECTED] Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to [EMAIL PROTECTED] with the message body help: ways_to_get_rfcs. For example: To: [EMAIL PROTECTED] Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to [EMAIL PROTECTED] Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. Submissions for Requests for Comments should be sent to [EMAIL PROTECTED] Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the RFCs. ftp://ftp.isi.edu/in-notes/rfc4018.txt ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
RFC 4028 on Session Timers in the Session Initiation Protocol (SIP)
A new Request for Comments is now available in online RFC libraries. RFC 4028 Title: Session Timers in the Session Initiation Protocol (SIP) Author(s): S. Donovan, J. Rosenberg Status: Standards Track Date: April 2005 Mailbox:[EMAIL PROTECTED], [EMAIL PROTECTED] Pages: 27 Characters: 65363 Updates/Obsoletes/SeeAlso:None I-D Tag:draft-ietf-sip-session-timer-15.txt URL:ftp://ftp.rfc-editor.org/in-notes/rfc4028.txt This document defines an extension to the Session Initiation Protocol (SIP). This extension allows for a periodic refresh of SIP sessions through a re-INVITE or UPDATE request. The refresh allows both user agents and proxies to determine whether the SIP session is still active. The extension defines two new header fields: Session-Expires, which conveys the lifetime of the session, and Min-SE, which conveys the minimum allowed value for the session timer. This document is a product of the Session Initiation Protocol Working Group of the IETF. This is now a Proposed Standard Protocol. This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to [EMAIL PROTECTED] Requests to be added to or deleted from the RFC-DIST distribution list should be sent to [EMAIL PROTECTED] Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to [EMAIL PROTECTED] with the message body help: ways_to_get_rfcs. For example: To: [EMAIL PROTECTED] Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to [EMAIL PROTECTED] Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. Submissions for Requests for Comments should be sent to [EMAIL PROTECTED] Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the RFCs. ftp://ftp.isi.edu/in-notes/rfc4028.txt ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
Reminder: Enforcement of Updated IPR Boilerplate
This message is to remind you that as of Friday, May 6, 2005, all Internet-Drafts that are submitted to the IETF Secretariat for posting must include the IPR-related notices and disclaimers specified in RFC 3978 (BCP 78), IETF Rights in Contributions. The required notices and disclaimers can be found in Section 5, Notices Required in IETF Documents, of RFC 3978, and in Section 3, IPR-Related Notices Required in Internet-Drafts, of the recently revised Guidelines to Authors of Internet-Drafts (http://www.ietf.org/ietf/1id-guidelines.html). The Guidelines document also provides additional guidance regarding the placement of these notices. Please note that the required notices and disclaimers must be reproduced verbatim since they have been legally reviewed and formally adopted as part of the IETF process. The Secretariat will not accept deviations from the specified text, nor will it correct the text. Any documents that do not comply with the requirements of RFC 3978, and with the most recent version of the Guidelines document, will be returned to the submitter. The IETF Secretariat ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
