Re: Organizationed spam RE: [Sip] WiMAX Summit'05 - Paris - France
[EMAIL PROTECTED] has already been denied posting rights on at least one IETF WG mailing list because of this behaviour. Is it time to dig out RFC 3683/BCP 83? BTW - has anyone, anywhere ever seen a response from him/them when they have been asked to stop spamming the IETF lists? Harald --On onsdag, desember 15, 2004 17:35:11 -0800 Thomas Gal [EMAIL PROTECTED] wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Harald and community, Observation/Comment from a concerned member. I've never really complained about anything before, but if I search over the last couple of months (I did a searchback to Oct 1) across the following mailing lists to which I'm subscribed: XCON,AVT,IPSEC,IPTEL,SIP,SIPPING,MMUSIC etc I get notices from Peter Lewis and Gunther Palmer, sometimes I get 5+ copies of these notices. For example I have 11 notices about the summer '05 wimax summit in paris france that I haven't deleted floating around my mailbox! 5 Just today between SIMPLE,XCON,SIPPING,MMUSIC, and SIP! Who knows how many more went out. I thought this was a little bit unacceptable(I'm trying to be polite for some reason I guess) as the IETF itself has 1 announce list for announcing things, and as far as I'm concerned this is basically spam. I sent a message on November 11th which is attached basically saying to the principals of this organization that: - -I'm receiving multiple notices, - -think it's unreasonable, - -the people sending the notices are not participants on the lists so are clearly exploiting the mailing list - -that the IETF has an announce list which they should work out appropriate submission and distribution through, as I'm sure that IETF memebers would in fact like to be notified of their events, but appropriately. I'm copying them on this message again as well, and personally I feel that if you look at http://tinyurl.com/6mvnc - -and- http://tinyurl.com/452e5 You can see that peter lewis has been sending bulk unsolicited email through IETF lists for some time, and Gunter Palmer appears to be a new up and coming distributor. That said, I never got a response, so I'm inclined to say we should boot them from IETF mailing lists, and ideally get a response and arrange to have them submit 1 notice 1 time to go out to the IETF announce list, or perhaps even a separate list which is specifically for folks wishing to address the IETF population at large. Certainly only willing participants to the IETF/IETF announce list should be getting these notices. I do recall a gentleman mentioning in DC something about coordinating reasonable official submissions, and I feel this falls in line with that request. There's enough of a problem with spam that we can't do anything about, and I think dealing with this situation properly could have the potential to not only reduce some junk mail, but also allow that information to go out in an appropriate fashion to willing recipients, and perhaps educate some people (who's company supposedly caters to technology folk) along the way of proper edicate for such matters. And if they don't respond, who cares, just boot em and let them suffer the consequences. Perhaps comments from a few more IETF folk could establish that this crap is not welcome, or is it just me? And to the principals of this orgnaization. Who are you to not respond to something like this? This is very indicative of pathetic business practices, and makes me inclined to say bad things about your organizations morals, and the organization itself, and frankly the people on top who don't respond as well. Don't you realize that the people who get the most spam and are more annoyed than anyone by it are the audience you supposedly are catering to? - -Tom [EMAIL PROTECTED] -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Gunter Sent: Wednesday, December 15, 2004 6:28 AM To: [EMAIL PROTECTED] Subject: [Sip] WiMAX Summit'05 - Paris - France . What is the business model for WiMAX? . What do we learn from earlier deployments? . What about the future extensions of the standard? . How is addressed the interoperability challenge? These questions, among others, will be addressed during the second edition of the WiMAX Summit to be organised in Paris next 5-8 April 2005. Get all details at: http://www.upperside.fr/wimax05/wimax2005intro.htm http://www.upperside.fr/wimax05/wimax2005intro.htm -BEGIN PGP SIGNATURE- iQA/AwUBQcDmA+q9bQOx/5ayEQLGFACeLMNxzQyiRwgB0n5KdxPHD0s3LxAAnRcl NfKI62xgIbF44qYivQyJ4Dmj =IY/A -END PGP SIGNATURE- ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Draft version of the IAD job announcement from the IASA TT
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 All, please find below the draft call for applications for the IAD position. The current timeline for moving forward is as follows DEC 18 Send out call for applications to o IETF-Announce list o ISOC announcement lists o NANOG, SANOG, NORDNOG, AFNOG, etc o Ask RIRs to forward to their respective announcement lists JAN 15 evaluation of applicants start We would appreciate any feedback as soon as possible, either on the [EMAIL PROTECTED] list OR directly to the IASA team at [EMAIL PROTECTED] On behalf of the IASA-TT - - kurtis - The IETF Administrative Entity is seeking a highly capable individual to serve as Administrative Director. You will report to the Internet Administrative Oversight Committee (IAOC) be accountable to the IETF community. This is a highly visible and very demanding job. You will be expected to: o Working with the IAOC to document and cater for the administrative requirements of the IETF, IESG, IAB and IRTF. o Establish the IASA/IETF annual budgets, and the financial administration and reporting of IASA/IETF. o Work with ISOC and various service providers to establish appropriate agreed budgets and related financial and performance reporting. o Contract negotiations with service providers, and establish procedures for meassuring the performance of these providers. o Eventual mangagement of support staff and contractors. o Serve as the day-to-day chief operating officer of the IETF, managing a number of contractors and working with a number of volunteers. o Work with our liaison organizations, such as the RFC Editor and the IANA. o Serve as the primary staff resource for the governing body of the administrative entity for the IETF. o Work with your contractors and members of the IETF community to provide adequate support and planning for 3 IETF meetings annually, and for frequent meetings and teleconferences of the IAB, IESG, and other bodies that support the IETF. The following characteristics are necessary for this job: o This job is public service. You should be able to work successfully with large numbers of people. This requires a high clock rate, a large stack, and the ability to listen carefully. o This is an operations job. IETF meetings are large and complex, and the day-to-day activities of the standards-making process is demanding. You should be adept at getting real results and helping large groups work together towards common goals and deadlines. o This is a public job. You will be required to present the results and achievements of the IASA in front of the community as well as dealing with questions from individual members of the community. The goal of IASA is to achieve as much transparency as possible so good communication skills, and previous similar experiences are valued. o This job requires a financially astute individual. The IETF is a $2-$3 million/year operation. IETF funds are tight and we expect you to take leadership in establishing our budgetary procedures, our procurement standards, and understanding our revenue sources. In-depth familiarity with the IETF prior to assuming this position is not required, but you must be able to quickly get up to speed and learn the unique culture and requirements of the organization. Likewise, long-term technical experience is not required, but you must be a quick learner and adept at using the Internet effectively. The Internet Society is based in Reston, Virginia and the job will require a high level of travel for IETF meetings and preparation and related meetings. You may work out of a home office as a telecommuter, or use the Internet Society facilities in Virginia. In either case, you should be prepared to travel to Virginia, IETF meetings, and the locations where the IETF has contractors. Salary levels commensurate with experience and qualifications. You must be fluent in spoken and written english. Applicants should forward a resume, references, and any other relevant materials, with a cover letter explaining why they feel they are the right person for this position written in text or PDF, in an email sent to [EMAIL PROTECTED] Applications will be evaluated starting January 15th. The evaluation of applications, selection and appointment of the IAD will be made by the IASA transition team. The list of applicants will not be posted publicly, but will be reviewed in confidence by members of the evaluation committee, the IAB, and the IESG. -BEGIN PGP SIGNATURE- Version: PGP 8.1 iQA/AwUBQcFS8aarNKXTPFCVEQKk/wCgykkbRICv/w4TbgaRTa+iKeeDImkAn0S4 hcLPkCUqazD9N7nzjRshjLkf =QR57 -END PGP SIGNATURE- ___ Ietf mailing list [EMAIL PROTECTED]
Re: Organizationed spam RE: [Sip] WiMAX Summit'05 - Paris - France
On Thu, Dec 16, 2004 at 08:45:51AM +0100, Harald Tveit Alvestrand wrote: [EMAIL PROTECTED] has already been denied posting rights on at least one IETF WG mailing list because of this behaviour. Is it time to dig out RFC 3683/BCP 83? BTW - has anyone, anywhere ever seen a response from him/them when they have been asked to stop spamming the IETF lists? No, I haven't. It is clearly a commercial posting, and should be blocked. I have soammed v6ops and ipng in the past with an IPv6 event announcement, but this was for a non-profit event, and although I didn't feel comfortable doing so, I felt it was OK as a regular contributor to both WGs. I also didn't get any complaints to me as it happens (thanks :) I think both metrics should be applied when spam complaints arise. Tim ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
List of Old Standards to be retired
Hello, This is an update from the Old Standards experiment. Below are a list of proposed standards that are candidates to be obsoleted. The old standards mailing list has vetted out a good number, but still a good number remains. We are looking for experts who can say affirmatively whether a standard is implemented and in use. In particular, many of the docs class into four categories: - telnet options - MIBs (for X.25, 802.5, FDDI, and other) - SOCKS - Interaction with other protocol stacks (ISO, IPX, Appelalk, SNA, etc) If you see a document on the list below and you know it to be in use, would you please reply to this message indicating the RFC number, and whether you believe the doc should be advanced beyond proposed? Also, if you know of work to update anything on the list below, please include that. A note along these lines is generally sufficient to remove a document from the list below. RFC0698 Telnet extended ASCII option RFC0726 Remote Controlled Transmission and Echoing Telnet option RFC0727 Telnet logout option RFC0735 Revised Telnet byte macro option RFC0736 Telnet SUPDUP option RFC0749 Telnet SUPDUP-Output option RFC0779 Telnet send-location option RFC0885 Telnet end of record option RFC0927 TACACS user identification Telnet option RFC0933 Output marking Telnet option RFC0946 Telnet terminal location number option RFC1041 Telnet 3270 regime option RFC1043 Telnet Data Entry Terminal option: DODIIS implementation RFC1053 Telnet X.3 PAD option RFC1234 Tunneling IPX traffic through IP networks RFC1239 Reassignment of experimental MIBs to standard MIBs RFC1269 Definitions of Managed Objects for the Border Gateway Protocol: Version 3 RFC1276 Replication and Distributed Operations extensions to provide an Internet Directory using X.500 RFC1277 Encoding Network Addresses to Support Operation over Non-OSI Lower Layers RFC1285 FDDI Management Information Base RFC1314 A File Format for the Exchange of Images in the Internet RFC1328 X.400 1988 to 1984 downgrading RFC1370 Applicability Statement for OSPF RFC1372 Telnet Remote Flow Control Option RFC1378 The PPP AppleTalk Control Protocol (ATCP) RFC1381 SNMP MIB Extension for X.25 LAPB RFC1382 SNMP MIB Extension for the X.25 Packet Layer RFC1397 Default Route Advertisement In BGP2 and BGP3 Version of The Border Gateway Protocol RFC1414 Identification MIB RFC1415 FTP-FTAM Gateway Specification RFC1418 SNMP over OSI RFC1419 SNMP over AppleTalk RFC1420 SNMP over IPX RFC1421 Privacy Enhancement for Internet Electronic Mail: Part I: Message Encryption and Authentication Procedures RFC1422 Privacy Enhancement for Internet Electronic Mail: Part II: Certificate-Based Key Management RFC1423 Privacy Enhancement for Internet Electronic Mail: Part III: Algorithms, Modes, and Identifiers RFC1424 Privacy Enhancement for Internet Electronic Mail: Part IV: Key Certification and Related Services RFC1461 SNMP MIB extension for Multiprotocol Interconnect over X.25 RFC1469 IP Multicast over Token-Ring Local Area Networks RFC1471 The Definitions of Managed Objects for the Link Control Protocol of the Point-to-Point Protocol RFC1472 The Definitions of Managed Objects for the Security Protocols of the Point-to-Point Protocol RFC1473 The Definitions of Managed Objects for the IP Network Control Protocol of the Point-to-Point Protocol RFC1474 The Definitions of Managed Objects for the Bridge Network Control Protocol of the Point-to-Point Protocol RFC1478 An Architecture for Inter-Domain Policy Routing RFC1479 Inter-Domain Policy Routing Protocol Specification: Version 1 RFC1494 Equivalences between 1988 X.400 and RFC-822 Message Bodies RFC1496 Rules for downgrading messages from X.400/88 to X.400/84 when MIME content-types are present in the messages RFC1502 X.400 Use of Extended Character Sets RFC1512 FDDI Management Information Base RFC1513 Token Ring Extensions to the Remote Network Monitoring MIB RFC1518 An Architecture for IP Address Allocation with CIDR RFC1519 Classless Inter-Domain Routing (CIDR): an Address Assignment and Aggregation Strategy RFC1525 Definitions of Managed Objects for Source Routing Bridges RFC1552 The PPP Internetworking Packet Exchange Control Protocol (IPXCP) RFC1553 Compressing IPX Headers Over WAN Media (CIPX) RFC1582 Extensions to RIP to Support Demand Circuits RFC1584 Multicast Extensions to OSPF RFC1598 PPP in X.25 RFC1618 PPP over ISDN
Re: Draft version of the IAD job announcement from the IASA TT
Typos etc. are easily fixed (in-line). Isn't it normal to give a closing date for applications rather than to say when evaluation of applications will start? It might also be usual to indicate from when we are hoping to fill the post. Is Salary levels commensurate with experience and qualifications a cop-out? You might say expected to be in the range... Adrian - Original Message - From: Kurt Erik Lindqvist [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Thursday, December 16, 2004 9:18 AM Subject: Draft version of the IAD job announcement from the IASA TT -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 All, please find below the draft call for applications for the IAD position. The current timeline for moving forward is as follows DEC 18 Send out call for applications to o IETF-Announce list o ISOC announcement lists o NANOG, SANOG, NORDNOG, AFNOG, etc o Ask RIRs to forward to their respective announcement lists JAN 15 evaluation of applicants start We would appreciate any feedback as soon as possible, either on the [EMAIL PROTECTED] list OR directly to the IASA team at [EMAIL PROTECTED] On behalf of the IASA-TT - - kurtis - The IETF Administrative Entity is seeking a highly capable individual to serve as Administrative Director. You will report to the Internet Administrative Oversight Committee (IAOC) be accountable s/(IAOC) be/(IAOC) and be/ to the IETF community. This is a highly visible and very demanding job. You will be expected to: o Working with the IAOC to document and cater for the administrative s/Working/Work/ requirements of the IETF, IESG, IAB and IRTF. o Establish the IASA/IETF annual budgets, and the financial administration and reporting of IASA/IETF. If you mean that there are two separate operations here: 1. establish budgets 2. establish financial admin and reporting I suggest you split this into two bullets o Work with ISOC and various service providers to establish appropriate agreed budgets and related financial and performance reporting. o Contract negotiations with service providers, and establish s/Contract negotiations/Negotiate contracts/ procedures for meassuring the performance of these providers. o Eventual mangagement of support staff and contractors. s/Eventual mangagement/Assume eventual mangagement/ o Serve as the day-to-day chief operating officer of the IETF, managing a number of contractors and working with a number of volunteers. o Work with our liaison organizations, such as the RFC Editor and the IANA. o Serve as the primary staff resource for the governing body of the administrative entity for the IETF. o Work with your contractors and members of the IETF community to provide adequate support and planning for 3 IETF meetings annually, and for frequent meetings and teleconferences of the IAB, IESG, and other bodies that support the IETF. The following characteristics are necessary for this job: o This job is public service. You should be able to work successfully with large numbers of people. This requires a high clock rate, a large stack, and the ability to listen carefully. o This is an operations job. IETF meetings are large and complex, and the day-to-day activities of the standards-making process is demanding. You should be adept at getting real results and helping large groups work together towards common goals and deadlines. o This is a public job. You will be required to present the results and achievements of the IASA in front of the community as well as dealing with questions from individual members of the community. The goal of IASA is to achieve as much transparency as possible so good communication skills, and previous similar experiences are valued. o This job requires a financially astute individual. The IETF is a $2-$3 million/year operation. IETF funds are tight and we expect you to take leadership in establishing our budgetary procedures, our procurement standards, and understanding our revenue sources. In-depth familiarity with the IETF prior to assuming this position is not required, but you must be able to quickly get up to speed and learn the unique culture and requirements of the organization. Likewise, long-term technical experience is not required, but you must be a quick learner and adept at using the Internet effectively. The Internet Society is based in Reston, Virginia and the job will require a high level of travel for IETF meetings and preparation and related meetings. You may work out of a home office as a telecommuter, or use the Internet Society facilities in Virginia. In either case, you should be prepared to travel to Virginia, IETF meetings, and the locations where the IETF has contractors. Salary levels commensurate with
Re: List of Old Standards to be retired
On Dec 16 2004, at 12:46 Uhr, Eliot Lear wrote: RFC1618 PPP over ISDN We had a short discussion about this in pppext. The gist was: The document is pretty bad (partly because things were murky in 1994, but also because it was written by Martians that had no space ship to take them to the ISDN planet), but some parts of it do describe what currently shipping, actively marketed products do (and should do) in this domain. Having done some ISDN work in the late 80s/early 90s, I all but volunteered during this discussion to do a DS version of the thing (probably by striking 80 % of the text and rewriting the rest). If this is what it takes to keep an active standards-track specification about IP over ISDN, I'll do that tiny amount of work. Or we could leave it where it is. Gruesse, Carsten ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: Draft version of the IAD job announcement from the IASA TT
Is Salary levels commensurate with experience and qualifications a cop-out? You might say expected to be in the range... Adrian Agree with Adrian here - commensurate makes sense when you hire several people with a range of experience, or when you are waiting to see who actually applies before approving budget for a position. The first condition does not apply here, and I'm having a hard time imagining someone being selected for the position with a LOT less experience than we expected the selected candidate to have. No, don't name a number, but naming a range is likely to help people decide whether you're actually looking for THEM! Spencer ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: Issue #719: Transparency/Openness of the IAOC (IASA transition te
Scott Bradner wrote: I actually wonder if this is an issue for the IASA BCP document, because it is about the Transition Team Transparency. I do not think it is So I propose to remobve it from the iasa-bcp queue or declare it as No change needed. makes sense to me Agreed Brian ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: List of Old Standards to be retired
I'm initially really surprised 1518/1519 is on this list. Wasn't there recent talk (like last week) of extending CIDR? And if this is true, shouldn't that work be completed before the existing docs are moved out to the pasture? At 12:46 PM 12/16/2004 +0100, Eliot Lear wrote: Hello, This is an update from the Old Standards experiment. Below are a list of proposed standards that are candidates to be obsoleted. The old standards mailing list has vetted out a good number, but still a good number remains. We are looking for experts who can say affirmatively whether a standard is implemented and in use. In particular, many of the docs class into four categories: - telnet options - MIBs (for X.25, 802.5, FDDI, and other) - SOCKS - Interaction with other protocol stacks (ISO, IPX, Appelalk, SNA, etc) If you see a document on the list below and you know it to be in use, would you please reply to this message indicating the RFC number, and whether you believe the doc should be advanced beyond proposed? Also, if you know of work to update anything on the list below, please include that. A note along these lines is generally sufficient to remove a document from the list below. RFC0698 Telnet extended ASCII option RFC0726 Remote Controlled Transmission and Echoing Telnet option RFC0727 Telnet logout option RFC0735 Revised Telnet byte macro option RFC0736 Telnet SUPDUP option RFC0749 Telnet SUPDUP-Output option RFC0779 Telnet send-location option RFC0885 Telnet end of record option RFC0927 TACACS user identification Telnet option RFC0933 Output marking Telnet option RFC0946 Telnet terminal location number option RFC1041 Telnet 3270 regime option RFC1043 Telnet Data Entry Terminal option: DODIIS implementation RFC1053 Telnet X.3 PAD option RFC1234 Tunneling IPX traffic through IP networks RFC1239 Reassignment of experimental MIBs to standard MIBs RFC1269 Definitions of Managed Objects for the Border Gateway Protocol: Version 3 RFC1276 Replication and Distributed Operations extensions to provide an Internet Directory using X.500 RFC1277 Encoding Network Addresses to Support Operation over Non-OSI Lower Layers RFC1285 FDDI Management Information Base RFC1314 A File Format for the Exchange of Images in the Internet RFC1328 X.400 1988 to 1984 downgrading RFC1370 Applicability Statement for OSPF RFC1372 Telnet Remote Flow Control Option RFC1378 The PPP AppleTalk Control Protocol (ATCP) RFC1381 SNMP MIB Extension for X.25 LAPB RFC1382 SNMP MIB Extension for the X.25 Packet Layer RFC1397 Default Route Advertisement In BGP2 and BGP3 Version of The Border Gateway Protocol RFC1414 Identification MIB RFC1415 FTP-FTAM Gateway Specification RFC1418 SNMP over OSI RFC1419 SNMP over AppleTalk RFC1420 SNMP over IPX RFC1421 Privacy Enhancement for Internet Electronic Mail: Part I: Message Encryption and Authentication Procedures RFC1422 Privacy Enhancement for Internet Electronic Mail: Part II: Certificate-Based Key Management RFC1423 Privacy Enhancement for Internet Electronic Mail: Part III: Algorithms, Modes, and Identifiers RFC1424 Privacy Enhancement for Internet Electronic Mail: Part IV: Key Certification and Related Services RFC1461 SNMP MIB extension for Multiprotocol Interconnect over X.25 RFC1469 IP Multicast over Token-Ring Local Area Networks RFC1471 The Definitions of Managed Objects for the Link Control Protocol of the Point-to-Point Protocol RFC1472 The Definitions of Managed Objects for the Security Protocols of the Point-to-Point Protocol RFC1473 The Definitions of Managed Objects for the IP Network Control Protocol of the Point-to-Point Protocol RFC1474 The Definitions of Managed Objects for the Bridge Network Control Protocol of the Point-to-Point Protocol RFC1478 An Architecture for Inter-Domain Policy Routing RFC1479 Inter-Domain Policy Routing Protocol Specification: Version 1 RFC1494 Equivalences between 1988 X.400 and RFC-822 Message Bodies RFC1496 Rules for downgrading messages from X.400/88 to X.400/84 when MIME content-types are present in the messages RFC1502 X.400 Use of Extended Character Sets RFC1512 FDDI Management Information Base RFC1513 Token Ring Extensions to the Remote Network Monitoring MIB RFC1518 An Architecture for IP Address Allocation with CIDR RFC1519 Classless Inter-Domain Routing (CIDR): an Address Assignment and Aggregation Strategy RFC1525 Definitions of Managed Objects for Source Routing Bridges RFC1552 The PPP
Re: Draft version of the IAD job announcement from the IASA TT
The current timeline for moving forward is as follows DEC 18 Send out call for applications to o IETF-Announce list o ISOC announcement lists o NANOG, SANOG, NORDNOG, AFNOG, etc o Ask RIRs to forward to their respective announcement lists That's pretty tight... 24 hours for IETF comments? JAN 15 evaluation of applicants start Even if you get it out this week, that is also tight due to the various holidays. I think you will have to accept applications at least until end January. Comments and suggested changes below. We would appreciate any feedback as soon as possible, either on the [EMAIL PROTECTED] list OR directly to the IASA team at [EMAIL PROTECTED] On behalf of the IASA-TT - - kurtis - The IETF Administrative Entity There is no such thing defined - we have only defined the IETF Administrative Support Activity. is seeking a highly capable individual to serve as Administrative Director. You will report to the Internet Administrative Oversight Committee (IAOC) be accountable Flame-bait! It's the IETF Administrative Oversight Committee. Also there is a missing and after (IAOC). to the IETF community. This is a highly visible and very demanding job. You will be expected to: o Working with the IAOC to document and cater for the administrative requirements of the IETF, IESG, IAB and IRTF. o Work with the IAOC to document the administrative requirements of the IETF, IESG, IAB and IRTF, and manage their implementation. o Establish the IASA/IETF annual budgets, and the financial administration and reporting of IASA/IETF. o Establish the IASA/IETF annual budgets and the financial administration of IASA, and be responsible for their reporting to the IETF. o Work with ISOC and various service providers to establish appropriate agreed budgets and related financial and performance reporting. o Contract negotiations with service providers, and establish procedures for meassuring the performance of these providers. o Negotiate contracts with service providers, and establish procedures for measuring and reporting the performance of these providers. o Eventual mangagement of support staff and contractors. o If applicable, mangage support staff and contractors. o Serve as the day-to-day chief operating officer of the IETF, managing a number of contractors and working with a number of volunteers. o Work with our liaison organizations, such as the RFC Editor and the IANA. These are not liaisons. The RFC Editor is under contract and the IANA operates under an MOU. They are service providers and should not be mentioned at all in this document as special cases. o Serve as the primary staff resource for the governing body of the administrative entity for the IETF. What on earth does that mean? I think it just means you report to the IAOC which is stated above. I recommend deleting it. o Work with your contractors and members of the IETF community to provide adequate support and planning for 3 IETF meetings annually, and for frequent meetings and teleconferences of the IAB, IESG, and other bodies that support the IETF. Add: o Work with contractors and members of the IETF community to ensure support for the IETF's various on line systems and tools, used to support IETF activities and to make IETF drafts and specifications generally available to the public. The following characteristics are necessary for this job: o This job is public service. You should be able to work successfully with large numbers of people. This requires a high clock rate, a large stack, and the ability to listen carefully. mention international nature of the community o This is an operations job. IETF meetings are large and complex, and the day-to-day activities of the standards-making process is demanding. You should be adept at getting real results and helping large groups work together towards common goals and deadlines. o This is a public job. You will be required to present the results and achievements of the IASA in front of the community as well as dealing with questions from individual members of the community. The goal of IASA is to achieve as much transparency as possible so good communication skills, and previous similar experiences are valued. o This job requires a financially astute individual. The IETF is a $2-$3 million/year operation. IETF funds are tight and we expect you to take leadership in establishing our budgetary procedures, our procurement standards, and understanding our revenue sources. o This job requires a good understanding of modern information technology including networks, but does not necessarily require the individual appointed to be an IT or networking specialist. In-depth familiarity with the IETF prior to assuming this position is not required, but you must be able to
Re: List of Old Standards to be retired
James M. Polk wrote: I'm initially really surprised 1518/1519 is on this list. Obviously, it's a bug. Of the Proposed Standards that the Internet runs on, those are among the most important. I believe this was pointed out on the old-standards list already, but it must have got lost. Brian ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: [newtrk] List of Old Standards to be retired
On Dec 16 2004, at 14:02 Uhr, Margaret Wasserman wrote: RFC0885 Telnet end of record option This option was, at least at one time, used for telnet clients that connected to IBM mainframes... It was used to indicate the end of a 3270 datastream. ... and 5250 (RFC2877). Note that there was a draft-murphy-iser-telnet-02.txt attempt at RFC2877bis as recent as May 2004, which still uses EOR. RFC1576 (which is cited in the PS document RFC2355 as traditional TN3270) says: Currently, support for 3270 terminal emulation over Telnet is accomplished by the de facto standard of negotiating three separate Telnet Options - Terminal-Type [2], Binary Transmission [3], and End of Record [4]. This negotiation and the resulting data flow will be described below. [...] [4] Postel, J., Telnet End of Record Option, RFC 885, USC/Information Sciences Institute, December 1983. It's probably necessary to do a full dependency analysis to do this right. OMG, what a visit to the technology attic. Gruesse, Carsten ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: [newtrk] List of Old Standards to be retired
On 16-dec-04, at 14:55, Carsten Bormann wrote: It's probably necessary to do a full dependency analysis to do this right. OMG, what a visit to the technology attic. Why do we care if there are still implementations that are based on these documents in use? The important question is whether there are going to be new or revised implementations based on these documents. ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: [newtrk] List of Old Standards to be retired
Why do we care if there are still implementations that are based on these documents in use? The important question is whether there are going to be new or revised implementations based on these documents. A new implementation for tn5250 is about as likely as a new implementation for NTP. Standards have been invented for creating markets. If the market is mature, you may not see many new entrants, but the existing players still need the standard to keep the market intact. (Of course, tn5250 is a strange market as it is ancillary to one created by a specific vendor, but that's not my point.) Maybe we need a new category STABLE? (But even that is not the case for tn5250, as evidenced by draft-murphy-iser-telnet-02.txt.) So what does HISTORIC mean? -- bad protocol (advice is to get rid of it), as in RIPv1 -- bad specification, but the protocol is alright -- an underlying/related technology is dying out slowly -- an underlying/related technology is used mainly in parts of the world many IETFers don't visit that often -- the market is stable, so there won't be new implementations -- existing open source implementations are doing well, so there won't be new implementations -- there is unlikely to be new development about this standard, as in IPv4 Gruesse, Carsten ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: [newtrk] List of Old Standards to be retired
Margaret, Thanks for your note. Please see below for responses: Margaret Wasserman wrote: RFC0885 Telnet end of record option This option was, at least at one time, used for telnet clients that connected to IBM mainframes... It was used to indicate the end of a 3270 datastream. I don't know if it is still used in that fashion, but Bob Moskowitz might know. Thanks. It sounds about right. I'm sure tn3270 is out there and used but I don't know what options it uses. RFC1041 Telnet 3270 regime option I'm not sure what this was ever used for, but again Bob Moskowitz would be a good person to ask if this is still in-use. Right. RFC1269 Definitions of Managed Objects for the Border Gateway Protocol: Version 3 Why would this be cruft? The BGP4 MIB was just recently approved... Good thing too. Take a good look at 1269. I don't think it would pass a MIB compiler test today. If you approved the BGP4-MIB, ought not that have obsoleted this guy? RFC1518 An Architecture for IP Address Allocation with CIDR RFC1519 Classless Inter-Domain Routing (CIDR): an Address Assignment and Aggregation Strategy CIDR is still in-use and rather frequently discussed in other documents. Are there newer references or something? Yah. Something slipped here. One of these two docs is cruftier than the other, and while we don't have a newer reference, we're likely to cruftify one of them and recommend that the other be revised and advanced. Eliot ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: [newtrk] List of Old Standards to be retired
Maybe we need a new category STABLE? I don't think that would be a good name since it might imply that others are INSTABLE ;-). Perhaps FROZEN, STATIC, MATURE? ...George George Swallow Cisco Systems (978) 936-1398 1414 Massachusetts Avenue Boxborough, MA 01719 ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: Organizationed spam RE: [Sip] WiMAX Summit'05 - Paris - France
Could this not be used for an enhancement? The IETF needs to globalize, to motivate and reward its members (see current analysis), to motivate (cf. RFC 3869) local Govs (meeting, debates, PR announces) and industries (PR on products) and to get independent and stable money for its budget. Why not to add an annoucement menu on the IETF page. Where announces could be presented in a mechanism similar to Drafts (with anouncements for information and some kind of sponsoring for key meeting/announces). With at least three keys (per WG, per Topics, per Location). This could only help outreach, Members to meet f2f locally and cross-WG information. Also, this could be contracted to ISOC or another party to run the commercial announces in a commercial way (products announces, commercial events, etc.) and get most probably substantial financial resources for the RFC Editor. In using an RSS I do not think it would impose an extra worthless reading on the Members and could help a lot keeping abreast without having to scan scores of blogs and mailing lists. jfc ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: RFC1269 - [was: RE: [newtrk] List of Old Standards to be retired]
Bert, I'll remove it from the list with the expectation that the new MIB will obsolete the old one. However, I note that is currently not stated in the header of the draft. Eliot Wijnen, Bert (Bert) wrote: W.r.t. RFC1269 Definitions of Managed Objects for the Border Gateway Protocol: Version 3 Why would this be cruft? The BGP4 MIB was just recently approved... Good thing too. Take a good look at 1269. I don't think it would pass a MIB compiler test today. If you approved the BGP4-MIB, ought not that have obsoleted this guy? The new doc (in IESG evaluation status) is draft-ietf-idr-bgp4-mib-15.txt And its abstract says it all: Abstract This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community In particular, it describes managed objects used for managing the Border Gateway Protocol Version 4 or lower. The origin of this memo is from RFC 1269 Definitions of Managed Objects for the Border Gateway Protocol (Version 3), which was updated to support BGP-4 in RFC 1657. This memo fixes errors introduced when the MIB module was converted to use the SMIv2 language. This memo also updates references to the current SNMP framework documents. This memo is intended to document deployed implementations of this MIB module in a historical context, provide clarifications of some items and also note errors where the MIB module fails to fully represent the BGP protocol. Work is currently in progress to replace this MIB module with a new one representing the current state of the BGP protocol and its extensions. This document obsoletes RFC 1269 and RFC 1657. Distribution of this memo is unlimited. Please forward comments to [EMAIL PROTECTED] So 1269 will soon be made OBSOLETED I will look at other MIB related documents next week. Bert ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: List of Old Standards to be retired
The way we've been running the experiment, if there is a portion of the doc that is still useful then we leave it alone but recommend an update. In other words no status change until someone takes further action. Having said that, I will remove RFC 1618 from the list, but it would be great if you did the update and in the process then obsoleted RFC 1618. Eliot Carsten Bormann wrote: On Dec 16 2004, at 12:46 Uhr, Eliot Lear wrote: RFC1618 PPP over ISDN We had a short discussion about this in pppext. The gist was: The document is pretty bad (partly because things were murky in 1994, but also because it was written by Martians that had no space ship to take them to the ISDN planet), but some parts of it do describe what currently shipping, actively marketed products do (and should do) in this domain. Having done some ISDN work in the late 80s/early 90s, I all but volunteered during this discussion to do a DS version of the thing (probably by striking 80 % of the text and rewriting the rest). If this is what it takes to keep an active standards-track specification about IP over ISDN, I'll do that tiny amount of work. Or we could leave it where it is. Gruesse, Carsten ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: [newtrk] List of Old Standards to be retired
* * It's probably necessary to do a full dependency analysis to do this * right. * If it's not broken, why break it? Bob Braden ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: [newtrk] List of Old Standards to be retired
* Standards have been invented for creating markets. That's strange, all these years I thought standards were for interoperability. Bob Braden * Gruesse, Carsten * * * ___ * Ietf mailing list * [EMAIL PROTECTED] * https://www1.ietf.org/mailman/listinfo/ietf * ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: Organizationed spam RE: [Sip] WiMAX Summit'05 - Paris - France
Based on the comments over the last several days and my interpretation of RFC 3683/BCP 83, I ask the firm of Upper Side, Paris France, to STOP POSTING COMMERCIAL NOTICES to the IETF general list [EMAIL PROTECTED] I quote from RFC 3683/BCP 83: Guidelines have been developed for dealing with abusive behavior (c.f., Section 3.2 of [1] and [2]). Although not exhaustive, examples of abusive or otherwise inappropriate postings to IETF mailing lists include: o unsolicited bulk e-mail; o discussion of subjects unrelated to IETF policy, meetings, activities, or technical concerns; o unprofessional commentary, regardless of the general subject; and, o announcements of conferences, events, or activities that are not sponsored or endorsed by the Internet Society or IETF. I made a phone call to Upper Side this morning (always pleasant when an transatlantic phone call costs less than the cup of coffee in my hand), was told Peter Lewis left the employ of Upper Side two years ago. The two managing partners of Upper Side, Remi Scavenius and Michel Gosse, are receiving copies of this email. Upper Side is a for-profit organizations that organizes conferences and provides training in IT. The quality or value of their activities is not the point. Such commercial announcements are not to be sent to IETF lists. Thomas Gal states that he sent email to the company on November 11 objecting to such SPAM commercial emails and he received no reply. As a personal courtesy, I will appreciate a reply to this request from Upper Side management off-list. If I am wrong in understanding IETF policy, please let me know. Gene Gaines [EMAIL PROTECTED] Sterling, Virginia USA On Thursday, December 16, 2004, 2:45:51 AM, Harald wrote: [EMAIL PROTECTED] has already been denied posting rights on at least one IETF WG mailing list because of this behaviour. Is it time to dig out RFC 3683/BCP 83? BTW - has anyone, anywhere ever seen a response from him/them when they have been asked to stop spamming the IETF lists? Harald --On onsdag, desember 15, 2004 17:35:11 -0800 Thomas Gal [EMAIL PROTECTED] wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Harald and community, Observation/Comment from a concerned member. I've never really complained about anything before, but if I search over the last couple of months (I did a searchback to Oct 1) across the following mailing lists to which I'm subscribed: XCON,AVT,IPSEC,IPTEL,SIP,SIPPING,MMUSIC etc I get notices from Peter Lewis and Gunther Palmer, sometimes I get 5+ copies of these notices. For example I have 11 notices about the summer '05 wimax summit in paris france that I haven't deleted floating around my mailbox! 5 Just today between SIMPLE,XCON,SIPPING,MMUSIC, and SIP! Who knows how many more went out. I thought this was a little bit unacceptable(I'm trying to be polite for some reason I guess) as the IETF itself has 1 announce list for announcing things, and as far as I'm concerned this is basically spam. I sent a message on November 11th which is attached basically saying to the principals of this organization that: - -I'm receiving multiple notices, - -think it's unreasonable, - -the people sending the notices are not participants on the lists so are clearly exploiting the mailing list - -that the IETF has an announce list which they should work out appropriate submission and distribution through, as I'm sure that IETF memebers would in fact like to be notified of their events, but appropriately. I'm copying them on this message again as well, and personally I feel that if you look at http://tinyurl.com/6mvnc - -and- http://tinyurl.com/452e5 You can see that peter lewis has been sending bulk unsolicited email through IETF lists for some time, and Gunter Palmer appears to be a new up and coming distributor. That said, I never got a response, so I'm inclined to say we should boot them from IETF mailing lists, and ideally get a response and arrange to have them submit 1 notice 1 time to go out to the IETF announce list, or perhaps even a separate list which is specifically for folks wishing to address the IETF population at large. Certainly only willing participants to the IETF/IETF announce list should be getting these notices. I do recall a gentleman mentioning in DC something about coordinating reasonable official submissions, and I feel this falls in line with that request. There's enough of a problem with spam that we can't do anything about, and I think dealing with this situation properly could have the potential to not only reduce some junk mail, but also allow that information to go out in an appropriate fashion to willing recipients, and perhaps educate some people (who's company supposedly caters to technology folk) along the way of proper edicate for such matters. And if they don't respond, who cares, just boot em
Re: List of Old Standards to be retired
I see this exercise has already reached the point of absurdity. How can it possibly be worth anyone's time to look at each telnet option and determine whether it is deployed? What possible purpose could be achieved by changing the standards status of some telnet option? Is there some chance that someone is going to implement one of these by mistake somehow? A similar comment applies to the FDDI MIB. Are we trying to make sure that no one implements that MIB by mistake? Or that no one implements FDDI by mistake, just because he thinks there's an IETF standard about it? Let me echo Bob Braden's if it's not broken, why break it? query. ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: Organizationed spam RE: [Sip] WiMAX Summit'05 - Paris - France
Harald Tveit Alvestrand wrote: [EMAIL PROTECTED] has already been denied posting rights on at least one IETF WG mailing list because of this behaviour. Is it time to dig out RFC 3683/BCP 83? BTW - has anyone, anywhere ever seen a response from him/them when they have been asked to stop spamming the IETF lists? I have not. In my capacity of a chair of one of the lists to which this spam was sent, I give Gunter notice that such behavior is unacceptable. Several days later, I have received no response. I tried to find a mechanism for content-based filtering -- for example, to hold any posts containing the string upperside.fr for moderation -- but the current mailman interface doesn't seem to support this kind of content filtering. /a ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: List of Old Standards to be retired
Eliot Lear wrote: This is an update from the Old Standards experiment. Below are a list of proposed standards that are candidates to be obsoleted. RFC1793 Extending OSPF to Support Demand Circuits the NEMO Basic Support protocol http://www.ietf.org/internet-drafts/draft-ietf-nemo-basic-support-03.txt has a reference to RFC 1793. a Mobile Router could run OSPF with its Home Agent from a remote location through a tunnel to the Home Agent. the NEMO spec recommends that the tunnel between the Home Agent and the Mobile Router be treated as a demand circuit. there is no implementation of this, however, AFAIK. Vijay ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
RE: New Last Call: 'Tags for Identifying Languages' to BCP
From: [EMAIL PROTECTED] [mailto:ietf-languages- [EMAIL PROTECTED] On Behalf Of Bruce Lilly The point is that under RFC 3066, the bilingual ISO language and country code lists are considered definitive. That is nowhere stated or even suggested in RFC 3066. RFC 3066 section 2.2 states, in part: - All 2-letter subtags are interpreted according to assignments found in ISO standard 639, Code for the representation of names of languages [ISO 639], or assignments subsequently made by the ISO 639 part 1 maintenance agency or governing standardization bodies. and has a similar statement regarding ISO 3166. interpreted according to assignments found in certainly sounds as if the ISO lists are considered definitive for their respective categories of subtags, since their interpretation is specified as that given in those lists. I don't see how the RFC 3066 text can be interpreted otherwise. You're now quoting things so far removed from their context that they are no longer being evaluated fairly. I believed we were talking about the specific strings, as you had made reference to implementers of bilingual products not having access to that data. Perhaps I misunderstood you, but whether or not, the relevant facts are that RFC 3066 referred to ISO source standards to establish the denotation of identifiers drawn from those standards, and the proposed revision does the same. Peter Constable Microsoft Corporation ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: [newtrk] Re: List of Old Standards to be retired
Eric Rosen wrote: Let me echo Bob Braden's if it's not broken, why break it? query. Because maybe it is broke. Even if someone *has* implemented the telnet TACACS user option, would a user really want to use it? The process is broke. We say in 2026 that proposed standards should hang around and there is good reason why they shouldn't. The stuff that does hang around falls into three categories: 1. that which works so well that we just never got around to advancing it 2. that which was useful at some point but is no longer 3. that which was never useful, and what we really had was a failed experiment. In both [2] and [3] if someone lacking experience decides to (re)implement one of these that person is likely in for a snoot full of trouble by way of security and interoperability owing to the fact that the world has changed since many of these documents were written. And if something wasn't useful in the first place, perhaps smarter people than that someone figured out why. This is a simple way to simply do what we said we were going to do. Eliot ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: [newtrk] Re: List of Old Standards to be retired
On Thu, 16 Dec 2004, Brian E Carpenter wrote: James M. Polk wrote: I'm initially really surprised 1518/1519 is on this list. Obviously, it's a bug. Of the Proposed Standards that the Internet runs on, those are among the most important. I believe this was pointed out on the old-standards list already, but it must have got lost. Not really a bug. Note that the to-be-historic list does not mention this: RFC1517 Applicability Statement for the Implementation of Classless Inter-Domain Routing (CIDR) This is the best document to use as a basis for respinning the concept of CIDR, AFAICS. 1518/1519 are full of address assignment etc. details which were out of date or inappropriate for a standards track document already 5 years ago. There's very small amount of useful information to salvage from those. -- Pekka Savola You each name yourselves king, yet the Netcore Oykingdom bleeds. Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: List of Old Standards to be retired
Carsten Bormann wrote: RFC1618 PPP over ISDN We had a short discussion about this in pppext. The gist was: The document is pretty bad (partly because things were murky in 1994, but also because it was written by Martians that had no space ship to take them to the ISDN planet), (sorry, I've given up reading IETF lists regularly, but I was pointed at this comment.) The document was written in 1992-1993 based on using real equipment over Ameritech lines in Ann Arbor, Michigan. In those days, I was so personally dedicated to the IETF that I actually moved to Ann Arbor to test and use it, as it was the first place in the state to offer ISDN. I've heard that things differ in other places in the world. But other places in the world participated in the lively design and implementation discussion. Without that discussion, it would have been octet-sync only, but others felt the need for bit-sync. Moreover, that bit-sync be preferred over octet-sync, as some places in the world would actually lose octet alignment over time. Horrors! Now that backbones use fiber this probably happens a lot less, but those were the realities of the day. The specification was implemented by me in at least 2 product lines. I've heard that it was implemented by others as well. But, I've never seen results of any interoperability testing, and thus it was never advanced toward standard. Most folks seemed to just buy the same vendor for both ends of the link. but some parts of it do describe what currently shipping, actively marketed products do (and should do) in this domain. And that needs to be documented on the PPP list. I found the nroff, and would be happy to document interoperability, should there be any. -- William Allen Simpson Key fingerprint = 17 40 5E 67 15 6F 31 26 DD 0D B9 9B 6A 15 2C 32 ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: [newtrk] Re: List of Old Standards to be retired
This is a simple way to simply do what we said we were going to do. The worries about this whole anti-cruft business have always been (a) the likelihood that it would do more harm than good, and (b) the likelihood that it would waste enormous amounts of time on issues of no importance. The initial foray into this area doesn't do much to relieve these worries. Even if someone *has* implemented the telnet TACACS user option, would a user really want to use it? I don't know. Do you? How do we go about answering a question like that? How much time should the IETF spend determining the answer to this question? It's just better to leave well enough alone. ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: IASA BCP -02 Designated Donations - section 5.3
Let me try a slightly different cut on the discussion. 1/ I believe the IETF is trying to address the fact we would like to be able to accept support in chunks that are greater than individual meeting fees, and less than $100kUS. IMHO, it's not that the IETF needs to be able to accept donations in *any* size between those, but I have heard people say that they know the person in their company who could write a cheque for $40k, if it will pecifically support the IETF, but there's no way they can get $100k through their budget. 2/ I believe we've also heard the IETF say that it wants to be able to clearly identify its collected assets (and, as the flipside, is willing to pay for all of its expenses). This is driven by a lot of factors, but I think the an important one is that the IETF believes it can and should be financially viable. Taking the bad along with the good, we want to be in an environment where we can prove that out empirically. 3/ We've heard clear explanations that attracting and managing corporate donations is not a simple task. Specifically, that there are reasons that it's not a simple matter to drop the level of donation necessary for designating donations. I don't believe the BCP needs to have specific text about *how* 1/ and 2/ are achieved. The current text is about how, and perhaps that's why it does not reconcile with 3/. The question is, do we all believe 1/ and 2/ are achievable? If we do have a meeting of the minds that they are, given the constrains in 3/, then what we have is only a wording problem to capture that meeting of the minds. If we do not have such a meeting of the minds, then we should figure out fast whether it's a difference of opinion, or whether 1/ and/or 2/ are not reasonably achievable in any universe. Leslie. Brian E Carpenter wrote: Bert, that does not change the need for the ISOC accountants to generate a separate entry for each case and for the auditors to check each of those entries. It's a real cost, because accountancy and auditing cost real money. Brian Wijnen, Bert (Bert) wrote: Inline Biran answered me: Wijnen, Bert (Bert) wrote: I am not a real accountant and kind of simple-minded. So when you say: Lynn == Lynn St Amour [EMAIL PROTECTED] writes: Lynn over 80% of ISOC's org. members donate less than $10K Lynn annually and managing these in a 'restricted accounting Lynn manner' requires more effort and overhead. Also, Lynn organizations/donors expect recognition appropriate to their Lynn contribution and that implies differing levels of value and Lynn distinction. I then wonder - if there is s separate or special bank account for IASA/ETF - if I can just deposit my donation into that bank account - What then is the more effort and overhead ?? I just do not understand. Bert, I'm sure Lynn will answer this too, but from when the ISOC was discussing accounting practices for individual member subscriptions and donations, I remember that the bank account aspect is the least of the worries (and anyway, we already reached consensus not to have a separate bank account). I am not even talking about separate bank account as we did in an early rev of the iasa-bcp doc. I am talking about an ISOC bank account that will ONLY receive donations targeted for a specific purpose. By depositing money on the specific bank account, you IMPLICITLY tell ISOC that the money is intended for a specific purpose, in this case IETF. Again it must be the simple-minded me who does not understand. Bert he issue is that accounting entries have to be made in a very specific way for money which is tied to a specific purpose, and while that is a small overhead if someone donates $100k, it becomes a significant overhead if 100 people donate $1k. It can end up eating money for accounting actions that really serve no useful purpose but have to be done to follow thr accounting rules. So I think Lynn is correct and we have to give ISOC the necessary flexibility. Brian ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf -- --- Reality: Yours to discover. -- ThinkingCat Leslie Daigle [EMAIL PROTECTED] --- ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: [newtrk] List of Old Standards to be retired
Bob Braden wrote: If it's not broken, why break it? * Standards have been invented for creating markets. That's strange, all these years I thought standards were for interoperability. Hear, Hear! Folks, I took a look at the first posting, and was surprised at those where I'm personally knowledgable. RFC1378 The PPP AppleTalk Control Protocol (ATCP) It was widely implemented. I still use this. My $1000 HP LaserJet 4ML works fine, it hasn't run out its original cartridge, but I need appletalk for it. RFC1552 The PPP Internetworking Packet Exchange Control Protocol (IPXCP) RFC1553 Compressing IPX Headers Over WAN Media (CIPX) Again, widely implemented. Sure, IPX wasn't a very good protocol, but I'm aware of rather a large number of sites that still run it. Sure, Novell refused to divulge the contents of some of the fields, so we just had to carry undifferentiated bytes around, but it worked RFC1598 PPP in X.25 RFC1618 PPP over ISDN At one time, these were incredibly important in the 3rd world, and some parts of Europe and Japan. Is X.25 completely non-existant today? Heck, folks were running X.25 over ISDN D-channels, and those still exist on every PRI circuit Admittedly, some of this may be nostalgia, as X.25 was the second protocol I ever implemented, circa 1978 before so much cruft was saddled upon it through the standardization process. It seems to me that besides the ossification of the IETF that keeps it from getting much of anything worthwhile done, some folks have lost sight of the inter part of networking. RFC1828 IP Authentication using Keyed MD5 RFC1829 The ESP DES-CBC Transform Now *THESE* were historic when written! Due to US government pressure, it took years (and big plenary protests) for them to be published! Especially without the 40-bit export restrictions! At the time, I advocated Triple-DES to be the Proposed Standard, since we already knew 56-bit DES was broken. I requested Historic status for these many years ago -- William Allen Simpson Key fingerprint = 17 40 5E 67 15 6F 31 26 DD 0D B9 9B 6A 15 2C 32 ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: IASA BCP -02 Designated Donations - section 5.3
Hi Leslie - There's something I'm not quite understanding, and I was wondering if others might share my confusion. I can think of two reasons why taking small targeted donations is bad: 1. It's a pain to administer and account for. 2. It screws up the overall marketing plan in some way (e.g., should a $1 donor get their name on the web page, should bigger sponsors be part of some bundling strategy, etc...). I could understand 1. being a problem if people could designate specifically what they want (e.g., support the newtrk working group). But, if the only designation available is support of the IETF, it is a pretty simple accounting transaction to book all receipts with that designation as Discretionary Funds Used for IASA. It becomes a line-item on the income statement and balance sheet, and becomes one line in the annual tax return under restricted contributions received. If the number becomes high, there are some implications for the public support test the IRS uses, but that doesn't seem to be an issue for the forseeable future. My confusion is whether people think that designating means the donor writes the conditions or whether it simply means support of IASA. If it is the latter, it really isn't that tough to administer. If it is the former, I'd be kicking and screaming if I were Lynn. :)) As to the second reason why one might not do this, my own personal opinion is that if people want to make any size contribution to the IETF and there are no strings attached, we shouldn't be so proud as to say no. Regards, Carl Let me try a slightly different cut on the discussion. 1/ I believe the IETF is trying to address the fact we would like to be able to accept support in chunks that are greater than individual meeting fees, and less than $100kUS. IMHO, it's not that the IETF needs to be able to accept donations in *any* size between those, but I have heard people say that they know the person in their company who could write a cheque for $40k, if it will pecifically support the IETF, but there's no way they can get $100k through their budget. 2/ I believe we've also heard the IETF say that it wants to be able to clearly identify its collected assets (and, as the flipside, is willing to pay for all of its expenses). This is driven by a lot of factors, but I think the an important one is that the IETF believes it can and should be financially viable. Taking the bad along with the good, we want to be in an environment where we can prove that out empirically. 3/ We've heard clear explanations that attracting and managing corporate donations is not a simple task. Specifically, that there are reasons that it's not a simple matter to drop the level of donation necessary for designating donations. I don't believe the BCP needs to have specific text about *how* 1/ and 2/ are achieved. The current text is about how, and perhaps that's why it does not reconcile with 3/. The question is, do we all believe 1/ and 2/ are achievable? If we do have a meeting of the minds that they are, given the constrains in 3/, then what we have is only a wording problem to capture that meeting of the minds. If we do not have such a meeting of the minds, then we should figure out fast whether it's a difference of opinion, or whether 1/ and/or 2/ are not reasonably achievable in any universe. Leslie. Brian E Carpenter wrote: Bert, that does not change the need for the ISOC accountants to generate a separate entry for each case and for the auditors to check each of those entries. It's a real cost, because accountancy and auditing cost real money. Brian Wijnen, Bert (Bert) wrote: Inline Biran answered me: Wijnen, Bert (Bert) wrote: I am not a real accountant and kind of simple-minded. So when you say: Lynn == Lynn St Amour [EMAIL PROTECTED] writes: Lynn over 80% of ISOC's org. members donate less than $10K Lynn annually and managing these in a 'restricted accounting Lynn manner' requires more effort and overhead. Also, Lynn organizations/donors expect recognition appropriate to their Lynn contribution and that implies differing levels of value and Lynn distinction. I then wonder - if there is s separate or special bank account for IASA/ETF - if I can just deposit my donation into that bank account - What then is the more effort and overhead ?? I just do not understand. Bert, I'm sure Lynn will answer this too, but from when the ISOC was discussing accounting practices for individual member subscriptions and donations, I remember that the bank account aspect is the least of the worries (and anyway, we already reached consensus not to have a separate bank account). I am not even talking about separate bank account as we did in an early rev of the iasa-bcp doc. I am talking
Re: [newtrk] List of Old Standards to be retired
At 05:53 PM 12/16/2004, William Allen Simpson wrote: RFC1828 IP Authentication using Keyed MD5 RFC1829 The ESP DES-CBC Transform Now *THESE* were historic when written! Due to US government pressure, it took years (and big plenary protests) for them to be published! Especially without the 40-bit export restrictions! The attack against these was presented at the Danvers IETF. I had requested that they go to historic (along with 1827) once the 2401 series of IPsec RFCs were published. The request fell through the bit mask. ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: [newtrk] Re: List of Old Standards to be retired
Hi, On Thu, 16 Dec 2004, John C Klensin wrote: [...] I suggest that the RFC Editor's traditional rule about normative references from standards track documents to things of a lower maturity level should apply here as well, even going backwards. If you think there is value in RFC 1517, and it makes normative reference to 1518 and 1519 (which it does-- I just checked), then 1518 and 1519 are live documents. If one reclassifies them to historic, one risks really confusing users/readers and doing a world of harm. If you think it is worth keeping the content of 1517 while removing 1518 and 1519 from the standards track, then I think you need to arrange to replace (obsolete) 1517 with a new document that stands alone, without those normative references. Such a document could, of course, obsolete all three of 1517-1519, which would eliminate the need for any processing in the cruft arrangements. Correct, though 1517 only has a single References section, giving the RFC-editor/IESG some leeway which ones to consider normative. If that is what it takes, a 5 page document -- based on RFC1517 -- could be easily written which would convey the CIDR principles without having to normatively reference the other documents. I think I agree with you that we cannot just recycle 1517 (or any other CIDR document) to DS, it'll require some polishing. -- Pekka Savola You each name yourselves king, yet the Netcore Oykingdom bleeds. Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: [newtrk] Re: List of Old Standards to be retired
Eric Rosen wrote: Even if someone *has* implemented the telnet TACACS user option, would a user really want to use it? I don't know. Do you? Yes, I do. Many of us do. And that's the point. How do we go about answering a question like that? We will spend less time discussing that option then we will the meta conversation, it seems. ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: [Old-standards] Re: [newtrk] List of Old Standards to be retired
Carsten, please read draft-ietf-newtrk-cruft-00.txt, in particular section 3.2, and see if it answers your question this has been a major discussion source Harald --On 16. desember 2004 15:40 +0100 Carsten Bormann [EMAIL PROTECTED] wrote: So what does HISTORIC mean? -- bad protocol (advice is to get rid of it), as in RIPv1 -- bad specification, but the protocol is alright -- an underlying/related technology is dying out slowly -- an underlying/related technology is used mainly in parts of the world many IETFers don't visit that often -- the market is stable, so there won't be new implementations -- existing open source implementations are doing well, so there won't be new implementations -- there is unlikely to be new development about this standard, as in IPv4 ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: [newtrk] List of Old Standards to be retired
RFC0885 Telnet end of record option This option was, at least at one time, used for telnet clients that connected to IBM mainframes... It was used to indicate the end of a 3270 datastream. I don't know if it is still used in that fashion, but Bob Moskowitz might know. RFC1041 Telnet 3270 regime option I'm not sure what this was ever used for, but again Bob Moskowitz would be a good person to ask if this is still in-use. RFC1269 Definitions of Managed Objects for the Border Gateway Protocol: Version 3 Why would this be cruft? The BGP4 MIB was just recently approved... RFC1518 An Architecture for IP Address Allocation with CIDR RFC1519 Classless Inter-Domain Routing (CIDR): an Address Assignment and Aggregation Strategy CIDR is still in-use and rather frequently discussed in other documents. Are there newer references or something? Margaret ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: List of Old Standards to be retired
Eliot Lear wrote: RFC1277 Encoding Network Addresses to Support Operation over Non-OSI Lower Layers This is still in use. draft-melnikov-nsap-ipv6-00.txt references it and in theory it can be updated to include bits of RFC 1277 which are still relevant. ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: Draft version of the IAD job announcement from the IASA TT
On 16 dec 2004, at 04.18, Kurt Erik Lindqvist wrote: -BEGIN PGP SIGNED MESSAGE- The IETF Administrative Entity Isn't it the transition team that is seeking the IAD at this point? is seeking a highly capable individual to serve as Administrative Director. You will report to the Internet Administrative Oversight Committee (IAOC) be accountable to the IETF community. This is a highly visible and very demanding job. Shouldn't we state explicitly that the IAD will be an employee of ISOC? You will be expected to: o Working with the IAOC to document and cater for the administrative requirements of the IETF, IESG, IAB and IRTF. cater is a difficult word that ussually refers to food. I would recommend 'provide for' o Establish the IASA/IETF annual budgets, and the financial administration and reporting of IASA/IETF. These should be established in cooperation with ISOC and IASA. This will not be done in isolation. o Work with ISOC and various service providers to establish appropriate agreed budgets and related financial and performance reporting. o Contract negotiations with service providers, and establish procedures for meassuring the performance of these providers. o Eventual mangagement of support staff and contractors. o Serve as the day-to-day chief operating officer of the IETF, managing a number of contractors and working with a number of volunteers. Have we gone so far as to call this job the COO of the IETF? Not only is the IETF not an organization that is structured to have a COO, but i think giving this position the COO designation may be misleading. o Work with our liaison organizations, such as the RFC Editor and the IANA. liaison? o Serve as the primary staff resource for the governing body of the administrative entity for the IETF. What does this mean? o Work with your contractors and members of the IETF community to provide adequate support and planning for 3 IETF meetings annually, and for frequent meetings and teleconferences of the IAB, IESG, and other bodies that support the IETF. The following characteristics are necessary for this job: o This job is public service. You should be able to work successfully with large numbers of people. This requires a high clock rate, a large stack, Well, i understand how you would measure these thing in a robot, but I am not sure how to determine these capabilities in a human. I think, it might be better to refer to these attributes in human terms; something like the ability to handle a multitude of simultaneous tasks. and the ability to listen carefully. o This is an operations job. IETF meetings are large and complex, and the day-to-day activities of the standards-making process is demanding. You should be adept at getting real results and helping large groups work together towards common goals and deadlines. should we mention that the nature of working together is consensus based? o This is a public job. You will be required to present the results and achievements of the IASA in front of the community as well as dealing with questions from individual members of the community. The goal of IASA is to achieve as much transparency and accountability? as possible so good communication skills, and previous similar experiences are valued. o This job requires a financially astute individual. The IETF is a $2-$3 million/year operation. IETF funds are tight and we expect you to take leadership in establishing our budgetary procedures, our procurement standards, and understanding our revenue sources. In-depth familiarity with the IETF prior to assuming this position is not required, but you must be able to quickly get up to speed and learn the unique culture and requirements of the organization. Should we require experience in running a similar type of operation? Likewise, long-term technical experience is not required, but you must be a quick learner and adept at using the Internet effectively. The Internet Society is based in Reston, Virginia and the job will require a high level of travel for IETF meetings and preparation and related meetings. You may work out of a home office as a telecommuter, or use the Internet Society facilities in Virginia. In either case, you should be prepared to travel to Virginia, IETF meetings, and the locations where the IETF has contractors. Salary levels commensurate with experience and qualifications. you might want to ask applicants to state salary requirements You must be fluent in spoken and written english. Applicants should forward a resume, references, should ask for a certain number of references and any other relevant materials, with a cover letter explaining why they feel they are the right person for this position written in text or PDF, in an email sent to [EMAIL PROTECTED] Applications will be evaluated starting January
RFC1269 - [was: RE: [newtrk] List of Old Standards to be retired]
W.r.t. RFC1269 Definitions of Managed Objects for the Border Gateway Protocol: Version 3 Why would this be cruft? The BGP4 MIB was just recently approved... Good thing too. Take a good look at 1269. I don't think it would pass a MIB compiler test today. If you approved the BGP4-MIB, ought not that have obsoleted this guy? The new doc (in IESG evaluation status) is draft-ietf-idr-bgp4-mib-15.txt And its abstract says it all: Abstract This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community In particular, it describes managed objects used for managing the Border Gateway Protocol Version 4 or lower. The origin of this memo is from RFC 1269 Definitions of Managed Objects for the Border Gateway Protocol (Version 3), which was updated to support BGP-4 in RFC 1657. This memo fixes errors introduced when the MIB module was converted to use the SMIv2 language. This memo also updates references to the current SNMP framework documents. This memo is intended to document deployed implementations of this MIB module in a historical context, provide clarifications of some items and also note errors where the MIB module fails to fully represent the BGP protocol. Work is currently in progress to replace this MIB module with a new one representing the current state of the BGP protocol and its extensions. This document obsoletes RFC 1269 and RFC 1657. Distribution of this memo is unlimited. Please forward comments to [EMAIL PROTECTED] So 1269 will soon be made OBSOLETED I will look at other MIB related documents next week. Bert ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: [newtrk] List of Old Standards to be retired
* From [EMAIL PROTECTED] Thu Dec 16 05:23:25 2004 * Mime-Version: 1.0 * Date: Thu, 16 Dec 2004 08:02:44 -0500 * To: Eliot Lear [EMAIL PROTECTED], IETF Discussion [EMAIL PROTECTED] * From: Margaret Wasserman [EMAIL PROTECTED] * X-Spam-Score: 0.1 (/) * X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 * Cc: '[EMAIL PROTECTED]' [EMAIL PROTECTED], *[EMAIL PROTECTED] * Subject: Re: [newtrk] List of Old Standards to be retired * List-Id: IETF-Discussion ietf.ietf.org * X-ISI-4-32-5-MailScanner: Found to be clean * X-ISI-4-30-3-MailScanner: Found to be clean * X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham *version=2.64 * * * RFC0885 Telnet end of record option * * This option was, at least at one time, used for telnet clients that * connected to IBM mainframes... It was used to indicate the end of a * 3270 datastream. I don't know if it is still used in that fashion, * but Bob Moskowitz might know. * I don't see that usage matters in the least. The EOR option provides a function that was useful at one time and may be useful again. It is not technically unsound. I don't see any excuse to change the category of this document. Bob Braden (speaking for himself) ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: List of Old Standards to be retired
From: Eric Rosen [EMAIL PROTECTED] I see this exercise has already reached the point of absurdity. How can it possibly be worth anyone's time to look at each telnet option and determine whether it is deployed? What possible purpose could be achieved by changing the standards status of some telnet option? Is there some chance that someone is going to implement one of these by mistake somehow? A similar comment applies to the FDDI MIB. Are we trying to make sure that no one implements that MIB by mistake? Or that no one implements FDDI by mistake, just because he thinks there's an IETF standard about it? Let me echo Bob Braden's if it's not broken, why break it? query. Spending time revising old RFCs of living protocols is unlikely to do much good and has potential for plenty of harm. It's hard to avoid the temptation to fix things (parts of RFC 1668 and RFC 1661 tempt me), but such fix-it efforts usually produce incompatible protocols. The IETF definition or RIPv1 was compatible only because it was a strict subset of the real protocol. The IETF version of the printer protocol was just plain broken. Other targets of this exercise describe protocols that were never implemented and should never have been allowed on the standards track. Why not scale back the exercise to attack only obvioulsy dead or stillborn protocols? Vernon Schryver[EMAIL PROTECTED] ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: RFC1269 -
Eliot Lear writes: I'll remove it from the list with the expectation that the new MIB will obsolete the old one. However, I note that is currently not stated in the header of the draft. I think RFC1269 (BGP-3 MIB) can safely be dropped even today, because nobody is using BGP-3 anymore, and as Bert pointed out, we already have RFC1657 (BGP-4 MIB). RFC1657 is what people use today. By the way, draft-ietf-idr-bgp4-mib-15.txt is a relatively minor update to RFC 1657, and misses many recent additions to BGP-4 that are widely used, such as support for multiple address families etc. There was an attempt at writing a modernized BGP-4 MIB, but that seems to have stalled (draft-ietf-idr-bgp4-mibv2-05.txt is a tombstone). Did I mention that writing MIBs is harder than it should be? -- Simon. ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: [newtrk] List of Old Standards to be retired
William Allen Simpson [EMAIL PROTECTED] writes: RFC1598 PPP in X.25 RFC1618 PPP over ISDN At one time, these were incredibly important in the 3rd world, and some parts of Europe and Japan. Is X.25 completely non-existant today? Heck, folks were running X.25 over ISDN D-channels, and those still exist on every PRI circuit For what it's worth, the AX.25 protocol number in IPv4 is still used by some poor souls. (Carries just about 3MB/day on the Abilene backbone and used to be several times more.) http://netflow.internet2.edu/weekly/longit/protocols93-octets.png -- Stanislav Shalunov http://www.internet2.edu/~shalunov/ This message is designed to be viewed upside down. ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: [newtrk] Re: List of Old Standards to be retired
--On Thursday, 16 December, 2004 22:07 +0200 Pekka Savola [EMAIL PROTECTED] wrote: On Thu, 16 Dec 2004, Brian E Carpenter wrote: James M. Polk wrote: I'm initially really surprised 1518/1519 is on this list. Obviously, it's a bug. Of the Proposed Standards that the Internet runs on, those are among the most important. I believe this was pointed out on the old-standards list already, but it must have got lost. Not really a bug. Note that the to-be-historic list does not mention this: RFC1517 Applicability Statement for the Implementation of Classless Inter-Domain Routing (CIDR) This is the best document to use as a basis for respinning the concept of CIDR, AFAICS. 1518/1519 are full of address assignment etc. details which were out of date or inappropriate for a standards track document already 5 years ago. There's very small amount of useful information to salvage from those. Pekka and others, I suggest that the RFC Editor's traditional rule about normative references from standards track documents to things of a lower maturity level should apply here as well, even going backwards. If you think there is value in RFC 1517, and it makes normative reference to 1518 and 1519 (which it does-- I just checked), then 1518 and 1519 are live documents. If one reclassifies them to historic, one risks really confusing users/readers and doing a world of harm. If you think it is worth keeping the content of 1517 while removing 1518 and 1519 from the standards track, then I think you need to arrange to replace (obsolete) 1517 with a new document that stands alone, without those normative references. Such a document could, of course, obsolete all three of 1517-1519, which would eliminate the need for any processing in the cruft arrangements. john ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Last Call: 'Internet Control Message Protocol (ICMPv6)for the Internet Protocol Version 6 (IPv6) Specification' to Draft Standard
The IESG has received a request from the IP Version 6 Working Group WG to consider the following document: - 'Internet Control Message Protocol (ICMPv6)for the Internet Protocol Version 6 (IPv6) Specification ' draft-ietf-ipngwg-icmp-v3-06.txt as a Draft 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 [EMAIL PROTECTED] or [EMAIL PROTECTED] mailing lists by 2005-1-2. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-ipngwg-icmp-v3-06.txt Implementation Report can be accessed at http://www.ietf.org/IESG/implementation.html ___ IETF-Announce mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf-announce
