Re: Recall petition for Mr. Marshall Eubanks
On 01/11/2012 21:45, Sam Hartman wrote: ... At this point, I believe the recall process is the correct process to follow unless there is an approved BCP update. In a case where there's been no contact and there's an argument we've found a gap in the procedures I can see the argument for creativity. However, according to Bob's note, Marshall has been contacted and rather than resigning, said he would consider resigning. I hope he does. Until he does, though, by considering resigning rather than resigning, he has implied that there might be a reason not to resign. In my mind that moves us out of a situation where creative interpretations of vacancy are appropriate. I agree, with some sadness. (I am, as it happens, not NomCom eligible right now.) Brian
RE: Recall petition for Mr. Marshall Eubanks
I also, with regret, would like to add my name to the recall petition. I am NomCom eligible. Thanks, Steve
Re: Recall petition for Mr. Marshall Eubanks
Brian, I would like to express my sadness as well, adding that I am most probably not NomCom eligible. I was only 23 when one of my freinds, community activist in the students circle of the university, committed a suicide. Three years later it happened again, by one other freind of us. I feel that there is a danger that this might happen again, especially in this case. Apparently Marshall still think that he could return to his IETF work in the near future. How could we help him, this is my question, How can we taylor the rules of our work, allowing to go for a sabbatical period and return later, with quick reintegration? Á bientot, Géza On Fri, Nov 2, 2012 at 9:03 AM, Brian E Carpenter brian.e.carpen...@gmail.com wrote: On 01/11/2012 21:45, Sam Hartman wrote: ... At this point, I believe the recall process is the correct process to follow unless there is an approved BCP update. In a case where there's been no contact and there's an argument we've found a gap in the procedures I can see the argument for creativity. However, according to Bob's note, Marshall has been contacted and rather than resigning, said he would consider resigning. I hope he does. Until he does, though, by considering resigning rather than resigning, he has implied that there might be a reason not to resign. In my mind that moves us out of a situation where creative interpretations of vacancy are appropriate. I agree, with some sadness. (I am, as it happens, not NomCom eligible right now.) Brian
Re: Recall petition for Mr. Marshall Eubanks
On 01/11/2012 19:43, Fred Baker (fred) wrote: On Nov 1, 2012, at 9:32 AM, Olaf Kolkman wrote: I also offer my signature under the recall procedure, in case pragmatism doesn't prevail (see my other note). My offer of signature should in no way be interpreted as reflecting an opinion about Marshall's character. Ditto, and Ditto. +1 and +1. Henk -- -- Henk Uijterwaal Email: henk(at)uijterwaal.nl http://www.uijterwaal.nl Phone: +31.6.55861746 -- Read my blog at http://www.uijterwaal.nl/henks_hands.html
RE: Antitrust FAQ
At a high level, I'm curious what the difference is between an FAQ and a formal policy? I ask since Section 6 of the FAQ seems to be providing instructions on how IETF participants should conduct themselves, which seems more like a policy than an FAQ. Thanks, David -Original Message- From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of IETF Chair Sent: Wednesday, October 10, 2012 8:41 PM To: IETF Cc: Jorge Contreras Subject: Antitrust FAQ The IETF does not have a formal antitrust policy. In fact, the ANTITRUST BOF concluded that a formal policy was not needed. However, educational material is needed so that all IETF participants are aware of the the law. The first draft of a FAQ to fill this need has been developed. Please review the FAQ, and if you discover any issues raise them in response to this message. http://www.ietf.org/playground/antitrust-faq.html Thanks, Russ
mailing list memberships reminder - passwords in the clear
Why does the mailing list memberships reminder send passwords in the clear? For everything else I'm subscribed to, if I forget my details, one click sends a one-time password-reset link. Passwords are never mailed out, and never shown. Thanks, P.
Re: mailing list memberships reminder - passwords in the clear
In article 5092d99f.3070...@cisco.com you write: Why does the mailing list memberships reminder send passwords in the clear? Because that's what Mailman does. Send code. -- Regards, John Levine, jo...@iecc.com, Primary Perpetrator of The Internet for Dummies, Please consider the environment before reading this e-mail. http://jl.ly
Re: mailing list memberships reminder - passwords in the clear
On 1 Nov 2012, at 20:20, Paul Aitken pait...@cisco.com wrote: Why does the mailing list memberships reminder send passwords in the clear? Because mailman is brain-dead stupid. See: http://www.jwz.org/doc/mailman.html Sadly, and despite my best efforts to find alternative mailing list software, mailman wins on popularity (ugh) and hence support with practically no competition. Only majordomo2, which has been unmaintained for a while now (and it's author calls it Dead holds much of a chance, but I doubt it would work for the IETF in its current condition. But have hope! The IETF serves the mailman interface over TLS, and it is an option that you can exercise *not* to have passwords mailed to you. Go to your membership options page, and in the group containing the option to turn off the membership reminders, check the checkbox to make it global. Later, you can have the password mailed to you on demand, or unsubscribe without needing a password at all (email confirmation loop). For everything else I'm subscribed to, if I forget my details, one click sends a one-time password-reset link. Passwords are never mailed out, and never shown. Yes. Sadly this isn't possible with mailman; you will always be mailed your password if you need it and can't remember it. HTH. Cheers, Sabahattin
Re: mailing list memberships reminder - passwords in the clear
Apparently no need to send code. Mailman project claims this is fixed in development version 3 (not yet released) discussion on plain text passwords http://mail.python.org/pipermail/mailman-users/2010-July/069844.html project todo list http://wiki.list.org/display/DEV/Mailman+3.0 (down under privacy, claims passwords will not be /en clair/) On Nov 2, 2012, at 11:24 AM, John Levine wrote: In article 5092d99f.3070...@cisco.com you write: Why does the mailing list memberships reminder send passwords in the clear? Because that's what Mailman does. Send code. -- Regards, John Levine, jo...@iecc.com, Primary Perpetrator of The Internet for Dummies, Please consider the environment before reading this e-mail. http://jl.ly
Re: [mpls] Last Call: draft-ietf-mpls-ipv6-pw-lsp-ping-03.txt (LabelSwitched Path (LSP) Ping for IPv6 Pseudowire FECs) toProposed Standard
I worry about the allocation of sub-TLVs in this I-D. It calls for The following Sub-TLV changes, which comprise three updates and two additions, are made for two TLV Types in the aforementioned sub- registry: TLV Type 1 for Target FEC Stack, and TLV Type 21 for Reply Path. and it is the Type 21 that worries me. IANA has, for Type 21, Reply Path (TEMPORARY - expires 2012-01-20) [draft-ietf-mpls-return-path-specified-lsp-ping] and I am unclear what the rules are about updates to expired, TEMPORARY, allocations. I worry too that [draft-ietf-mpls-return-path-specified-lsp-ping] while confirming the reservation of Type 21 takes a different tack for sub-TLVs, namely According to the guidelines defined in [RFC5226], the sub-TLV range of Reply Path TLV are partitioned as following: 0-31743 - Reserved, and MUST NOT be allocated. so quite what this I-D will do to that I-D worries me. And I worry yet more that other I-Ds, such as draft-zjns-mpls-lsp-ping-relay-reply-00 are heading down the track with further updates in this area of the MPLS namespace (except that this particular one seems to have abandoned sub-TLVs). Tom Petch - Original Message - From: The IESG iesg-secret...@ietf.org To: IETF-Announce ietf-annou...@ietf.org Cc: m...@ietf.org Sent: Wednesday, October 24, 2012 9:31 PM The IESG has received a request from the Multiprotocol Label Switching WG (mpls) to consider the following document: - 'Label Switched Path (LSP) Ping for IPv6 Pseudowire FECs' draft-ietf-mpls-ipv6-pw-lsp-ping-03.txt as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2012-11-09. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract Multi-Protocol Label Switching (MPLS) Label Switched Path (LSP) Ping and traceroute mechanisms are commonly used to detect and isolate data plane failures in all MPLS LSPs including Pseudowire (PW) LSPs. The PW LSP Ping and traceroute elements, however, are not specified for IPv6 address usage. This document extends the PW LSP Ping and traceroute mechanisms so they can be used with IPv6 PWs, and updates RFC 4379. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-mpls-ipv6-pw-lsp-ping/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-mpls-ipv6-pw-lsp-ping/ballot/ No IPR declarations have been submitted directly on this I-D. ___ mpls mailing list m...@ietf.org https://www.ietf.org/mailman/listinfo/mpls
Re: I* Member Removal Process
From: Russ Housley hous...@vigilsec.com And, the community does not have rough consensus for simply declaring his seat vacant under the current set of BCPs. Why not, I cannot fathom, because as SM has pointed out (hat tip), RFC 4333, IAOC Member Selection Guidelines and Process, has text which is exactly on point: if the appointed member is unable to serve the full two-year term, the selecting body may, at its discretion, immediately select a replacement to serve the remainder of the term using the interim process defined in Section 3.5.1. The document doesn't define in detail what constitutes unable to serve, but it clearly means via some form of incapacitation (death, severe illness, etc). Obviously, the intent of leaving un-stated exactly what constituted unable to serve the full two-year term was that it would be determined by common sense, applying the unable to serve test to the facts at hand. He's clearly unable to serve. I find it hard to see how someone who will not respond to _any_ form of communication, over a period of months, is '[]able to serve'. If the _only_ way to determine that someone is unable to serve the full two-year term is via the recall process, why didn't the document say that? There is just the bald statement that 'if someone is unable to serve, a replacment can be selected using the same process that selected them'. And he's definitely unable to serve. But I guess the IETF would rather deploy the most onerous, heavy-weight bureacratic process it can find (one intended for entirely different circumstances), as opposed to using the capability _already in its process documents exactly for cases like this_. Noel
Re: I* Member Removal Process
On 11/2/2012 12:09 PM, Noel Chiappa wrote: if the appointed member is unable to serve the full two-year term, the selecting body may, at its discretion, immediately select a replacement to serve the remainder of the term using the interim process defined in Section 3.5.1. The document doesn't define in detail what constitutes unable to serve, but Rhat is the specific and entire point. We have a substantial set of formal details, but we don't have that one. it clearly means via some form of incapacitation (death, severe illness, etc). Obviously, the intent of leaving un-stated exactly what constituted unable to serve the full two-year term was that it would be determined by common sense, applying the unable to serve test to the facts at hand. Your certitude about the intent of the framers and ratifiers of these formal documents is appealing, but unfortunately unfounded, since there is no documentation about that intent. Worse, it's not clear to me that even knowing their/our intent would suffice, in terms of being subject to external review for due process. He's clearly unable to serve. So you believe. I might also. He might or might not. I find it hard to see how someone who will not respond to _any_ form of communication, over a period of months, is '[]able to serve'. And more's the pity that our documents didn't cover such constructive resignation by voluntary vacancy. If the _only_ way to determine that someone is unable to serve the full two-year term is via the recall process, why didn't the document say that? There is just the bald statement that 'if someone is unable to serve, a replacment can be selected using the same process that selected them'. The problem is that the document doesn't specify anything about the conditions that define being unable to serve. The nature of this sort of formal document requires such specificity. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net
Re: [mpls] Last Call: draft-ietf-mpls-ipv6-pw-lsp-ping-03.txt (LabelSwitched Path (LSP) Ping for IPv6 Pseudowire FECs) toProposed Standard
Tom, On Nov 2, 2012, at 2:05 PM, t.p. daedu...@btconnect.com wrote: I worry about the allocation of sub-TLVs in this I-D. Thanks for the comments. I share worries about keeping synchronicity between sub-registries in this fashion. It calls for The following Sub-TLV changes, which comprise three updates and two additions, are made for two TLV Types in the aforementioned sub- registry: TLV Type 1 for Target FEC Stack, and TLV Type 21 for Reply Path. and it is the Type 21 that worries me. Right -- the allocations under Type 1 are straightforward. But the allocations under Type 21 seem to be standing over quicksand. IANA has, for Type 21, Reply Path (TEMPORARY - expires 2012-01-20) [draft-ietf-mpls-return-path-specified-lsp-ping] and I am unclear what the rules are about updates to expired, TEMPORARY, allocations. I worry too that [draft-ietf-mpls-return-path-specified-lsp-ping] while confirming the reservation of Type 21 takes a different tack for sub-TLVs, namely According to the guidelines defined in [RFC5226], the sub-TLV range of Reply Path TLV are partitioned as following: 0-31743 - Reserved, and MUST NOT be allocated. so quite what this I-D will do to that I-D worries me. Perhaps the best approach is to decouple. Have all Type 21 allocations under draft-ietf-mpls-return-path-specified-lsp-ping and have that point to the RFC from draft-ietf-mpls-ipv6-pw-lsp-ping if needed (and it can take a snapshot of the sub-registry when it will be stable.) Thanks, -- Carlos. And I worry yet more that other I-Ds, such as draft-zjns-mpls-lsp-ping-relay-reply-00 are heading down the track with further updates in this area of the MPLS namespace (except that this particular one seems to have abandoned sub-TLVs). Tom Petch - Original Message - From: The IESG iesg-secret...@ietf.org To: IETF-Announce ietf-annou...@ietf.org Cc: m...@ietf.org Sent: Wednesday, October 24, 2012 9:31 PM The IESG has received a request from the Multiprotocol Label Switching WG (mpls) to consider the following document: - 'Label Switched Path (LSP) Ping for IPv6 Pseudowire FECs' draft-ietf-mpls-ipv6-pw-lsp-ping-03.txt as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2012-11-09. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract Multi-Protocol Label Switching (MPLS) Label Switched Path (LSP) Ping and traceroute mechanisms are commonly used to detect and isolate data plane failures in all MPLS LSPs including Pseudowire (PW) LSPs. The PW LSP Ping and traceroute elements, however, are not specified for IPv6 address usage. This document extends the PW LSP Ping and traceroute mechanisms so they can be used with IPv6 PWs, and updates RFC 4379. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-mpls-ipv6-pw-lsp-ping/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-mpls-ipv6-pw-lsp-ping/ballot/ No IPR declarations have been submitted directly on this I-D. ___ mpls mailing list m...@ietf.org https://www.ietf.org/mailman/listinfo/mpls
Re: I* Member Removal Process
Noel, On Fri, Nov 2, 2012 at 8:09 PM, Noel Chiappa j...@mercury.lcs.mit.eduwrote: And he's definitely unable to serve. But I guess the IETF would rather deploy the most onerous, heavy-weight bureacratic process it can find (one intended for entirely different circumstances), as opposed to using the capability _already in its process documents exactly for cases like this_. Noel Marshall was clearly unable to serve in the past three months. The question is: Would it be possible for him to return within a couple of weeks, or not. I wish he could. However, this is unclear for me and I has no information at all. Best, Géza
Re: mailing list memberships reminder - passwords in the clear
Why does the mailing list memberships reminder send passwords in the clear? Because that's what Mailman does. Send code. And that's acceptable to the IETF? You're kidding me, right? I can't speak for the IETF, but I do note that the same password notices have been going out on the first of every month for years. You just noticed iit now? And once again, if you think it should do something else, send code. We're volunteers here. Assertions that it is very important for someone else to do work that you're not prepared to do are rarely effective. R's, John
Re: I* Member Removal Process
On Nov 1, 2012, at 9:52 PM, Russ Housley wrote: Mike: Yup. But I'd say their wishes would have a great deal of influence on whether or not this would go forward. And I'd still like to get at least some indication that this is their desired outcome at this point. I think, if nothing else, this needs to be part of whatever record considered by a recall committee. If I heard that only 1 or 2 members were indicating support for removal, I probably would withdraw my name from the petition signature. The IAOC was unanimous (minus Marshall, of course) in asking the community to declare the seat vacant. A vote was taken, and the minutes will confirm what I have stated here when they are published. The results of the E-Vote taking this action are included below. As stated these will be included in the minutes of the 25 October 2012 IAOC call. Bob From: Bob Hinden bob.hin...@gmail.com Subject: Results of IAOC E-Vote to Approve sending an email about the IAOC Vacancy to IETF Announce Date: October 22, 2012 8:08:27 AM PDT To: i...@ietf.org Cc: Bob Hinden bob.hin...@gmail.com The results of the E-Vote to Approve sending an email about the IAOC Vacancy to IETF Announce mailing list are: Ole Jacobsen [YES] October 17, 2012 11:30:31 PM GMT+02:00 Scott Bradner [YES] October 17, 2012 11:46:31 PM GMT+02:00 Russ Housley [YES] October 18, 2012 12:02:00 AM GMT+02:00 Bob Hinden [YES] October 18, 2012 6:18:34 AM GMT+02:00 Bernard Aboba [YES] October 18, 2012 7:22:48 PM GMT+02:00 Dave Crocker [YES] October 18, 2012 7:24:17 PM GMT+02:00 Lynn St. Amour [YES] October 19, 2012 6:55:06 PM EDT Marshall Eubanks [ ] The E-Vote passes. The results of the e-vote will be recorded in the minutes of the IAOC call being scheduled for 25 October 2012. The IOAC chair is authorized to send the attached email to the IETF announce list on Monday October 22, 2012. Bob Hinden IAOC Chair On Oct 17, 2012, at 11:24 PM, Bob Hinden wrote: IAOC, This is an official IAOC E-Vote, to close on Monday 22 October 2012 at 10am EST. A minimum of a 3/4 majority of the IAOC voting Yes is required for the motion to pass. RESOLUTION The IAOC approves send a message to the IETF-Announce list asking the community to declare Marshall Eubanks position on the IAOC vacant. A draft of the email is attached to this E-Vote. Please let me know your vote by responding to this message to the full IAOC list. You may vote Yes (in favor approving the resolution), No (opposed), or you may formally abstain. Passing the resolution requires both a quorum and a 3/4 majority of the IAOC voting Yes. The motion will pass if this is reached on or before the closing date. The results of the E-Vote will be recorded into the minutes of the next IAOC meeting. Regards, Bob Hinden IAOC Chair Bernard Aboba [ ] Lynn St. Amour [ ] Scott Bradner [ ] Dave Crocker [ ] Marshall Eubanks [ ] Bob Hinden [ ] Russ Housley [ ] Ole Jacobsen [ ] --
Re: mailing list memberships reminder - passwords in the clear
Only majordomo2, which has been unmaintained for a while now (and it's author calls it Dead holds much of a chance, but I doubt it ?would work for the IETF in its current condition. Actually, MJ2 works great, I've been using it in production for years, but I agree that we'd need to locate a perl weenie willing to make tweaks, and it's probably not enough better than MM to be worth the pain of switching. Sadly this isn't possible with mailman; you will always be mailed your password if you need it and can't remember it. If you use a high value password for your IETF list subscriptions, you have deeper security issues than a few tweaks to mail software can fix. R's, John PS: I saw a description of mailman2 by one of the developers last week. It's really not that different, although he mentioned that the monthly reminders are now off by default.
Selection of a replacement IAOC member
Hello, The IAOC Chair posted a message about the IAOC appointing a replacement liaison to the IETF NomCom after learning from the NomCom chair that Marshall had not responded to emails from the NomCom chair. [1] According to BCP 113: However, if the appointed member is unable to serve the full two-year term, the selecting body may, at its discretion, immediately select a replacement to serve the remainder of the term using the interim process defined in Section 3.5.1. Mr Marshall Eubanks was selected by the 2011-2012 IETF Nominating Committee [2]. Given that Mr Marshall Eubanks has not responded to emails from the NomCom Chair it would appreciated if NomCom could determine: (a) Whether the appointed member is unable to serve the full two-year term (b) Select a replacement to serve the remainder of the term using the interim process Regards, S. Moonesamy 1. http://www.ietf.org/mail-archive/web/ietf-announce/current/msg10812.html 2. https://datatracker.ietf.org/ann/nomcom/3291/
Re: Selection of a replacement IAOC member
it would appreciated if NomCom could determine: (a) Whether the appointed member is unable to serve the full two-year term This is decidedly NOT something that any process empowers the NomCom chair to do. Matt could certainly give his opinion as an individual, but I can't see under what process it would have any official weight. Barry
Re: Selection of a replacement IAOC member
Hi Barry, At 17:15 02-11-2012, Barry Leiba wrote: This is decidedly NOT something that any process empowers the NomCom chair to do. Matt could certainly give his opinion as an individual, but I can't see under what process it would have any official weight. I mentioned NomCom instead of NomCom Chair as that's the selecting body. These individuals have been selected according to the algorithm from RFC 3797 [1]. None of these individuals are members of the IAB, IESG or IAOC. My request does not prevent the Member Recall petition from being pursued. For the sake of disclosure, I do not have any interest in common with the IAOC member except for IETF participation. The request was not discussed with anybody. I am deferring to the nominating committee to see whether BCP 113 is applicable, and if so, take whatever action it deems appropriate. Regards, S. Moonesamy 1. https://datatracker.ietf.org/ann/nomcom/50952/
Re: Selection of a replacement IAOC member
On 11/2/2012 2:47 PM, S Moonesamy wrote: it would appreciated if NomCom could determine: (a) Whether the appointed member is unable to serve the full two-year term Nomcom has no authority to make that determination. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net
