Finding issue trackers for drafts
Hi. One additional piece of information relating to drafts that ism't included in the drafts database is the location of the issue tracker (if any). They aren't all in one place at the moment which makes life more difficult than necessary for the casual inspector... for example... - I was just faced with an email relating to a l2vpn document which I reviewed for the gen-art team which stated that 'there were some issues in the issue tracker' but no note of where I could locate the tracker. Now clearly I can bug the authors but I am sure they have better things to do. - I know where to find some of the nsis issue trackers but I also know they aren't obvious to a casual observer. So two thoughts: - Could this information be collated on the info pages (subject to a good way of finding it out)? - Would it be a good idea to incorporate the location of the issue tracker into drafts as a matter of course (might even encourage their use)? xml2rfc might be able to provide some sort of support perhaps but that isn't essential. Regards, Elwyn ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: IETF65 hotel location
Dave Crocker write: the questionnaire will not serve to understand the needs of people who are *unable to attend* Perhaps we should ask a more open-ended question (i.e. B below): A) Did you attend IETF-65? B) If not, why not? Regards, Ed -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Dave Crocker Sent: Sunday, January 29, 2006 9:26 PM To: Marshall Eubanks Cc: ietf@ietf.org Subject: Re: IETF65 hotel location However, to be constructive, I would like to suggest adding two yes or no questions to the next meeting questionnaire : A.) Do you feel that the venue chosen for the meeting was too remote, in terms of accessibility of restaurants, bars, your or other hotels, etc. ? B.) (If A is answered yes.) Would having another IETF meeting in a site that is similarly remote make it less likely that you would attend ? Asking questions like this could be quite useful. The challenge is in making sure that the right people get asked. If the questions are asked of people who already attended the meeting, then the sampling is of people with the resources to accommodate the current style of meeting arrangement. While some might grouse about one characteristic or another of the current choices, the questionnaire will not serve to understand the needs of people who are *unable to attend* IETF meetings because of current costs, due to remoteness, hotel fees, or the like. (By the way, the what will make it less likely you will attend type of question is often interesting to ask, but is usually not a good predictor of actual behavior.) d/ -- Dave Crocker Brandenburg InternetWorking http://bbiw.net ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IETF65 hotel location
Dear Ed; This might also be a useful question to ask; it might be better to make it multiple choice along the lines of (B. If not, because of - general expense - registration fees - difficulty in arranging visa's or other travel preparations - interference from other meetings or work schedule - location of the meeting city - location of the meeting venue ) However, that wasn't quite what I was suggesting. I have heard this issue of nearby access to stuff come up before, and I know some people consider it quite important, so much so that certain locations might be ruled out just for only having venues that are too isolated in their urban context. So, in the context of a location that may be considered isolated, I think it might be useful to consider this an experiment, and judge the reaction of the community after the meeting towards this variable. Note that this would require polling those who attended, rather than those who did not. Regards Marshall On Jan 30, 2006, at 8:59 AM, Ed Juskevicius wrote: Dave Crocker write: the questionnaire will not serve to understand the needs of people who are *unable to attend* Perhaps we should ask a more open-ended question (i.e. B below): A) Did you attend IETF-65? B) If not, why not? Regards, Ed -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Dave Crocker Sent: Sunday, January 29, 2006 9:26 PM To: Marshall Eubanks Cc: ietf@ietf.org Subject: Re: IETF65 hotel location However, to be constructive, I would like to suggest adding two yes or no questions to the next meeting questionnaire : A.) Do you feel that the venue chosen for the meeting was too remote, in terms of accessibility of restaurants, bars, your or other hotels, etc. ? B.) (If A is answered yes.) Would having another IETF meeting in a site that is similarly remote make it less likely that you would attend ? Asking questions like this could be quite useful. The challenge is in making sure that the right people get asked. If the questions are asked of people who already attended the meeting, then the sampling is of people with the resources to accommodate the current style of meeting arrangement. While some might grouse about one characteristic or another of the current choices, the questionnaire will not serve to understand the needs of people who are *unable to attend* IETF meetings because of current costs, due to remoteness, hotel fees, or the like. (By the way, the what will make it less likely you will attend type of question is often interesting to ask, but is usually not a good predictor of actual behavior.) d/ -- Dave Crocker Brandenburg InternetWorking http://bbiw.net ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: IETF65 hotel location
David, As I understand it, it would be a man-in-the-middle attack if you sat at a table and ordered a Burrito from a person you thought was a waiter. That person then goes to the counter, orders two burritos and a large coffee, to go. They then deliver one Burrito to you, along with the bill, and takes the other Burrito and the coffee with them. What you describe is more like high-jacking the transport mechanism... -- Eric -- -Original Message- -- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] -- On Behalf Of David B Harrington -- Sent: Saturday, January 28, 2006 1:12 PM -- To: 'Spencer Dawkins'; ietf@ietf.org -- Subject: RE: IETF65 hotel location -- -- Hi, -- -- This conversation of the IETF65 location started with an issue of -- security. -- -- I'd like to get this discussion back on track. -- What are the security requirements for a distributed burrito -- processing protocol? -- If you are traveling from the conference hotel to a -- restaurant and are -- mugged, is that considered a man-in-the-middle attack? -- -- dbh -- -- -Original Message- -- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On -- Behalf Of Spencer Dawkins -- Sent: Friday, January 27, 2006 3:26 PM -- To: ietf@ietf.org -- Subject: Re: IETF65 hotel location -- -- Hi, Mike, -- -- If we could morph it into a signup system that -- distributed people -- according to restauant capacity and avoided the problem -- that someone -- says I hear there's a burrito place on X street and a herd of -- 300 -- IETFers shows up there, since they don't know any other -- places to go, -- then you'd really have something. -- -- I'm afraid it's beyond IETF's expertise to come up with -- distributed burrito processing protocols. -- -- Mike -- -- If you think about this for a minute, you would realize that -- (1) we not only -- have protocols for this, but we have running code, and (2) -- too much focus -- on distributed burrito processing might explain a lot about -- where we are -- and how we got here! :-) -- -- Thanks, -- -- Spencer, who is wondering what a dining protocol designers -- multitasking -- algorithm might look like, with a burrito between every pair -- of protocol -- designers (with apologies to the dining philosophers) -- -- -- -- ___ -- Ietf mailing list -- Ietf@ietf.org -- https://www1.ietf.org/mailman/listinfo/ietf -- -- -- -- -- ___ -- Ietf mailing list -- Ietf@ietf.org -- https://www1.ietf.org/mailman/listinfo/ietf -- ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Meeting Survey Results
Hi David, I'm not really sure if we are able to completely understand each other, may be my fault with my poor English. I'm not saying anyone is enforcing one or the other protocol, I just say that it may be wrong to assume, even if we believe that a is better, that it will work if almost everyone move to a. And then we will have recommended everyone to invest in something that was not so useful ... I'm not enforcing the NOC to make a b/g network, especially once has been explained why a seems to be better. On the other way around, I'm sure that they are doing the best that can be done, absolutely no doubt on that. Once more, some times providing details could be more helpful than just decisions w/o explanations about why. Let's close this here, please. Regards, Jordi De: David Kessens [EMAIL PROTECTED] Responder a: [EMAIL PROTECTED] Fecha: Wed, 25 Jan 2006 19:03:01 -0800 Para: JORDI PALET MARTINEZ [EMAIL PROTECTED] CC: ietf@ietf.org ietf@ietf.org Asunto: Re: Meeting Survey Results Jordi, On Wed, Jan 25, 2006 at 05:47:17PM -0400, JORDI PALET MARTINEZ wrote: I understand your point, which somehow has been replied by some other comments in the list such as: - Is not so clear that this technology (a) will still work if all use it. - We are asking to change to 75% of the attendees. I don't understand why you keep harping on this issue that only exists because you have misread our announcement. We have been very forthcoming and clear why we like people to bring 802.11a cards. We are not forcing anybody to use 802.11a and there is absolutely no talk of not providing 802.11b wireless access. We *RECOMMEND* that people bring and use 802.11a gear because we believe that *EVERYBODY*, including people who only have 802.11b cards, will have a better network experience. The only thing that we should have mentioned, but that we overlooked as most cards/dongles on the market now do 802.11a,bg, is that we don't recommend to leave your 802.11b equipment at home. The hotel is very large and there will be areas in the fringes that will have better 802.11b coverage or that are only covered by the hotels own 802.11b service. - 50USD may be a lot for some people. You can easily get cards *LESS* than US$50. It is your judgement call whether you believe that this investment is worth it. Don't buy a 802.11a card/dongle if you think it is too much. Nobody forces you to buy one. David Kessens --- ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ** The IPv6 Portal: http://www.ipv6tf.org Barcelona 2005 Global IPv6 Summit Slides available at: http://www.ipv6-es.com This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Interim meetings planning [was Softwires Interim Meeting]
Hi John, Thanks for your input. See below, in-line. Regards, Jordi De: John C Klensin [EMAIL PROTECTED] Responder a: [EMAIL PROTECTED] Fecha: Thu, 26 Jan 2006 16:53:51 -0500 Para: [EMAIL PROTECTED] CC: ietf@ietf.org ietf@ietf.org Asunto: Re: Interim meetings planning [was Softwires Interim Meeting] Jordi, Let me make a very general observation, based on my experience with the IETF. Where administrative procedures are concerned, the IETF functions well when the IESG is given general guidance by the community but then applies good judgment and discretion to the situations that arise. If the community observes that the IESG's judgment is not good enough, we readjust the general guidance -- by complaints to individual ADs, by notes to the IESG, by discussion on the IETF list, or even via appeals if that is needed. If one or more specific ADs regularly abuse that discretionary authority, they get abused in return on mailing lists, in plenaries, in discussions with nomcoms, and, if necessary, by recalls or at least serious discussions of recalls. Agree, but I feel that there is a lack of administrative procedure here, which already caused some troubles. I'm trying to avoid repeating mistakes, improving the guidance and making sure the process is more open and fair. I fear that in this kind of situation (an Interim meeting unfairly setup), an appeal will not sort out the problem. By contrast, when we try to write down the specific rules that should be applied, or the list of rules or steps they should use in making decisions, and try to reach consensus on them, two things happen, and happen over and over again: (1) We spend (I would say waste, but you may reasonably disagree) a huge amount of time discussing both the details of the proposals and whether or not the proposals are appropriate. In my personal opinion, the IETF would be a better and more effective place to get work done if a higher percentage of the community's energy went into technical work than into discussions of procedural details. Agree in that we need more people, and working more in technical documents, but we like it or not, procedures are needed to make sure that the technical work can be followed up. Otherwise, we may break our main rule: consensus, not sure if say here also fairness. (2) We get the details wrong, resulting in more time being spent correcting the details of the rules that, IMO, we might have been better off not having in the first place. I really much prefer to avoid problems when they may be too late to get recovered. Details need to be put in place for that. In addition, if we get the details seriously wrong, the IESG has historically responded by applying a meta-rule. That meta-rule is that their first obligation is to keep the IETF functioning. And, on that basis, once they conclude that whatever has been written down and established by consensus makes no sense, they simply ignore ignore it. That action creates a very unhappy and unhealthy environment, whether it is appealed or not, but often may still be better than the alternative. Not really sure if I've seen a case like the one that you describe, but really doubt it may be the case for what I'm proposing. So, for a case like this, I suggest that you might want to have a conversation, with any AD you think is likely to listen, about whether the present guidance is sufficient and whether additional guidance or discussion would help. ADs persuading other ADs about IESG matters and customs can be far more effective than any of us writing I-Ds to pin down details. If there are no ADs with whom you feel that you can have such a conversation, then I think you need to chat with the Nomcom but I, at least, have generally found ADs to be receptive on these sorts of issues... even ADs with whom I generally don't get along well (not that there are any of those on the current IESG). Agree, and indeed my proposal was the outcome of a few email exchange with an AD ;-) He actually suggested to include this in the venue-selection-criteria document, which for me, and also talking to others, was not the best choice ... Let's try to avoid yet another round of stretched-out discussions on, e.g., how many days constitutes adequate notice, how to measure the accessibility of a location, what conditions are sufficient to justify an exception, and whatever other questions start to arise as soon as one tries to lock down specific rules. If an interim meeting is announced that is likely to cause specific harm (as distinct from being an issue of principles about dates and locations), complain to the relevant AD and, if necessary, appeal the decision to approve the meeting. But most of us, yourself certainly included, have more productive things to do with our time than starting another one of these procedural debate threads. Just my opinion, of course. And thanks a lot for
Re: IETF65 hotel location
I don't understand why this discussion keeps going on and on, much less why it started in the first place. Folks, surely we have more important issues of Internet technology to talk about, rather than jaw-boning about a task that we have delegated to a competant organization. That organization has in general done an excellent job over the past many years, and I for one am confident they will continue. They are sensitive to input, but they get the job done. Site selection and contracting requires a difficult balancing act to perform, between the ideal and the real. As far as I can see, they do a much better job of than the IETF could possibly hope for. I am thankful for their dedication and expertise. Let's stop spending our resources micro-managing the Secretariat, and deal with the problems that we are supposed to be solving. Bob Braden ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IETF65 hotel location
So, in the context of a location that may be considered isolated, I think it might be useful to consider this an experiment, and judge the reaction of the community after the meeting towards this variable. A reasonable question, but it probably needs to be picked out a little more than that. For us self-employed weenies, the price of the trip is an issue, and part of the problem of isolated hotels is that they tend to have restaurants where the burger costs $23.95 and takes an hour to arrive. In this case, there are cheaper hotels nearby, but unless you want to eat at Denny's, the culinary and options are thin. R's, John ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IETF65 hotel location
Bob Braden wrote: I don't understand why this discussion keeps going on and on, much less why it started in the first place. perhaps the difficulty is that you do not suffer from the problems being discussed. that is fine for you, but it does not make the problems small or secondary. when an issue is raised repeatedly, by many different people, it almost always has some degree of inherent legitimacy. that makes it worth attending to. some tactical problems have strategic impact. in this case, decisions which well might serve to make the ietf less inclusive ought to be taken seriously. it used to be relatively easy and inexpensive to attend ietf meetings. this no longer holds. that excludes keeps potentially useful participants. d/ -- Dave Crocker Brandenburg InternetWorking http://bbiw.net ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IETF65 hotel location
At 12:25 PM 1/30/2006, John Levine wrote: So, in the context of a location that may be considered isolated, I think it might be useful to consider this an experiment, and judge the reaction of the community after the meeting towards this variable. A reasonable question, but it probably needs to be picked out a little more than that. For us self-employed weenies, the price of the trip is an issue, and part of the problem of isolated hotels is that they tend to have restaurants where the burger costs $23.95 and takes an hour to arrive. In this case, there are cheaper hotels nearby, but unless you want to eat at Denny's, the culinary and options are thin. I'll echo John's sentiments, also being self-employed. My IETF participation is spotty at best of late based on the expense. Also being vegan, some locales can be especially difficult. (Memphis was sure a challenge). I still have a hard time thinking of a better place than Minneapolis in wintertime. The hotel costs weren't bad, and who knew Minneapolis was one of the most vegan and vegetarian friendly places in the US? ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IETF65 hotel location
I've abstained myself to comment on this thread until now ... I prefer not to judge until I actually visit the venue and see the real situation, because it will be unfair to discover that this venue has been selected being distant to downtown, when this was the excuse given to me for not accepting Madrid, which has been proposed since 2001. Then we had San Diego, which was a much better case, and I though it will never again happen ... Will see ... The point here is: 1) I agree with Dave: something that is being commented repeatedly ... Means is not satisfying people and may be a real problem 2) Those that are expressing opinions on this thread, may be will like to provide further inputs to a document in the scope of this thread, which has been developed precisely to cope with this issues: http://www.ietf.org/internet-drafts/draft-palet-ietf-meeting-venue-selection -criteria-04.txt Regards, Jordi De: Dave Crocker [EMAIL PROTECTED] Organización: Brandenburg InternetWorking Responder a: [EMAIL PROTECTED] Fecha: Mon, 30 Jan 2006 10:41:08 -0800 Para: Bob Braden [EMAIL PROTECTED] CC: ietf@ietf.org ietf@ietf.org Asunto: Re: IETF65 hotel location Bob Braden wrote: I don't understand why this discussion keeps going on and on, much less why it started in the first place. perhaps the difficulty is that you do not suffer from the problems being discussed. that is fine for you, but it does not make the problems small or secondary. when an issue is raised repeatedly, by many different people, it almost always has some degree of inherent legitimacy. that makes it worth attending to. some tactical problems have strategic impact. in this case, decisions which well might serve to make the ietf less inclusive ought to be taken seriously. it used to be relatively easy and inexpensive to attend ietf meetings. this no longer holds. that excludes keeps potentially useful participants. d/ -- Dave Crocker Brandenburg InternetWorking http://bbiw.net ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ** The IPv6 Portal: http://www.ipv6tf.org Barcelona 2005 Global IPv6 Summit Slides available at: http://www.ipv6-es.com This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: I-D ACTION:draft-hartman-mailinglist-experiment-00.txt
Joel == Joel M Halpern [EMAIL PROTECTED] writes: Joel As I read the description of the experiment, when the IESG Joel decides on the appropriate response to a specific case, they Joel can decide whether that response is a single-list response Joel or a multi-list response. That was my intent. Note there are roughly three responses: 1) Ban from list foo 2) Ban from list foo and bar but no others 3) Ban from list foo, and bar; lists in the set baz can also ban without iesg involvement. I'd be happy to drop 3 as an option for this experiment if there is community support. I'd also be happy to keep 3 as an option. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Last Call: 'Multimedia Terminal Adapter (MTA) Management Information Base for PacketCable and IPCablecom compliant devices' to Proposed Standard
The IESG has received a request from the IP over Cable Data Network WG to consider the following document: - 'Multimedia Terminal Adapter (MTA) Management Information Base for PacketCable and IPCablecom compliant devices ' draft-ietf-ipcdn-pktc-mtamib-09.txt as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by 2006-02-13. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-ipcdn-pktc-mtamib-09.txt ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
RFC 4372 on Chargeable User Identity
A new Request for Comments is now available in online RFC libraries. RFC 4372 Title: Chargeable User Identity Author: F. Adrangi, A. Lior, J. Korhonen, J. Loughney Status: Standards Track Date: January 2006 Mailbox:[EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] Pages: 10 Characters: 21555 Updates/Obsoletes/SeeAlso: None I-D Tag:draft-ietf-radext-chargeable-user-id-06.txt URL:http://www.rfc-editor.org/rfc/rfc4372.txt This document describes a new Remote Authentication Dial-In User Service (RADIUS) attribute, Chargeable-User-Identity. This attribute can be used by a home network to identify a user for the purpose of roaming transactions that occur outside of the home network. [STANDARDS TRACK] This document is a product of the RADIUS EXTensions 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. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... A new Request for Comments is now available in online RFC libraries. RFC 4372 Title: Chargeable User Identity Author: F. Adrangi, A. Lior, J. Korhonen, J. Loughney Status: Standards Track Date: January 2006 Mailbox:[EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] Pages: 10 Characters: 21555 Updates/Obsoletes/SeeAlso: None I-D Tag:draft-ietf-radext-chargeable-user-id-06.txt URL:http://www.rfc-editor.org/rfc/rfc4372.txt This document describes a new Remote Authentication Dial-In User Service (RADIUS) attribute, Chargeable-User-Identity. This attribute can be used by a home network to identify a user for the purpose of roaming transactions that occur outside of the home network. [STANDARDS TRACK] This document is a product of the RADIUS EXTensions 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. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... ___ IETF-Announce mailing list IETF-Announce@ietf.org
RFC 4369 on Definitions of Managed Objects for Internet Fibre Channel Protocol (iFCP)
A new Request for Comments is now available in online RFC libraries. RFC 4369 Title: Definitions of Managed Objects for Internet Fibre Channel Protocol iFCP Author: K. Gibbons, C. Monia, J. Tseng, F. Travostino Status: Standards Track Date: January 2006 Mailbox:[EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] Pages: 29 Characters: 59354 Updates/Obsoletes/SeeAlso: None I-D Tag:draft-ietf-ips-ifcp-mib-07.txt URL:http://www.rfc-editor.org/rfc/rfc4369.txt The iFCP protocol (RFC 4172) provides Fibre Channel fabric functionality on an IP network in which TCP/IP switching and routing elements replace Fibre Channel components. The iFCP protocol is used between iFCP Gateways. This document provides a mechanism to monitor and control iFCP Gateway instances, and their associated sessions, using SNMP. [STANDARDS TRACK] This document is a product of the IP Storage 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. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... A new Request for Comments is now available in online RFC libraries. RFC 4369 Title: Definitions of Managed Objects for Internet Fibre Channel Protocol iFCP Author: K. Gibbons, C. Monia, J. Tseng, F. Travostino Status: Standards Track Date: January 2006 Mailbox:[EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] Pages: 29 Characters: 59354 Updates/Obsoletes/SeeAlso: None I-D Tag:draft-ietf-ips-ifcp-mib-07.txt URL:http://www.rfc-editor.org/rfc/rfc4369.txt The iFCP protocol (RFC 4172) provides Fibre Channel fabric functionality on an IP network in which TCP/IP switching and routing elements replace Fibre Channel components. The iFCP protocol is used between iFCP Gateways. This document provides a mechanism to monitor and control iFCP Gateway instances, and their associated sessions, using SNMP. [STANDARDS TRACK] This document is a product of the IP Storage 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
RFC 4373 on Lightweight Directory Access Protocol (LDAP) Bulk Update/Replication Protocol (LBURP)
A new Request for Comments is now available in online RFC libraries. RFC 4373 Title: Lightweight Directory Access Protocol LDAP Bulk Update Replication Protocol LBURP Author: R. Harrison, J. Sermersheim, Y. Dong Status: Informational Date: January 2006 Mailbox:[EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] Pages: 16 Characters: 31091 Updates/Obsoletes/SeeAlso: None I-D Tag:draft-rharrison-lburp-05.txt URL:http://www.rfc-editor.org/rfc/rfc4373.txt The Lightweight Directory Access Protocol (LDAP) Bulk Update/Replication Protocol (LBURP) allows an LDAP client to perform a bulk update to an LDAP server. The protocol frames a sequenced set of update operations within a pair of LDAP extended operations to notify the server that the update operations in the framed set are related in such a way that the ordering of all operations can be preserved during processing even when they are sent asynchronously by the client. Update operations can be grouped within a single protocol message to maximize the efficiency of client-server communication. The protocol is suitable for efficiently making a substantial set of updates to the entries in an LDAP server. This memo provides information for the Internet community. INFORMATIONAL: 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 ... A new Request for Comments is now available in online RFC libraries. RFC 4373 Title: Lightweight Directory Access Protocol LDAP Bulk Update Replication Protocol LBURP Author: R. Harrison, J. Sermersheim, Y. Dong Status: Informational Date: January 2006 Mailbox:[EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] Pages: 16 Characters: 31091 Updates/Obsoletes/SeeAlso: None I-D Tag:draft-rharrison-lburp-05.txt URL:http://www.rfc-editor.org/rfc/rfc4373.txt The Lightweight Directory Access Protocol (LDAP) Bulk Update/Replication Protocol (LBURP) allows an LDAP client to perform a bulk update to an LDAP server. The protocol frames a sequenced set of update operations within a pair of LDAP extended operations to notify the server that the update operations in the framed set are related in such a way that the ordering of all operations can be preserved during processing even when they are sent asynchronously by the client. Update operations can be grouped within a single protocol message to maximize the efficiency of client-server communication. The protocol is suitable for efficiently making a substantial set of updates to the entries in an LDAP server. This memo provides information for the Internet community. INFORMATIONAL: 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
RFC 4357 on Additional Cryptographic Algorithms for Use with GOST 28147-89, GOST R 34.10-94, GOST R 34.10-2001, and GOST R 34.11-94 Algorithms
A new Request for Comments is now available in online RFC libraries. RFC 4357 Title: Additional Cryptographic Algorithms for Use with GOST 28147-89 GOST R 34 10-94 GOST R 34 10-2001 and GOST R 34 11-94 Algorithms Author: V. Popov, I. Kurepkin, S. Leontiev Status: Informational Date: January 2006 Mailbox:[EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] Pages: 51 Characters: 114564 Updates/Obsoletes/SeeAlso: None I-D Tag:draft-popov-cryptopro-cpalgs-04.txt URL:http://www.rfc-editor.org/rfc/rfc4357.txt This document describes the cryptographic algorithms and parameters supplementary to the original GOST specifications, GOST 28147-89, GOST R 34.10-94, GOST R 34.10-2001, and GOST R 34.11-94, for use in Internet applications. This memo provides information for the Internet community. INFORMATIONAL: 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 ... A new Request for Comments is now available in online RFC libraries. RFC 4357 Title: Additional Cryptographic Algorithms for Use with GOST 28147-89 GOST R 34 10-94 GOST R 34 10-2001 and GOST R 34 11-94 Algorithms Author: V. Popov, I. Kurepkin, S. Leontiev Status: Informational Date: January 2006 Mailbox:[EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] Pages: 51 Characters: 114564 Updates/Obsoletes/SeeAlso: None I-D Tag:draft-popov-cryptopro-cpalgs-04.txt URL:http://www.rfc-editor.org/rfc/rfc4357.txt This document describes the cryptographic algorithms and parameters supplementary to the original GOST specifications, GOST 28147-89, GOST R 34.10-94, GOST R 34.10-2001, and GOST R 34.11-94, for use in Internet applications. This memo provides information for the Internet community. INFORMATIONAL: 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 ... ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
Last Call: 'Real-time Application Quality of Service Monitoring (RAQMON) Framework' to Proposed Standard
The IESG has received a request from the Remote Network Monitoring WG to consider the following documents: - 'Real-time Application Quality of Service Monitoring (RAQMON) MIB ' draft-ietf-rmonmib-raqmon-mib-11.txt as a Proposed Standard - 'Real-time Application Quality of Service Monitoring (RAQMON) Framework ' draft-ietf-rmonmib-raqmon-framework-14.txt as a Proposed Standard - 'Transport Mappings for Real-time Application Quality of Service Monitoring (RAQMON) Protocol Data Unit (PDU) ' draft-ietf-rmonmib-raqmon-pdu-12.txt as a Proposed Standard There is a potential overlap between the RAQMON protocol and the IPFIX and/or RTCP-XR work, but there are enough differences in applicability and complexity that this should not be a significant issue. RAQMON is an extensible, distributed, SNMP-based monitoring system, integrated with the RMON family of MIB modules. As such, it is intended to be applicable to many different types of protocols, that may run concurrently. If a specialized protocol for VoIP monitoring is desired, then RTCP-XR should probably be used instead. If SNMP and/or RMON integration are not desired, then IPFIX would be a suitable choice. The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by 2006-02-13. The files can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-rmonmib-raqmon-mib-11.txt http://www.ietf.org/internet-drafts/draft-ietf-rmonmib-raqmon-framework-14.txt http://www.ietf.org/internet-drafts/draft-ietf-rmonmib-raqmon-pdu-12.txt ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
