Re: ion-ion-store open for public comment
Dave Crocker wrote: Brian E Carpenter wrote: So internet drafts, however ephemeral we claim them to be, are versioned and referenceable. I don't know that the final step (the RFC) is any less permanent than the history we maintain of the drafts leading up to it. That's beside the point. This is nothing to do with RFC development. This is for stuff that will (almost certainly) never be an RFC. snip In short, under what circumstances would I post an ION instead of an internet draft? If you were, for example, the maintainer of 1id-guidelines. Anyway - again, this is an experiment, and yours are the questions to be asked at the end of the experiment. Brian, et al, The basic desire to collect together the documents that the IETF uses for its internal operations strikes me as simple and entirely pragmetic. (I have to note that until this latest set of postings, I thought that ION's somehow competed with BCPs, by virtue of being related to operations.) One might want to wonder, a bit, about the IETF's having a growing number of such documents, and that this might make it more difficult to know enough about IETF procedures and the like, but it is clear that the body of documents are better collected under one reference roof than being strewn around. As for you last sentence, perhaps it should give some pause. The idea that we do not already have a pretty clear idea of what should distinguish an I-D from an ION ought to engender concern. Like any other project consuming significant resources, an experiment is supposed to have reasonably clear statements of differentiation and expected benefit. I personally believe that it is clear in RFC 4693. (I also believe we have a number of process BCPs that contain operational details that don't really belong there, but pre-ION we had no systematic way to handle such details.) On reflecting about the forces that seem to have led to the creation of the ION experiment, I suspect that there are two concerns: 1) Needing a label that collects together internal operating notes and distinguishes them from other IETF documents, and 2) the overhead of getting an RFC published. The first could be solved easily by adding a new, non-standard-track sub-label to the RFC series and I suspect the latter could be resolved by making an arrangement with the RFC Editor to have IONs go through less handling and proofing overhead. (And, gosh, this might even give a basis for reviewing why RFC publication has become high overhead...) Again - this is exactly what we should discuss at the *end* of the experiment, by which time we'll also have significant experience with the new RFC Editor contract. Although probably warranting an entirely separate thread, it might again be worth revisiting the question of archival access to expired I-Ds. The number of times that folks suffer from not being able to easily get access to old copies is growing. The most obvious of these is for intellectual property research, but one that is closer to home is to be able to aid in assessing the sequence of changes that a document went through, by way of responding to improvements in working group discussions. Indeed it's a separate topic... Brian ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: ion-ion-format open for public comment
Frank Ellermann wrote: Brian Carpenter wrote: Please see http://www.ietf.org/IESG/content/ions/drafts/ion-ion-format.txt It says text or html, but ion-ion-store is perfectly valid XHTML. Is that a problem ? I don't think so, do you? The HTML output of xml2rfc is rather ugly with my browser, and its nice unpaginated output doesn't offer meta-data and I18N, tough :-( The HTML output is apparently also no valid HTML (tested with your ion-procdoc draft), they forgot apos; in HTML 4.01, and apparently UL needs a closing /UL - with HTML I never know, XHTML is KISS. That is one for the xml2rfc list I think. The SVN access doesn't work yet (authentification fails). And that's the one you're discussing with Henrik. Brian ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: draft status links on the wg pages?
Dave, Given that the Tools folk have created yet-another useful mechanism, making each working group's page have a link to its related status information now becomes a trivial effort, with substantial benefit. This would be useful. (FWIW, I've already moved to using only the tools page -- you get to everywhere where you need from the tools page, including the official charter page.) --Jari ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
HOKEY interim meeting on January 23rd
The HOKEY WG will hold a one-day interim meeting. The CAPWAP WG will hold an interim meeting at the same location on the two days following the HOKEY WG interim meeting. Here are the details: HOKEY WG Interim Meeting Tuesday, January 23, 2007 9:00 AM - 5:00 PM (PDT) 3750 Cisco Way (Building 15) San Jose, CA Thanks, Russ ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
nomcom:Soliciting feedback from entire working groups?
If I'm reading the following mail correctly, it sounds like the nomcom is requesting feedback from a working group mailing list. In other words anyone who creates a tools.ietf.org account for that address can see the short list of candidates. At that point, shouldn't we just be making the short list public? ---BeginMessage--- Security Area Director Candidate Feedback The NomCom solicits your input on the candidates it is reviewing for the Security Area Director position. It is a requirement of the NomCom process that lists of candidates reviewed by the NomCom are to be kept confidential. Therefore, when you receive the list of candidates for review, you MUST keep it confidential and MUST NOT share it with anyone else. The NomCom requests that you provide your input as soon as possible, for full consideration, please have them in no later than the end of the day, Tuesday, January 2, 2007. Your input is a very important aspect of the process through which the NomCom will make its selections for IETF leadership. We encourage you to review the list of candidates you have been asked to comment on and provide us any input that might help us in our selection. Please provide input on as many candidates as you can; input to the effect of I'm not familiar with X is acceptable and useful to the NomCom. This year, the NomCom is accepting input on candidates through a web-based tool. Later in this message, you will find a URL through which you can provide your input. You may be asked for input on multiple positions that are under review by the NomCom. If you are asked for input on multiple positions, you will receive separate e-mail requests for each position. If you prefer to provide anonymous input, please send it directly to the NomCom chair, Andrew Lange, [EMAIL PROTECTED], who will make your input anonymous before forwarding it to the NomCom. Any input you provide, whether it is provided to the NomCom directly through the web-based tool or anonymously, will be kept confidential and will not be shared outside the NomCom. There are names in the lists of candidates for each position who have declined nomination, which are included in the list to help protect the confidentiality of actual candidates. Also, if you are a candidate for a position, your name will not appear in the list of candidates for that position. If you are a candidate for a position, the NomCom will not accept anonymous input from you about other candidates for the same position. The web-based feedback tool gives the NomCom an automated process for collecting input on the NomCom candidates. We hope you will find it more convenient to use as well. Your input will be encrypted before it is stored by the feedback tool, and can only be decrypted by the NomCom. Some individuals may be candidates for multiple positions. If you provide input for such a candidate for one position, the NomCom will see that input for that candidate associated with each of the positions. You may provide additional input for specific positions, by clicking on the candidate's name in the list of candidates for that specific position. The feedback form is available at the following URLs: https://www1.tools.ietf.org/group/nomcom06/input/ Please use your tools.ietf.org login with the email address you have been invited with. If you do not have a tools login, you can get one at this URL: https://www1.tools.ietf.org/newlogin Again, the NomCom emphasizes that, if you use the feedback form to provide input, you MUST keep the list of candidates confidential. When you access the feedback form, you will see a list of all of the candidates you have been asked to comment on. By clicking on a candidate's name, you will be presented with a text-input form into which you can type your input. Note that, because of the way in which the NomCom collected names and e-mail addresses for individuals from whom input is solicited, we may have more than one e-mail address for you and you may receive multiple requests for feedback on the same position. We apologize in advance for any duplicate e-mail you may receive as a part of this feedback solicitation process. Thanks in advance for your feedback. Andrew ___ pki4ipsec mailing list [EMAIL PROTECTED] https://listserv.icsalabs.com/mailman/listinfo/pki4ipsec ---End Message--- ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: nomcom:Soliciting feedback from entire working groups?
Hi Sam, Commenting only on the possibility of accessing the candidate list, further down: on 2006-12-18 15:37 Sam Hartman said the following: If I'm reading the following mail correctly, it sounds like the nomcom is requesting feedback from a working group mailing list. In other words anyone who creates a tools.ietf.org account for that address can see the short list of candidates. I was alerted to this shortly after the invitations went out, and removed the list address from the ACL. For a short while, somebody requesting a password for that address (with the confirmation email and authentication hash going to the same address, thus appearing on the list) could have set a password and accessed the short list, but that's not possible any more. Henrik At that point, shouldn't we just be making the short list public? Subject: [Pki4ipsec] Nomcom06: Security Area Director Candidate Feedback From: Nomcom06 [EMAIL PROTECTED] Date: Mon, 18 Dec 2006 04:13:51 +0100 To: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Security Area Director Candidate Feedback The NomCom solicits your input on the candidates it is reviewing for the Security Area Director position. It is a requirement of the NomCom process that lists of candidates reviewed by the NomCom are to be kept confidential. Therefore, when you receive the list of candidates for review, you MUST keep it confidential and MUST NOT share it with anyone else. The NomCom requests that you provide your input as soon as possible, for full consideration, please have them in no later than the end of the day, Tuesday, January 2, 2007. Your input is a very important aspect of the process through which the NomCom will make its selections for IETF leadership. We encourage you to review the list of candidates you have been asked to comment on and provide us any input that might help us in our selection. Please provide input on as many candidates as you can; input to the effect of I'm not familiar with X is acceptable and useful to the NomCom. This year, the NomCom is accepting input on candidates through a web-based tool. Later in this message, you will find a URL through which you can provide your input. You may be asked for input on multiple positions that are under review by the NomCom. If you are asked for input on multiple positions, you will receive separate e-mail requests for each position. If you prefer to provide anonymous input, please send it directly to the NomCom chair, Andrew Lange, [EMAIL PROTECTED], who will make your input anonymous before forwarding it to the NomCom. Any input you provide, whether it is provided to the NomCom directly through the web-based tool or anonymously, will be kept confidential and will not be shared outside the NomCom. There are names in the lists of candidates for each position who have declined nomination, which are included in the list to help protect the confidentiality of actual candidates. Also, if you are a candidate for a position, your name will not appear in the list of candidates for that position. If you are a candidate for a position, the NomCom will not accept anonymous input from you about other candidates for the same position. The web-based feedback tool gives the NomCom an automated process for collecting input on the NomCom candidates. We hope you will find it more convenient to use as well. Your input will be encrypted before it is stored by the feedback tool, and can only be decrypted by the NomCom. Some individuals may be candidates for multiple positions. If you provide input for such a candidate for one position, the NomCom will see that input for that candidate associated with each of the positions. You may provide additional input for specific positions, by clicking on the candidate's name in the list of candidates for that specific position. The feedback form is available at the following URLs: https://www1.tools.ietf.org/group/nomcom06/input/ Please use your tools.ietf.org login with the email address you have been invited with. If you do not have a tools login, you can get one at this URL: https://www1.tools.ietf.org/newlogin Again, the NomCom emphasizes that, if you use the feedback form to provide input, you MUST keep the list of candidates confidential. When you access the feedback form, you will see a list of all of the candidates you have been asked to comment on. By clicking on a candidate's name, you will be presented with a text-input form into which you can type your input. Note that, because of the way in which the NomCom collected names and e-mail addresses for individuals from whom input is solicited, we may have more than one e-mail address for you and you may receive multiple requests for feedback on the same position. We apologize in advance for any
Re: ion-ion-format open for public comment
Julian Reschke wrote: IMHO it would be a good idea in the sense of own dogfood not to serve XHTML content with media type text/html. Matter of taste, from my POV XHTML 1.0 transitional is the best way to create backwards compatible (HTML 3.2) content visible with any browser. Or as the ion-ion-format draft puts it: no fancy features. If my old browser sees some real XML it simply starts my text editor... ;-) The HTML output of xml2rfc is rather ugly with my browser, and its nice unpaginated output doesn't offer meta-data and I18N, tough :-( I18N? Non-ASCII, the xml2rfc txt or unpg output is ASCII. The HTML of rfcmarkup is very nice, but at that point all meta-data and non-ASCII is already lost. Maybe xml2rfc should get a new XHTML output option, not your dogfod of course, normal XHTML 1.0 transitional text/html. Frank ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: nomcom:Soliciting feedback from entire working groups?
Judging from the email addresses where I received solicitations for comments, either every RFC author or every I-D author received an invitation to comment. (I suspect the latter, since the invitations seemed to be tailored by working group, i.e., an I-D in a Transport working group earned an invitation that included Transport candidates.) Calling a candidate list distributed to all I-D authors private is polite fiction. I don't object to this effective public candidacy, but honesty in labeling might be called for. On Dec 18, 2006, at 9:37 AM, Sam Hartman wrote: If I'm reading the following mail correctly, it sounds like the nomcom is requesting feedback from a working group mailing list. In other words anyone who creates a tools.ietf.org account for that address can see the short list of candidates. At that point, shouldn't we just be making the short list public? From: Nomcom06 [EMAIL PROTECTED] Date: December 17, 2006 10:13:51 PM EST To: [EMAIL PROTECTED] Subject: [Pki4ipsec] Nomcom06: Security Area Director Candidate Feedback Security Area Director Candidate Feedback The NomCom solicits your input on the candidates it is reviewing for the Security Area Director position. It is a requirement of the NomCom process that lists of candidates reviewed by the NomCom are to be kept confidential. Therefore, when you receive the list of candidates for review, you MUST keep it confidential and MUST NOT share it with anyone else. The NomCom requests that you provide your input as soon as possible, for full consideration, please have them in no later than the end of the day, Tuesday, January 2, 2007. Your input is a very important aspect of the process through which the NomCom will make its selections for IETF leadership. We encourage you to review the list of candidates you have been asked to comment on and provide us any input that might help us in our selection. Please provide input on as many candidates as you can; input to the effect of I'm not familiar with X is acceptable and useful to the NomCom. This year, the NomCom is accepting input on candidates through a web-based tool. Later in this message, you will find a URL through which you can provide your input. You may be asked for input on multiple positions that are under review by the NomCom. If you are asked for input on multiple positions, you will receive separate e-mail requests for each position. If you prefer to provide anonymous input, please send it directly to the NomCom chair, Andrew Lange, [EMAIL PROTECTED], who will make your input anonymous before forwarding it to the NomCom. Any input you provide, whether it is provided to the NomCom directly through the web-based tool or anonymously, will be kept confidential and will not be shared outside the NomCom. There are names in the lists of candidates for each position who have declined nomination, which are included in the list to help protect the confidentiality of actual candidates. Also, if you are a candidate for a position, your name will not appear in the list of candidates for that position. If you are a candidate for a position, the NomCom will not accept anonymous input from you about other candidates for the same position. The web-based feedback tool gives the NomCom an automated process for collecting input on the NomCom candidates. We hope you will find it more convenient to use as well. Your input will be encrypted before it is stored by the feedback tool, and can only be decrypted by the NomCom. Some individuals may be candidates for multiple positions. If you provide input for such a candidate for one position, the NomCom will see that input for that candidate associated with each of the positions. You may provide additional input for specific positions, by clicking on the candidate's name in the list of candidates for that specific position. The feedback form is available at the following URLs: https://www1.tools.ietf.org/group/nomcom06/input/ Please use your tools.ietf.org login with the email address you have been invited with. If you do not have a tools login, you can get one at this URL: https://www1.tools.ietf.org/newlogin Again, the NomCom emphasizes that, if you use the feedback form to provide input, you MUST keep the list of candidates confidential. When you access the feedback form, you will see a list of all of the candidates you have been asked to comment on. By clicking on a candidate's name, you will be presented with a text-input form into which you can type your input. Note that, because of the way in which the NomCom collected names and e-mail addresses for individuals from whom input is solicited, we may have more than one e-mail address for you and you may receive multiple requests for feedback on the same position. We apologize in advance for any duplicate e-mail you may receive as a part of this feedback solicitation process. Thanks in advance for your feedback. Andrew
Re: draft status links on the wg pages?
Dave Crocker wrote: minor enhancement: Put a link to that page on the working group's main IETF page. There's a link to the Charter, isn't that the old main page ? A working group's main page really is its home page and, therefore, ought to bring together references to all relevant information. The WG pages on the tools' site offer links to more relevant information, therefore I consider this as their new main page. Frank ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: draft status links on the wg pages?
Dave Crocker wrote: Bill Fenner wrote: Mike, Check out http://tools.ietf.org/wg/wgname and see if that gives you the view you're looking for. Bill, thanks. I suspect that's what Michael has in mind, except for one minor enhancement: Put a link to that page on the working group's main IETF page. A working group's main page really is its home page and, therefore, ought to bring together references to all relevant information. Given that the Tools folk have created yet-another useful mechanism, making each working group's page have a link to its related status information now becomes a trivial effort, with substantial benefit. Right, this is really cool -- although a link from the ietf wg page would be nice, the tools version almost looks like wg page v2.0 with a few additions (like the charter, milestones, etc.) cheers, Mike ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: draft status links on the wg pages?
Hi Dave, Frank, on 2006-12-18 17:20 Frank Ellermann said the following: Dave Crocker wrote: minor enhancement: Put a link to that page on the working group's main IETF page. Good idea. And actually already implemented some time ago. Looking at for instance the mip4 charter page, at http://www.ietf.org/html.charters/mip4-charter.html there is a line right above the listing of the Chairs which provides an URL and link: Additional information is available at tools.ietf.org/wg/mip4 I think that's what you were looking for? There's a link to the Charter, isn't that the old main page ? This refers to the link in the opposite direction, from tools.ietf.org to www.ietf.org, which is also good to have, but not what Dave was asking for, I think... Henrik ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: nomcom:Soliciting feedback from entire working groups?
I received four of these, apparently on the strength of being an RFC author, and was immediately sure there had been a mistake. Henning Schulzrinne wrote: Judging from the email addresses where I received solicitations for comments, either every RFC author or every I-D author received an invitation to comment. (I suspect the latter, since the invitations seemed to be tailored by working group, i.e., an I-D in a Transport working group earned an invitation that included Transport candidates.)� Calling a candidate list distributed to all I-D authors private is polite fiction. I don't object to this effective public candidacy, but honesty in labeling might be called for. -- Doug Ewell * Fullerton, California, USA * RFC 4645 * UTN #14 http://users.adelphia.net/~dewell/ http://www1.ietf.org/html.charters/ltru-charter.html http://www.alvestrand.no/mailman/listinfo/ietf-languages ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: draft status links on the wg pages?
Michael Thomas wrote: Given that the Tools folk have created yet-another useful mechanism, making each working group's page have a link to its related status information now becomes a trivial effort, with substantial benefit. Right, this is really cool -- although a link from the ietf wg page would be nice, the tools version almost looks like wg page v2.0 with a few additions (like the charter, milestones, etc.) I hadn't thought of merging the existing wg page with the tools one. I also never noticed that a pointer to the tools page is already on the official wg page. It is right above Chairs, slipping past the eye, after the Last Modified date. I also had entirely missed just how rich the tools page is. The Status page really has two innovations. One is the status information. The other is the page format -- heading anbd side-column. Most IETF pages are organized by information topics. The user gets to figure out what topic to query. And, of course, this is often obvious. Other times, not so much. Although this one's heading uses topic terminology, it actually is organized for working group participant *activity*. True activity-based design tends towards use of verbs rather than nouns, but given the list of links at the page heading, I think it covers all the things a participant would want to get at. (The fact that the charter link is in the middle of the list, rather than the beginning, is a pretty strong indicator that this is more oriented towards participants than towards folks trying to find out about the wg. Of course, it serves the latter folks just fine.) Activity-based GUI design has become a point of focus in the Usability field and seems to be far more productive that the classic style, which leaves it up to the user to figure out how to combine info queries together, to get work done. This page header should become the standard for all pages relating to a working group. (Whether to also make the left-hand column universal for wg-related pages could be debated a bit. My first reaction was not to keep it, but the ability to jump between wgs does seem pretty appealing, and the display real estate cost of the feature isn't onerous.) So my suggestions are: 1. Move these Status pages out of the tools development area and make them an official part of a working group's official pages. 2. Make the header standard for *all* working-group specific pages. 3. Remove the documents list from the WG charter page, since it is redundant with the Status page and less complete. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: nomcom:Soliciting feedback from entire working groups?
Sam Hartman wrote: If I'm reading the following mail correctly, it sounds like the nomcom is requesting feedback from a working group mailing list. In other words anyone who creates a tools.ietf.org account for that address can see the short list of candidates. At that point, shouldn't we just be making the short list public? 1. They are careful to say that the lists that are stuffed with some fake entries. Although I respect the intention, this long-standing technique -- attempting to protect the privacy of actual candidates, is ineffective and wasteful. It is particularly wasteful by having lots of folks asked to provide feedback about people who are not real candidates. 2. Using some method of restricting the query to active wg participants is a good idea. Using the existance of a Tools account is one simple method. It's always worth considering whether there are better criteria that are easy to implement, but the current approach is pretty reasonable. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: ion-ion-store open for public comment
Brian E Carpenter wrote: As for you last sentence, perhaps it should give some pause. The idea that we do not already have a pretty clear idea of what should distinguish an I-D from an ION ought to engender concern. Like any other project consuming significant resources, an experiment is supposed to have reasonably clear statements of differentiation and expected benefit. I personally believe that it is clear in RFC 4693. That's fine, Brian, but at least some of us were confused. That ought to cause some concern. I suspect concern divides between folks like me, who really didn't even understand the scope of the documents intended for this series, and others who remain unclear why the overhead of an entirely new publication mechanism is required. Better writing -- an maybe better labeling -- will fix the former concern. The latter concern is deeper. (I also believe we have a number of process BCPs that contain operational details that don't really belong there, but pre-ION we had no systematic way to handle such details.) Sure. And I wasn't commenting about prior publications. On reflecting about the forces that seem to have led to the creation of the ION experiment, I suspect that there are two concerns: 1) Needing a label that collects together internal operating notes and distinguishes them from other IETF documents, and 2) the overhead of getting an RFC published. The first could be solved easily by adding a new, non-standard-track sub-label to the RFC series and I suspect the latter could be resolved by making an arrangement with the RFC Editor to have IONs go through less handling and proofing overhead. (And, gosh, this might even give a basis for reviewing why RFC publication has become high overhead...) Again - this is exactly what we should discuss at the *end* of the experiment, by which time we'll also have significant experience with the new RFC Editor contract. So you want to develop a community history with a new class of documents called ION that are published independently from any existing mechanism and then later consider re-homing them? This highlights why the term experiment can be misleading. If this sort of experiment is successful, then there will be significant disruption to the user base if the mechanism is moved to a new hosting mechanism. (The irony, here, is that the Arpanet suffered this same problem. Intended and used as an experiment it also immediately became so thoroughly useful as an operational communications infrastructure so that scheduling real experiments became problematic.) d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
CAPWAP Interim Meeting, January 24th 25th
The CAPWAP WG will hold a two-day interim meeting. Here are the details: CAPWAP WG Interim Meeting Wednesday Thursday, January 24 25, 2007 9:00am - 5:00pm (PDT) 3750 Cisco Way (Building 15) San Jose, CA, USA More information about the CAPWAP WG can be found on our charter page: http://www.ietf.org/html.charters/capwap-charter.html More information about the CAPWAP interim meeting, including registration information and a full agenda, will be circulated on the CAPWAP WG mailing list. If you wish to join the CAPWAP mailing list, go to: http://lists.frascone.com/mailman/listinfo/capwap Dan (on behalf of the CAPWAP chairs) ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Nomcom O6 categories -- GEN == Chair?
I assume that the nominee sub-section labeled GEN is really for the IETF Chair? d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Nomcom O6 categories -- GEN == Chair?
--On Monday, December 18, 2006 10:18 AM -0800 Dave Crocker [EMAIL PROTECTED] wrote: I assume that the nominee sub-section labeled GEN is really for the IETF Chair? I think you should assume, given the number of these things that all of us seem to be receiving, that the Nomcom is distributing these notes indiscriminately to people who have developed documents, reviewed documents, or who participate in various mailing lists. I share the concern of some others that we have promised people a confidential process and that this makes short lists (with or without ringers) generally available to anyone interested. Regardless of whether confidentiality is a good idea, it is what the procedures call for and what nominees have been promised. If that is actually what is going on, then, IMO, the bad judgment associated with this decision completely overwhelms the bad judgment associated with redrawing the pool after consulting, among others, potential nominees and candidates. john ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
IETF 68 hotel full
Hi, There is only one hotel listed for IETF 68: http://www3.ietf.org/meetings/68-hotels.html There are no more rooms at the IETF rate, and perhaps at any rate. The online form says no rooms are available that week. I'm having trouble finding Pobrezni 1 186 00 Prague 8 Czech Republic with online maps. Does anybody know which hotels are close to the Hilton Prague? thanks, Andy ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Nomcom 06 feedback kudos
Folks, In my/our usual fashion, we've slipped into engineering refinement discussions about the Nomcom's new mechanism for soliciting feedback, without commenting separately about the basic existence of that effort. So here is an unqualified thank you to the Nomcom folks for seeking to obtain a broader range of input. This represents a fundamental expansion to the scope of those asked to provide comments to Nomcom. I have no idea how the already-overworked Nomcom team can process this additional input, but am delighted at their effort. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Nomcom O6 categories -- GEN == Chair?
Hi Dave, on 2006-12-18 19:18 Dave Crocker said the following: I assume that the nominee sub-section labeled GEN is really for the IETF Chair? Yes. I'll fix that in a moment. Henrik ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IETF 68 hotel full
IIRC the hotel web site has a map. You could use that to find the names of nearby streets. Janet Andy Bierman [EMAIL PROTECTED] wrote on 12/18/2006 01:37:43 PM: Hi, There is only one hotel listed for IETF 68: http://www3.ietf.org/meetings/68-hotels.html There are no more rooms at the IETF rate, and perhaps at any rate. The online form says no rooms are available that week. I'm having trouble finding Pobrezni 1 186 00 Prague 8 Czech Republic with online maps. Does anybody know which hotels are close to the Hilton Prague? thanks, Andy ___ 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: IETF 68 hotel full
Janet P Gunn wrote: IIRC the hotel web site has a map. You could use that to find the names of nearby streets. Really? Where? The one I found didn't have street names. http://www1.hilton.com/en_US/hi/hotel/PRGHITW/directions.do#localmap Janet Andy Andy Bierman [EMAIL PROTECTED] wrote on 12/18/2006 01:37:43 PM: Hi, There is only one hotel listed for IETF 68: http://www3.ietf.org/meetings/68-hotels.html There are no more rooms at the IETF rate, and perhaps at any rate. The online form says no rooms are available that week. I'm having trouble finding Pobrezni 1 186 00 Prague 8 Czech Republic with online maps. Does anybody know which hotels are close to the Hilton Prague? thanks, Andy ___ 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: nomcom:Soliciting feedback from entire working groups?
Hi, Dave Crocker wrote: At that point, shouldn't we just be making the short list public? 1. They are careful to say that the lists that are stuffed with some fake entries. Although I respect the intention, this long-standing technique -- attempting to protect the privacy of actual candidates, is ineffective and wasteful. It is particularly wasteful by having lots of folks asked to provide feedback about people who are not real candidates. I agree. When I was in NomCom two years ago, I was embarrased to see negative, often very personal, feedback given on folks who had just been put on the short list as fake entries. Some of these people had even explicitly turned down their nomination. Of course the NomCom confidentiality rules apply to that feedback and we never discussed it even in the NomCom, but it still felt weird. 2. Using some method of restricting the query to active wg participants is a good idea. Using the existance of a Tools account is one simple method. It's always worth considering whether there are better criteria that are easy to implement, but the current approach is pretty reasonable. Agree here too. I think it would actually be good to have some kind of pre-defined criteria on who is asked for feedback. Otherwise *that* group may lead to bias, for instance there is a lot of input from people active in certain WGs and very little from others. There's also a chance that active NomCom members can insert in this group a lot of people they know to give a certain type of feedback. I would be in favor of making the short lists public. This semi-secrecy is creating a way too much speculation and suspicion. Markus ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IETF 68 hotel full
Andrew G. Malis wrote: You're much better off following this link (but I think you have to use Internet Explorer for it to work): http://local.live.com/default.aspx?v=2cp=50.09292~14.437961style=rlvl=17tilt=-90dir=0alt=-1000rtp=null~null http://local.live.com/default.aspx?v=2cp=50.09292~14.437961style=rlvl=17tilt=-90dir=0alt=-1000rtp=null~null You can very easily see the Hilton. thanks. Somebody sent me a private email and said Friday (3/23) was sold out at the hotel. When I used the online form (and called the 800#), I was trying to checkout on 3/25. When I entered 3/23 as the checkout date in the online form, I was able to get a room at the IETF rate. Cheers, Andy ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IETF 68 hotel full
I'm having trouble finding Pobrezni 1 186 00 Prague 8 Czech Republic with online maps. I believe hotel is toward the west end of the street, near the bridge to the island in the river: http://maps.google.com/maps?f=qhl=ene=UTF8om=1ie=UTF8z=16ll=50.092682,14.443717spn=0.009375,0.016673 On the other hand, the Hilton web site just offered me a room for IETF week at E152 which appears to be the IETF rate, so it's not all that sold out. Regards, John Levine, [EMAIL PROTECTED], Primary Perpetrator of The Internet for Dummies, Information Superhighwayman wanna-be, http://www.johnlevine.com, Mayor More Wiener schnitzel, please, said Tom, revealingly. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: ion-ion-store open for public comment
On Sunday, December 17, 2006 06:05:45 PM -0800 Dave Crocker [EMAIL PROTECTED] wrote: One might want to wonder, a bit, about the IETF's having a growing number of such documents, and that this might make it more difficult to know enough about IETF procedures and the like On the contrary, I don't think the process has gotten any more complex; we just have more documentation about it. Whether that makes it easier or harder to know enough about IETF procedures would seem to depend on the accuracy and currency of that documentation. On reflecting about the forces that seem to have led to the creation of the ION experiment, I suspect that there are two concerns: 1) Needing a label that collects together internal operating notes and distinguishes them from other IETF documents, and 2) the overhead of getting an RFC published. The first could be solved easily by adding a new, non-standard-track sub-label to the RFC series and I suspect the latter could be resolved by making an arrangement with the RFC Editor to have IONs go through less handling and proofing overhead. (And, gosh, this might even give a basis for reviewing why RFC publication has become high overhead...) I don't think it's just about the overhead of getting an RFC _published_; it's about the overhead of achieving IETF consensus on one. Process BCP's should be about IETF-level policy, not the operational practices of the I* or of any other entity that implements those policies. Recently, the Federal Communications Commission in the US adopted a number of changes to regulations governing the Amateur Radio service. The changes were officially published on November 15, and went into effect 30 days later. In between, someone noticed an error which inadvertently made certain operations illegal that should not have been, and asked the FCC to fix it. The fix was approved on December 15, the same day the new regulations became effective, and will probably become effective sometime in February. The same sort of correction would have taken the IETF six months to a year plus a lot of arguing and reopening old issues. A similar correction to an ION would have taken days, at most. And that's sort of the point - overall policy should be set by IETF consensus, but operational details should not. -- Jeff ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: ion-ion-store open for public comment
Jeffrey Hutzelman wrote: One might want to wonder, a bit, about the IETF's having a growing number of such documents, and that this might make it more difficult to know enough about IETF procedures and the like On the contrary, I don't think the process has gotten any more complex; we just have more documentation about it. 1. We used to have far more flexibility about wg process than we now do. Small tasks required small effort. The substantial procedures for creating and running a working group and producing documents that are today typical used to be reserved for larger and more difficult efforts. This includes now tending to require BOFs and tending to require Requirements documents, and so on. 2. The requirements for the form of wg documents have also changed, notably with respect to required boilerplate. In addition, the boilerplate changes with some regularity and the enforcement of the requirements is substantially more stringent. I'm sure the list is longer, but the above seem sufficient for making the point. I don't think it's just about the overhead of getting an RFC _published_; it's about the overhead of achieving IETF consensus on one. Process BCP's should be about IETF-level policy, not the operational practices of the I* or of any other entity that implements those policies. Yes, the rules are different, just as the rules for Informational RFCs are different from standards track RFCs. That's why the idea of a new RFC sub-category make sense. The same sort of correction would have taken the IETF six months to a year plus a lot of arguing and reopening old issues. And then there is the possibility that you are describing a deeper IETF problem that needs its own focus... d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Nomcom06: IAB Member Candidate Feedback
On Dec 17, 2006, at 7:54 PM, Nomcom06 wrote: The NomCom requests that you provide your input as soon as possible, for full consideration, please have them in no later than the end of the day, Tuesday, January 2, 2007. Folks, you might want to consider that it's the week before Christmas. Expecting people to drop what they're doing during the week most of us are scrambling to wrap up work projects before the break, finish Christmas shopping, make travel plans, and execute those travel plans, to meet your January 2 deadline is ... optimistic? -lyndon ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Document Action: 'Network Mobility Support Goals and Requirements' to Informational RFC
The IESG has approved the following document: - 'Network Mobility Support Goals and Requirements ' draft-ietf-nemo-requirements-06.txt as an Informational RFC This document is the product of the Network Mobility Working Group. The IESG contact persons are Jari Arkko and Mark Townsley. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-nemo-requirements-06.txt Technical Summary Network mobility arises when a router connecting a network to the Internet dynamically changes its point of attachment to the Internet thereby causing the reachability of the said network to be changed in relation to the fixed Internet topology. Such kind of network is referred to as a mobile network. With appropriate mechanisms, sessions established between nodes in the mobile network and the global Internet can be maintained after the mobile router changes its point of attachment. This document outlines the goals expected from network mobility support and defines the requirements that must be met by the NEMO Basic Support solution. Working Group Summary There has been significant review and discussion of these documents, and the consensus of the working group is solidly behind the documents. Protocol Quality RFC 3963, NEMO Basic Support protocol was developed and published as an answer to these requirements. There are multiple implementations. This document has been reviewed by Jari Arkko for the IESG. Note to RFC Editor In Section 3.7, s/modidication/modification/ In Section 4, replace R10 with this: R10: The solution MUST be agnostic to the internal configuration. This means the solution will behave the same way if the NEMO is nested, comprises one or several subnets, comprises MNNs which are LFNs, VMNs, LFNs or a mixture of them. Add replace Section 5 with the following contents: Security consideration of the NEMO Basic Support solutions are addressed in RFC 3963. Section 3.9 of this document discusses the security goals for all forms of existing and forthcoming NEMO solutions. Please change MUST, MAY, etc in Section 4 to lower case. Please add a NEW Section 3.12: 3.12 Minimal Impact on Internet Routing Any NEMO solution(s) needs have minimal negative effect on the global Internet routing system. The solution must therefore limit both the amount of information that must be injected into Internet routing, as well as the dynamic changes in the information that is injected into the global routing system. As one example of why this is necessary, consider the approach of advertising each mobile network's connectivity into BGP, and for every movement withdrawing old routes and injecting new routes. If there were tens of thousands of mobile networks each advertising and withdrawing routes, for example, at the speed that an airplane can move from one ground station to another, the potential effect on BGP could be very unfortunate. In this example the total amount of routing information advertised into BGP may be acceptable, but the dynamic instability of the information (ie, the number of changes over time) would be unacceptable. And finally, add a NEW requirement to the end of Section 4: R17: The solution should have a minimal impact on the global Internet routing system. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
Document Action: 'TCP Friendly Rate Control (TFRC): the Small-Packet (SP) Variant' to Experimental RFC
The IESG has approved the following document: - 'TCP Friendly Rate Control (TFRC): the Small-Packet (SP) Variant ' draft-ietf-dccp-tfrc-voip-07.txt as an Experimental RFC This document is the product of the Datagram Congestion Control Protocol Working Group. The IESG contact persons are Lars Eggert and Magnus Westerlund. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dccp-tfrc-voip-07.txt Technical Summary This document proposes a mechanism for further experimentation, but not for widespread deployment at this time in the global Internet. TCP-Friendly Rate Control (TFRC) is a congestion control mechanism for unicast flows operating in a best-effort Internet environment [RFC3448]. TFRC was intended for applications that use a fixed packet size, and was designed to be reasonably fair when competing for bandwidth with TCP connections using the same packet size. This document proposes TFRC-SP, a Small-Packet (SP) variant of TFRC, that is designed for applications that send small packets. The design goal for TFRC-SP is to achieve the same bandwidth in bps (bits per second) as a TCP flow using packets of up to 1500 bytes. TFRC-SP enforces a minimum interval of 10 ms between data packets, to prevent a single flow from sending small packets arbitrarily frequently. Flows using TFRC-SP compete reasonably fairly with large-packet TCP and TFRC flows in environments where large-packet flows and small- packet flows experience similar packet drop rates. However, in environments where small-packet flows experience lower packet drop rates than large-packet flows (e.g., with Drop-Tail queues in units of bytes), TFRC-SP can receive considerably more than its share of the bandwidth. Working Group Summary This document is a chartered item of the DCCP WG. The document provides a description of an experimental method to provide congestion control that is based on TFRC, but is adapted to sources that transmit small fixed-sized packets at a fixed rate. The document also provides simulation results to demonstrate the fairness with other IETF-defined transport protocols and may serve as a basis for future congestion control methods. Protocol Quality The document defines a new experimental algorithm. Further experimentation is required to understand the implications of implementation, its suitability to specific applications and the deployment within the general Internet. Gorry Fairhurst was the PROTO Document Shepherd and Lars Eggert has reviewed this document for the IESG. Note to RFC Editor Section 3 (feedback from Magnus): OLD: If the TFRC implementation knows that the IP layer is using IPv6 instead of IPv4, then the connection using TFRC-SP MAY use an estimate of 40 bytes instead of 60 bytes for H, for simplicity of implementation. NEW: However, if the TFRC implementation knows that the IP layer is using IPv6 instead of IPv4, then the connection using TFRC-SP MAY still use the default estimate of 40 bytes for H instead of the actual size of 60 bytes, for simplicity of implementation. Section 4.5.1 (from Miguel Garcia): OLD: this environments, the sending rate in bytes per RTT is roughly 1.2 NEW: these environments, the sending rate in bytes per RTT is roughly 1.2 ^ Section 4.5.3 (from Lars): OLD: bytes (becauses the path MTU is known to be less than 576 bytes), NEW: bytes (because the path MTU is known to be less than 576 bytes), ^^^ Section 12 (nit from Miguel Garcia): OLD: for feedback on earlier versions of this draft. NEW: for feedback on earlier versions of this document. Section 9 (from secdir review by Juergen Quittek): OLD: There are no security considerations introduced in this document. General security considerations for TFRC are discussed in RFC 3448. The security considerations for TFRC include the need to protect against spoofed feedback, and the need for protection mechanisms to protect the congestion control mechanisms against incorrect information from the receiver. Security considerations for DCCP's Congestion Control ID 3, TFRC Congestion Control, are discussed in [RFC4342]. That document extensively discussed the mechanisms the sender can use to verify the information sent by the receiver. NEW: There are no new security considerations introduced in this document. The issues of the fairness of TFRC-SP with standard TFRC and TCP in a range of environments, including those with byte-based queue management at the congested routers, are discussed extensively in the main body of this document. General security considerations for TFRC are discussed in RFC 3448. As with TFRC in RFC 3448,
Protocol Action: 'Exclude Routes - Extension to RSVP-TE' to Proposed Standard
The IESG has approved the following document: - 'Exclude Routes - Extension to RSVP-TE ' draft-ietf-ccamp-rsvp-te-exclude-route-06.txt as a Proposed Standard This document is the product of the Common Control and Measurement Plane Working Group. The IESG contact persons are Ross Callon and Bill Fenner. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-rsvp-te-exclude-route-06.txt Technical Summary In some networks where precise explicit paths are not computed at the head end it may be useful to specify and signal abstract nodes and resources that are to be explicitly excluded from routes. These exclusions may apply to the whole path, or to parts of a path between two abstract nodes specified in an explicit path. How Shared Risk Link Groups (SLRGs) can be excluded is also specified in this document. This document specifies ways to communicate route exclusions during path setup using RSVP-TE. Working Group Summary no reports of any dissent Protocol Quality Ross Callon has reviewed this for the IESG, and Eric Gray has provided Gen-ART review comments. The document has been updated in response to Eric's and Ross' comments. I know of at least one implementation with some deployment, and I suspect that there is more than one implementation. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
Protocol Action: 'Padding Chunk and Parameter for SCTP' to Proposed Standard
The IESG has approved the following document: - 'Padding Chunk and Parameter for SCTP ' draft-ietf-tsvwg-sctp-padding-02.txt as a Proposed Standard This document is the product of the Transport Area Working Group Working Group. The IESG contact persons are Lars Eggert and Magnus Westerlund. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-sctp-padding-02.txt Technical Summary This document defines a padding chunk and a padding parameter and describes the required receiver side procedures. The main purpose of the padding chunk and parameter are for path-MTU discovery. Working Group Summary There is strong consensus in the WG to publish this document. It has been reviewed by several people in the WG last call. Protocol Quality James Polk was the PROTO Document Shepherd for this document. Lars Eggert reviewed this document for the iESG. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
RFC 4742 on Using the NETCONF Configuration Protocol over Secure SHell (SSH)
A new Request for Comments is now available in online RFC libraries. RFC 4742 Title: Using the NETCONF Configuration Protocol over Secure SHell (SSH) Author: M. Wasserman, T. Goddard Status: Standards Track Date: December 2006 Mailbox:[EMAIL PROTECTED], [EMAIL PROTECTED] Pages: 10 Characters: 17807 Updates/Obsoletes/SeeAlso: None I-D Tag:draft-ietf-netconf-ssh-06.txt URL:http://www.rfc-editor.org/rfc/rfc4742.txt This document describes a method for invoking and running the Network Configuration Protocol (NETCONF) within a Secure Shell (SSH) session as an SSH subsystem. [STANDARDS TRACK] This document is a product of the Network Configuration Working Group of the IETF. This is now a Proposed Standard Protocol. STANDARDS TRACK: 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. The RFC Editor Team USC/Information Sciences Institute ... ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
RFC 4743 on Using NETCONF over the Simple Object Access Protocol (SOAP)
A new Request for Comments is now available in online RFC libraries. RFC 4743 Title: Using NETCONF over the Simple Object Access Protocol (SOAP) Author: T. Goddard Status: Standards Track Date: December 2006 Mailbox:[EMAIL PROTECTED] Pages: 20 Characters: 39734 Updates/Obsoletes/SeeAlso: None I-D Tag:draft-ietf-netconf-soap-08.txt URL:http://www.rfc-editor.org/rfc/rfc4743.txt The Network Configuration Protocol (NETCONF) is applicable to a wide range of devices in a variety of environments. Web Services is one such environment and is presently characterized by the use of the Simple Object Access Protocol (SOAP). NETCONF finds many benefits in this environment: from the reuse of existing standards, to ease of software development, to integration with deployed systems. Herein, we describe SOAP over HTTP and SOAP over Blocks Exchange Extensible Protocol (BEEP) bindings for NETCONF. [STANDARDS TRACK] This document is a product of the Network Configuration Working Group of the IETF. This is now a Proposed Standard Protocol. STANDARDS TRACK: 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. The RFC Editor Team USC/Information Sciences Institute ... ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
RFC 4733 on RTP Payload for DTMF Digits, Telephony Tones, and Telephony Signals
A new Request for Comments is now available in online RFC libraries. RFC 4733 Title: RTP Payload for DTMF Digits, Telephony Tones, and Telephony Signals Author: H. Schulzrinne, T. Taylor Status: Standards Track Date: December 2006 Mailbox:[EMAIL PROTECTED], [EMAIL PROTECTED] Pages: 49 Characters: 115614 Obsoletes: RFC2833 See-Also: I-D Tag:draft-ietf-avt-rfc2833bis-15.txt URL:http://www.rfc-editor.org/rfc/rfc4733.txt This memo describes how to carry dual-tone multifrequency (DTMF) signalling, other tone signals, and telephony events in RTP packets. It obsoletes RFC 2833. This memo captures and expands upon the basic framework defined in RFC 2833, but retains only the most basic event codes. It sets up an IANA registry to which other event code assignments may be added. Companion documents add event codes to this registry relating to modem, fax, text telephony, and channel-associated signalling events. The remainder of the event codes defined in RFC 2833 are conditionally reserved in case other documents revive their use. This document provides a number of clarifications to the original document. However, it specifically differs from RFC 2833 by removing the requirement that all compliant implementations support the DTMF events. Instead, compliant implementations taking part in out-of-band negotiations of media stream content indicate what events they support. This memo adds three new procedures to the RFC 2833 framework: subdivision of long events into segments, reporting of multiple events in a single packet, and the concept and reporting of state events. [STANDARDS TRACK] This document is a product of the Audio/Video Transport Working Group of the IETF. This is now a Proposed Standard Protocol. STANDARDS TRACK: 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. The RFC Editor Team USC/Information Sciences Institute ... ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
RFC 4741 on the NETCONF Configuration Protocol
A new Request for Comments is now available in online RFC libraries. RFC 4741 Title: NETCONF Configuration Protocol Author: R. Enns, Ed. Status: Standards Track Date: December 2006 Mailbox:[EMAIL PROTECTED] Pages: 95 Characters: 173914 Updates/Obsoletes/SeeAlso: None I-D Tag:draft-ietf-netconf-prot-12.txt URL:http://www.rfc-editor.org/rfc/rfc4741.txt The Network Configuration Protocol (NETCONF) defined in this document provides mechanisms to install, manipulate, and delete the configuration of network devices. It uses an Extensible Markup Language (XML)-based data encoding for the configuration data as well as the protocol messages. The NETCONF protocol operations are realized on top of a simple Remote Procedure Call (RPC) layer. [STANDARDS TRACK] This document is a product of the Network Configuration Working Group of the IETF. This is now a Proposed Standard Protocol. STANDARDS TRACK: 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. The RFC Editor Team USC/Information Sciences Institute ... ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
