Re: Proposed Statement on HTTPS everywhere for the IETF

2015-06-02 Thread Ted Lemon
On Jun 2, 2015, at 12:59 PM, Joe Touch to...@isi.edu wrote: Leaving out the have-nots - or those whose access is blocked by others when content cannot be scanned - isn't moving forward. That would certainly be a problem if the consensus were not to provide both a secure and an, as you call it,

Re: Proposed Statement on HTTPS everywhere for the IETF

2015-06-02 Thread Ted Lemon
On Jun 2, 2015, at 2:05 PM, Joe Touch to...@isi.edu wrote: On 6/2/2015 11:02 AM, Ted Lemon wrote: On Jun 2, 2015, at 12:59 PM, Joe Touch to...@isi.edu wrote: Leaving out the have-nots - or those whose access is blocked by others when content cannot be scanned - isn't moving forward

Re: IETF 98 - Montreal!

2014-11-13 Thread Ted Lemon
On Nov 13, 2014, at 10:49 AM, IETF Administrative Director i...@ietf.org wrote: The IAOC is pleased to announce Montreal as the site for IETF 98 from 26 - 31 March 2017. The meeting will be held at the Fairmont Queen Elizabeth. Sweet. This means we can all finally go skiing with Jari at

Re: [ietf-privacy] [Int-area] NAT Reveal / Host Identifiers

2014-06-09 Thread Ted Lemon
On Jun 9, 2014, at 12:32 PM, Eliot Lear l...@cisco.com wrote: But does adding a header solve the problem? Not unless it is signed AND I believe the signature. And then I had better be willing to spend the processing time to sort out your good customers from your bad customers. I might do

Re: [ietf-privacy] [Int-area] NAT Reveal / Host Identifiers

2014-06-05 Thread Ted Lemon
On Jun 5, 2014, at 4:28 PM, Brian E Carpenter brian.e.carpen...@gmail.com wrote: I have to call you on that. WG adoption is not approval. It's agreement to work on a topic. It is not OK to attempt a pocket veto on adoption because you don't like the existing content. WG adoption is a pretty

Re: Call for volunteers for C/C++ API liaison manager

2014-05-01 Thread Ted Lemon
On May 1, 2014, at 1:40 PM, Thomas Nadeau tnad...@lucidvision.com wrote: I guess we will have to agree to disagree. I just don't see why that is going to be useful to anyone. If you were talking about open source and/or reference implementations that the source was available for, then

Re: RFC 7168 on The Hyper Text Coffee Pot Control Protocol for Tea Efflux Appliances (HTCPCP-TEA)

2014-04-02 Thread Ted Lemon
On Apr 2, 2014, at 10:44 PM, Clint Chaplin clint.chap...@gmail.com wrote: Yes, I know it should have been no-tea. How many people have any clue what I am referring to? Quite a few of us, I suspect. If only I could figure out where I put that thing my aunt gave me which I don't know what it

Re: Last calling draft-resnick-on-consensus

2013-10-11 Thread Ted Lemon
On Oct 11, 2013, at 8:15 AM, Scott O Bradner s...@sobco.com wrote: The process in the ID is not what was followed when I was an AD and it not what I have described by the meaning of the term rough consensus in my newcomers tutorials (which I have been giving since at least IETF 57 in 2003).

Re: Last Call: draft-ietf-dhc-option-guidelines-14.txt (Guidelines for Creating New DHCPv6 Options) to Best Current Practice

2013-10-10 Thread Ted Lemon
On Oct 9, 2013, at 11:49 PM, Cullen Jennings flu...@iii.ca wrote: If this argument were correct, we'd expect to see major O.S. vendors supporting the NTP option, but we don't—instead, it's something that can be configured in the UI for situations like the one you describe, and that

Re: Montevideo statement

2013-10-10 Thread Ted Lemon
On Oct 9, 2013, at 10:11 PM, Medel v6 Ramirez mgrami...@globe.com.ph wrote: Leaders were processed thoroughly prior to their appointment so I trust them. And that they hold through the spirit of being an IETF and shall be responsible under oath for any impact on the organization. I don't

Re: Last Call: draft-resnick-on-consensus-05.txt (On Consensus and Humming in the IETF) to Informational RFC

2013-10-09 Thread Ted Lemon
On Oct 9, 2013, at 1:30 AM, Melinda Shore melinda.sh...@gmail.com wrote: Rough consensus - An agreement by almost everyone that the proposed That's a lot like voting, I think. It's worse than voting, because it encourages people to invite their friends to sway the consensus. At least with

Re: Montevideo statement

2013-10-09 Thread Ted Lemon
On Oct 9, 2013, at 6:45 AM, Tobias Gondrom tobias.gond...@gondrom.org wrote: But I support SM's proposal that it would be good to do a few days comment period for such important statements in the future - if timing is not critical. There is no harm in a few days delay and getting input from

Re: Last Call: draft-ietf-dhc-option-guidelines-14.txt (Guidelines for Creating New DHCPv6 Options) to Best Current Practice

2013-10-09 Thread Ted Lemon
On Oct 9, 2013, at 11:26 AM, Cullen Jennings (fluffy) flu...@cisco.com wrote: Help educate me on this a bit - I don't see all the things that get requested of DHCP. What are some examples of things where people are request FQDN where IP would be better. I think having some real examples that

Re: Last Call: draft-ietf-dhc-option-guidelines-14.txt (Guidelines for Creating New DHCPv6 Options) to Best Current Practice

2013-10-09 Thread Ted Lemon
On Oct 9, 2013, at 1:32 PM, Cullen Jennings flu...@iii.ca wrote: Well DNS and Router obviously won't work with FQDN so lets talk about NTP for a minute. (and sorry, I don't even know what AFTR IP is). I design lots of devices that have to be plugged into a network and just start working with

Re: Last Call: draft-ietf-dhc-option-guidelines-14.txt (Guidelines for Creating New DHCPv6 Options) to Best Current Practice

2013-10-09 Thread Ted Lemon
On Oct 9, 2013, at 1:59 PM, Joe Abley jab...@hopcount.ca wrote: DNSSEC validation imposes a requirement for clock sync (to the accuracy reasonably required to consider signature inception and expiry times). There is a possible future in which such validation takes place on end hosts, rather

Re: Last Call: draft-ietf-dhc-option-guidelines-14.txt (Guidelines for Creating New DHCPv6 Options) to Best Current Practice

2013-10-09 Thread Ted Lemon
On Oct 9, 2013, at 6:02 PM, Cullen Jennings flu...@iii.ca wrote: Hard coding it means you can't make your device work if you are on a network that behind a firewall that does not allow the traffic or is on a networks that is not part of the internet or is being set up for use in emergency

Re: Last Call: draft-resnick-on-consensus-05.txt (On Consensus and Humming in the IETF) to Informational RFC

2013-10-08 Thread Ted Lemon
On Oct 8, 2013, at 11:39 AM, Ted Hardie ted.i...@gmail.com wrote: To be clear here, I did not think Pete's document was going for BCP. Indeed, but you are speaking of it as if it were, which was my point.

Re: Last Call: draft-ietf-dhc-option-guidelines-14.txt (Guidelines for Creating New DHCPv6 Options) to Best Current Practice

2013-10-08 Thread Ted Lemon
On Oct 8, 2013, at 4:30 PM, Cullen Jennings (fluffy) flu...@cisco.com wrote: Part of why you can't do this with DHCP is that clients are written so that when an IP address fails to work for an application connection, the application re does the DNS and gets the new address (assuming TTL had

Re: Last Call: draft-resnick-on-consensus-05.txt (On Consensus and Humming in the IETF) to Informational RFC

2013-10-07 Thread Ted Lemon
On Oct 7, 2013, at 3:34 PM, Brian E Carpenter brian.e.carpen...@gmail.com wrote: So I'd like to dispute Ted's point that by publishing a version of resnick-on-consensus as an RFC, we will engrave its contents in stone. If that's the case, we have an even deeper problem than misunderstandings

Re: year for highest number of IETF participants

2013-10-07 Thread Ted Lemon
On Oct 7, 2013, at 7:29 PM, Aaron Yi DING aaron.d...@cl.cam.ac.uk wrote: Is there a pointer (maybe from IETF secretary)? The year with highest number of attendees - which one is that? The exact number of participants will be even better. Wasn't it in Berlin? ISTR that we had a remarkably

Re: WG Review: Extensions for Scalable DNS Service Discovery (dnssd)

2013-10-03 Thread Ted Lemon
Discussion of IETF consensus activities is supposed to occur on the IETF mailing list, not on the working group mailing list, which doesn't yet exist. We'll set up the new mailing list when the working group is approved. Sorry for the confusion.

Re: WG Review: Extensions for Scalable DNS Service Discovery (dnssd)

2013-10-03 Thread Ted Lemon
On Oct 3, 2013, at 3:05 PM, manning bill bmann...@isi.edu wrote: but the To Subscribe pointer is busted…. Correct. I should have gotten the information right before sending out the announcement, but I blew it—sorry about that.

Re: WG Review: Extensions for Scalable DNS Service Discovery (dnssd)

2013-10-03 Thread Ted Lemon
Discussion of IETF consensus activities is supposed to occur on the IETF mailing list, not on the working group mailing list, which doesn't yet exist. We'll set up the new mailing list when the working group is approved. Sorry for the confusion.

Re: WG Review: Extensions for Scalable DNS Service Discovery (dnssd)

2013-10-03 Thread Ted Lemon
On Oct 3, 2013, at 3:05 PM, manning bill bmann...@isi.edu wrote: but the To Subscribe pointer is busted…. Correct. I should have gotten the information right before sending out the announcement, but I blew it—sorry about that.

Re: [dhcwg] Last Call: draft-ietf-dhc-option-guidelines-14.txt (Guidelines for Creating New DHCPv6 Options) to Best Current Practice

2013-09-22 Thread Ted Lemon
On Sep 19, 2013, at 7:01 PM, Kevin Darcy k...@chrysler.com wrote: What would be the preferred way to provide a mixed list of IPv4 and IPv6 addresses, in a DHCPv6 option? IPv4-mapped addresses? The preferred way would be not to do that. I think there is a document floating around out there

Re: Transparency in Specifications and PRISM-class attacks

2013-09-20 Thread Ted Lemon
On Sep 20, 2013, at 9:12 AM, Harald Alvestrand har...@alvestrand.no wrote: From the stack I'm currently working on, I find the ICE spec to be convoluted, but the SDP spec is worse, becaue it's spread across so many documents, and there are pieces where people seem to have agreed to ship

Re: Transparency in Specifications and PRISM-class attacks

2013-09-20 Thread Ted Lemon
On Sep 20, 2013, at 10:02 AM, Martin Sustrik sust...@250bpm.com wrote: Isn't it the other way round? That exactly because IETF process is open it's relatively easy for anyone to secretly introduce a backdoor into a protocol? No, this is exactly wrong. What is important about openness is not

Re: ORCID - unique identifiers for contributors

2013-09-18 Thread Ted Lemon
On Sep 18, 2013, at 5:09 AM, Abdussalam Baryun abdussalambar...@gmail.com wrote: on the other hand, people from industry are more organised and don't need/want the academians ideas/participations :-) The IETF is not an industry organization. We want (and get!) participation from a wide

Re: IPR Disclosures for draft-ietf-xrblock-rtcp-xr-qoe

2013-09-16 Thread Ted Lemon
On Sep 16, 2013, at 3:51 PM, Ted Lemon ted.le...@nominum.com wrote: This is a claim in the boilerplate which the IETF, not the authors, are making. I am sure flames are already directed my way for being imprecise here, but what I mean is that although the authors put this boilerplate

Re: IPR Disclosures for draft-ietf-xrblock-rtcp-xr-qoe

2013-09-16 Thread Ted Lemon
On Sep 16, 2013, at 1:37 PM, John C Klensin john-i...@jck.com wrote: (2) Whether the submitted in full conformance... statement in I-Ds is sufficient to cover IPR up to the point of posting of the I-D. If the answer is no, then there is a question of why we are wasting the bits. If it is

Re: [DNSOP] Practical issues deploying DNSSEC into the home.

2013-09-12 Thread Ted Lemon
On Sep 12, 2013, at 7:24 AM, Theodore Ts'o ty...@mit.edu wrote: It is still a hierarchical model of trust. So at the top, if you don't trust Verisign for the .COM domain and PIR for the .ORG domain (and for people who are worried about the NSA, both of these are US corporations), the whole

Re: [DNSOP] Practical issues deploying DNSSEC into the home.

2013-09-12 Thread Ted Lemon
On Sep 12, 2013, at 2:35 PM, Phillip Hallam-Baker hal...@gmail.com wrote: It would work just fine if the attacker did not mind if the surveillance was detected or actually wanted people to know they were being watched to intimidate them. Yup,neither PKI nor DNSSEC address that threat model.

Re: [DNSOP] Practical issues deploying DNSSEC into the home.

2013-09-12 Thread Ted Lemon
On Sep 12, 2013, at 11:07 AM, Theodore Ts'o ty...@mit.edu wrote: Finally, if you think the target can try to find random caching nameservers all across the networ to use, (a) there are certain environments where this is not allowed --- some ISP's or hotel/coffee shop/airline's networks require

Re: [DNSOP] Practical issues deploying DNSSEC into the home.

2013-09-12 Thread Ted Lemon
On Sep 12, 2013, at 3:16 PM, Dickson, Brian bdick...@verisign.com wrote: Excluding the direct methods of acquisition, let us consider the level of effort involved in recreating the root key, by brute force. I think we can assume that they would use some fairly subtle attack to get the key, and

Re: [DNSOP] Practical issues deploying DNSSEC into the home.

2013-09-12 Thread Ted Lemon
On Sep 12, 2013, at 1:21 PM, Theodore Ts'o ty...@mit.edu wrote: Still, I agree with the general precept that perfect should not enemy of the better, and DNSSEC certainly adds value. I just get worried about people who seem to think that DNSSEC is a panacea. Me too. It most certainly is not.

Re: [DNSOP] Practical issues deploying DNSSEC into the home.

2013-09-12 Thread Ted Lemon
On Sep 12, 2013, at 1:49 PM, Dickson, Brian bdick...@verisign.com wrote: In order to subvert or redirect a delegation, the TLD operator (or registrar) would need to change the DNS server name/IP, and replace the DS record(s). Someone who possesses the root key could in principle create a fake

Re: pgp signing in van

2013-09-10 Thread Ted Lemon
On Sep 10, 2013, at 4:41 AM, t.p. daedu...@btconnect.com wrote: for reasons of security, of course; html has far too many attack vectors to allow it to be processed in e-mail If that's true, why is it safe for you to use HTML in a web browser? Is it because you feel that the HTTP trust

Re: not really pgp signing in van

2013-09-10 Thread Ted Lemon
On Sep 10, 2013, at 12:32 PM, Phillip Hallam-Baker hal...@gmail.com wrote: The CA NEVER ever gives the user the key in any of the systems I have worked on. This appears to be untrue. Comodo offers that exact service today. https://secure.comodo.com/products/!SecureEmailCertificate_Signup

Re: not really pgp signing in van

2013-09-10 Thread Ted Lemon
On Sep 10, 2013, at 2:19 PM, Phillip Hallam-Baker hal...@gmail.com wrote: You go to a Web page that has the HTML or Javascript control for generating a keypair. But the keypair is generated on the end user's computer. So I run Javascript provided by Comodo to generate the key pair. This

Re: not really pgp signing in van

2013-09-10 Thread Ted Lemon
On Sep 10, 2013, at 5:47 PM, John R Levine jo...@taugh.com wrote: How likely is it that they would risk their reputation and hence their entire business by screwing around with free promo S/MIME certs? I don't know. What happens if they are served with an NSL? I certainly don't think

Re: not really pgp signing in van

2013-09-10 Thread Ted Lemon
On Sep 10, 2013, at 6:50 PM, Phillip Hallam-Baker hal...@gmail.com wrote: Could be but I have been working through what we know versus what would be required and I really can't see how a group of people who would let Snowden loose on their innermost secrets would be able to keep a conspiracy

Re: pgp signing in van

2013-09-09 Thread Ted Lemon
On Sep 9, 2013, at 8:43 AM, Michael Richardson mcr+i...@sandelman.ca wrote: What's the upside to signing my email? I know why I want everybody I know to sign my email, but what's the upside for me if I do it? Until there's a clear win, it's not going to happen. It's what establishes the

Re: pgp signing in van

2013-09-09 Thread Ted Lemon
On Sep 9, 2013, at 4:11 PM, Dan York dan-i...@danyork.org wrote: Even in the groups where PGP was (and is) being used, usage is inconsistent in part because people are now accessing their email using different devices and not all of them have easy access to PGP/GPG. If you receive an

Re: What real users think [was: Re: pgp signing in van]

2013-09-09 Thread Ted Lemon
On Sep 9, 2013, at 4:27 PM, Steve Crocker st...@shinkuro.com wrote: Actually, I interpret the chemistry professor's comment in a different light. It would be possible to design a system where: o the standard end user software doesn't facilitate editing the other person's text, and o

Re: What real users think [was: Re: pgp signing in van]

2013-09-09 Thread Ted Lemon
On Sep 9, 2013, at 4:48 PM, Brian E Carpenter brian.e.carpen...@gmail.com wrote: Indeed. How one achieves such a fresh start is unclear. G+, Facebook, etc. There's no shortage of fresh starts in the personal communication space. They just don't typically look like typical SMTP/rfc822

Re: [v6ops] Last Call: draft-ietf-v6ops-mobile-device-profile-04.txt (Internet Protocol Version 6 (IPv6) Profile for 3GPP Mobile Devices) to Informational RFC

2013-09-09 Thread Ted Lemon
Owen, do you have any technical objection to raise about this document, or are you just replying because you like the sound the keys make as you type? The working group adopted the document, so it's too late to object that the working group shouldn't be working on it. You can object by

Re: pgp signing in van

2013-09-09 Thread Ted Lemon
On Sep 9, 2013, at 5:19 PM, David Morris d...@xpasc.com wrote: On Mon, 9 Sep 2013, Ted Lemon wrote: It might be worth thinking about why ssh and ssl work so well, and PGP/GPG don't. Umm, I question a conclusion that either ssh or ssl work well. It's in widespread use. Hence, it works

Re: What real users think [was: Re: pgp signing in van]

2013-09-09 Thread Ted Lemon
On Sep 9, 2013, at 5:25 PM, Dave Crocker d...@dcrocker.net wrote: 1. Starting fresh means ceasing to interoperate (well) with Internet Mail. We had quite a lot of exemplars of this when the Internet was starting to be commercial; semantics matching was often awkward. To be clear, what I

Re: not really pgp signing in van

2013-09-09 Thread Ted Lemon
On Sep 9, 2013, at 5:36 PM, John Levine jo...@taugh.com wrote: Sounds like we're on our way to reinventing S/MIME. Other than the key signing and distribution (which I agree is a major can of worms) it works remarkably well. Right. That's the reason I don't use it. Completely naively, may

Re: What real users think [was: Re: pgp signing in van]

2013-09-09 Thread Ted Lemon
On Sep 9, 2013, at 5:21 PM, SM s...@resistor.net wrote: Yes. Somebody would write a MUA to do it if it wasn't possible. What they do not, however, do, is to fix up the signature so that it still validates after the editing has been done.

Re: pgp signing in van

2013-09-09 Thread Ted Lemon
On Sep 9, 2013, at 5:51 PM, Arturo Servin arturo.ser...@gmail.com wrote: Because normally with SSL and SSH the complexity is in the server, not the client. When the client needs to verify the identity of some site with SSL we have the background browser process to check it (that in fact it

Re: not really pgp signing in van

2013-09-09 Thread Ted Lemon
On Sep 9, 2013, at 9:07 PM, John Levine jo...@taugh.com wrote: Yes, and no. PGP and S/MIME each have their own key distribution problems. With PGP, it's easy to invent a key, and hard to get other people's software to trust it. With S/MIME it's harder to get a key, but once you have one,

Re: [v6ops] Last Call: draft-ietf-v6ops-mobile-device-profile-04.txt (Internet Protocol Version 6 (IPv6) Profile for 3GPP Mobile Devices) to Informational RFC

2013-09-09 Thread Ted Lemon
It has been pointed out to me that I went overboard in my response to you. I will state what was obvious to me as I wrote my response, but may not have been obvious to other readers: I am not the responsible AD for v6ops. My response was that of a participant in v6ops. I didn't find what

Re: not really pgp signing in van

2013-09-09 Thread Ted Lemon
On Sep 9, 2013, at 9:26 PM, John R Levine jo...@taugh.com wrote: Um, didn't this start out as a discussion about how we should try to get people using crypto, rather than demanding perfection that will never happen? Yes. Typical S/MIME keys are issued by CAs that verify them by sending you

Re: pgp signing in van

2013-09-09 Thread Ted Lemon
On Sep 9, 2013, at 11:36 PM, Paul Wouters p...@nohats.ca wrote: Related (does not take away the full pain): Nice. I think section 4.2 is slightly too pessimistic, but not harmfully so. It might be worth talking about leap-of-faith validation as well as web-of-trust validation.

Re: pgp signing in van

2013-09-08 Thread Ted Lemon
On Sep 8, 2013, at 5:33 PM, Michael Richardson mcr+i...@sandelman.ca wrote: To all the people who posted to this thread about how they don't know what a PGP key signature means, and who did not PGP or S/MIME their email: What's the upside to signing my email? I know why I want everybody I

Re: Bruce Schneier's Proposal to dedicate November meeting to saving the Internet from the NSA

2013-09-07 Thread Ted Lemon
On Sep 7, 2013, at 9:39 AM, Phillip Hallam-Baker hal...@gmail.com wrote: Nor does being open source provide any additional security, only review provides security and it is hard enough getting people to review other people's code when you pay them to do that. Expecting people to spend their

Re: Bruce Schneier's Proposal to dedicate November meeting to saving the Internet from the NSA

2013-09-06 Thread Ted Lemon
On Sep 6, 2013, at 2:46 AM, SM s...@resistor.net wrote: At 20:08 05-09-2013, Ted Lemon wrote: I think we all knew NSA was collecting the data. Why didn't we do something about it sooner? Wasn't it an emergency when the PATRIOT act was passed? We certainly thought it was an emergency

Re: Bruce Schneier's Proposal to dedicate November meeting to saving the Internet from the NSA

2013-09-06 Thread Ted Lemon
On Sep 6, 2013, at 3:25 AM, Måns Nilsson mansa...@besserwisser.org wrote: I do think that more distributed technoligies like DANE play an important rôle here. Right, because there's no way the NSA could ever pwn the DNS root key. What we should probably be thinking about here is: -

Re: Bruce Schneier's Proposal to dedicate November meeting to saving the Internet from the NSA

2013-09-06 Thread Ted Lemon
On Sep 6, 2013, at 2:31 PM, Dean Willis dean.wil...@softarmor.com wrote: What if they didn't say they were NSA guys, but just discretely worked a weakness into a protocol? What if they were a trusted senior member of the community? If we have trusted senior members making false statements

Re: pgp signing in van

2013-09-06 Thread Ted Lemon
On Sep 6, 2013, at 2:51 PM, Phillip Hallam-Baker hal...@gmail.com wrote: The issue is that smime email clients are more common so I would rather teach the smime doggie pgp like tricks than vice versa The problem is getting your smime program to stop using CA keys and only use your local key as

Re: Bruce Schneier's Proposal to dedicate November meeting to saving the Internet from the NSA

2013-09-06 Thread Ted Lemon
On Sep 6, 2013, at 6:02 PM, Tim Bray tb...@textuality.com wrote: How about a BCP saying conforming implementations of a wide-variety of security-area RFCs MUST be open-source? So clearly we should do all our crypto on devices built out of 7400-series logic. Hm, where has my old wire-wrap

Re: pgp signing in van

2013-09-06 Thread Ted Lemon
On Sep 6, 2013, at 6:42 PM, Joe Touch to...@isi.edu wrote: I've noted elsewhere that the current typical key-signing party methods are very weak. You should sign only the keys of those who you know well enough to claim you can attest to their identity. This is a ridiculously high bar. The

Re: pgp signing in van

2013-09-06 Thread Ted Lemon
On Sep 6, 2013, at 8:21 PM, Melinda Shore melinda.sh...@gmail.com wrote: when you vouch for someone's identity - in an authoritative trust system - you're also vouching for the authenticity of their transactions. This is what I mean by a high bar. Signing someone's PGP key should mean I

Re: pgp signing in van

2013-09-06 Thread Ted Lemon
On Sep 6, 2013, at 9:24 PM, Melinda Shore melinda.sh...@gmail.com wrote: I'm not sure why I know this person as X provides much more reliability than someone asserting their own identity. Actually it's quite useful. It allows me to differentiate email coming from someone I know as X from

Re: pgp signing in van

2013-09-06 Thread Ted Lemon
On Sep 6, 2013, at 10:18 PM, Scott Brim scott.b...@gmail.com wrote: Dilution of trust is a problem with PGP. I know this person as X is way too lax if you want the system to scale. It's naive to think that keys are any more trustworthy than this, because any signature's trustworthiness is

Re: pgp signing in van

2013-09-06 Thread Ted Lemon
On Sep 6, 2013, at 10:35 PM, Melinda Shore melinda.sh...@gmail.com wrote: I actually don't think that pgp is likely to be particularly useful as a serious trust mechanism, mostly because of issues like this. It's not at all clear to me that serious trust mechanisms should be digital at all.

Re: pgp signing in van

2013-09-06 Thread Ted Lemon
On Sep 6, 2013, at 11:12 PM, Melinda Shore melinda.sh...@gmail.com wrote: I'm not quite sure how we got from the question of how to do crypto better as a means to provide stronger privacy protections to the value of Facebook, to be honest. Possibly because of the key signing proposal. It's

Re: Bruce Schneier's Proposal to dedicate November meeting to saving the Internet from the NSA

2013-09-05 Thread Ted Lemon
On Sep 5, 2013, at 8:46 PM, Lucy Lynch lly...@civil-tongue.net wrote: I'd like to share the challenge raised by Bruce Schneier in: I thought it was a great call to action. Is Bruce coming to Vancouver?

Re: Bruce Schneier's Proposal to dedicate November meeting to saving the Internet from the NSA

2013-09-05 Thread Ted Lemon
On Sep 5, 2013, at 9:36 PM, Brian E Carpenter brian.e.carpen...@gmail.com wrote: I'm sorry, I don't detect the emergency. I think we all knew NSA was collecting the data. Why didn't we do something about it sooner? Wasn't it an emergency when the PATRIOT act was passed? We certainly

Re: PS Characterization Clarified

2013-09-03 Thread Ted Lemon
On Sep 3, 2013, at 4:40 PM, Barry Leiba barryle...@computer.org wrote: The only concern I have is that once we do this -- declare that PS is always more mature than that -- we can't go back. Do we *really* want to say that we will never again approve a PS spec that's partially baked? It

Re: Is the datatracker authoritative (was: WG Review: Dynamic Host Configuration (dhc))

2013-08-31 Thread Ted Lemon
On Aug 31, 2013, at 12:10 AM, S Moonesamy sm+i...@elandsys.com wrote: announcement really ought to just point to the datatracker, since what's there is normative. This is an individual opinion. Please assume that the entire IETF disagrees with it. The datatracker is not the authoritative

Re: WG Review: Dynamic Host Configuration (dhc)

2013-08-30 Thread Ted Lemon
On Aug 30, 2013, at 9:17 PM, S Moonesamy sm+i...@elandsys.com wrote: Did the DHC working group read the milestones? I ask because it's been a few years since the year 2008 ended. Yes. The minutes have been updated in the datatracker: https://datatracker.ietf.org/wg/dhc/charter/ I don't

Re: External link to article on trends in anti-surveillance design

2013-08-29 Thread Ted Lemon
On Aug 29, 2013, at 1:22 PM, Peter Saint-Andre stpe...@stpeter.im wrote: Interesting stuff, but more on-topic for the perpass list: I think Deans point is precisely that it is _not_ a topic that can be restricted to the perpass list.

Re: Rude responses (sergeant-at-arms?)

2013-08-27 Thread Ted Lemon
FWIW, if we are going to go down that road, it would be worth noting that there are various kinds of rudeness that can occur on IETF mailing lists. To my mind, the most harmful of these is not outright rudeness. Outright rudeness is to be avoided, certainly. But the most rude behavior that

Re: Rude responses (sergeant-at-arms?)

2013-08-27 Thread Ted Lemon
On Aug 27, 2013, at 1:20 PM, Scott Brim scott.b...@gmail.com wrote: IMHO that's not a job for the sergeant at arms. The SAA is responsible for how things are said. The shepherd -- or supershepherd or whatever -- would be responsible for the substance. I think it should be fairly obvious

Re: Rude responses (sergeant-at-arms?)

2013-08-27 Thread Ted Lemon
On Aug 27, 2013, at 3:08 PM, John Leslie j...@jlc.net wrote: I feel sorry for Ted, who _does_ have to evaluate consensus here. Actually no, I don't—spfbis is apps area, not int area. Lucky me... :)

Re: [spfbis] Last Call: draft-ietf-spfbis-4408bis-19.txt (Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1) to Proposed Standard

2013-08-21 Thread Ted Lemon
On Aug 21, 2013, at 7:17 AM, Patrik Fältström p...@frobbit.se wrote: My conclusion is that a statement that nobody queries for it is false. I am curious if the folks who did the analysis of query rates know the answers to the following questions: 1. Per unit of mail delivered (as opposed to

Re: [spfbis] there is no transitiion, was Last Call: draft-ietf-spfbis-4408bis-19.txt

2013-08-21 Thread Ted Lemon
On Aug 21, 2013, at 10:44 AM, John Levine jo...@taugh.com wrote: This would require some reason why it is worth them spending time and money to do something that has no operational benefit whatsoever. Sorry, I wasn't trying to make an argument for you to refute. I'm saying that if the people

Re: [spfbis] SPF TYPE support

2013-08-19 Thread Ted Lemon
On Aug 19, 2013, at 5:10 PM, Hector Santos hsan...@isdg.net wrote: This will allow coders to add the optimized logic for usage. It will also allow for new problem solving seeds to be laid down. It will hopefully get the DNS software vendors to finally add direct support for unnamed TYPE

Re: Community Input Sought on SOWs for RFC Production Center and RFC Publisher

2013-08-13 Thread Ted Lemon
On Aug 13, 2013, at 3:49 AM, Melinda Shore melinda.sh...@gmail.com wrote: I agree in principle (MS document formats are not a suitable document exchange format for an open standards body) but in truth, it's been awhile since Open Office hasn't been able to read .doc files correctly. I wonder,

Re: Community Input Sought on SOWs for RFC Production Center and RFC Publisher

2013-08-13 Thread Ted Lemon
On Aug 13, 2013, at 9:51 AM, John Levine jo...@taugh.com wrote: There's no great way to send around a redlined document and I'd say that Word formats are currently the least bad. rfcdiff does really nicely, actually.

Re: Last Call: draft-bormann-cbor-04.txt (Concise Binary Object Representation (CBOR)) to Proposed Standard

2013-08-10 Thread Ted Lemon
On Aug 10, 2013, at 8:32 AM, Hadriel Kaplan hadriel.kap...@oracle.com wrote: I'm not saying that will happen in this case at all, but we shouldn't kid ourselves that it doesn't matter. If it didn't matter, people wouldn't care about labeling their IDs Informational or Experimental. People

Re: Faraday cages...

2013-08-10 Thread Ted Lemon
On Aug 10, 2013, at 10:52 AM, Scott Kitterman sc...@kitterman.com wrote: Unless you're checking identification provided by sources all agree are trustworthy, you've done nothing of the sort. You may be able to attach an unverified identifier to a group of statements, but there's still no

Re: Last Call: draft-bormann-cbor-04.txt (Concise Binary Object Representation (CBOR)) to Proposed Standard

2013-08-10 Thread Ted Lemon
On Aug 10, 2013, at 11:00 AM, Dave Crocker d...@dcrocker.net wrote: Most of this thread has ignored the IETF's own rules and criteria. As such, it's wasteful, at best, though I think it's actually destructive, since it provides fuel to the view that the IETF is a questionable venue for

Re: Last Call: draft-bormann-cbor-04.txt (Concise Binary Object Representation (CBOR)) to Proposed Standard

2013-08-10 Thread Ted Lemon
On Aug 10, 2013, at 11:30 AM, Hadriel Kaplan hadriel.kap...@oracle.com wrote: I'm not sure if you intended to, but you're implying non-standards-track docs are only for things we don't expect interoperability for, or cannot have or affect interoperability. I've read RFC 2026, and afaict

Re: Last Call: draft-bormann-cbor-04.txt (Concise Binary Object Representation (CBOR)) to Proposed Standard

2013-08-10 Thread Ted Lemon
On Aug 10, 2013, at 12:25 PM, Ted Lemon ted.le...@nominum.com wrote: Section 1.1 goes on at some length about the intended use for the document is. If you believe it is unclear or incomplete, some pointed questions about it would be entirely appropriate. To expand on this slightly

Re: Faraday cages...

2013-08-09 Thread Ted Lemon
On Aug 8, 2013, at 9:05 PM, Keith Moore mo...@network-heretics.com wrote: Would being able to reliably know exactly who said everything that was said in a WG meeting visibly improve the quality of our standards? If the answer is not a clear yes (and I don't think it is) then I suggest that

Re: Last Call: draft-bormann-cbor-04.txt (Concise Binary Object Representation (CBOR)) to Proposed Standard

2013-08-09 Thread Ted Lemon
On Aug 9, 2013, at 4:56 PM, Phillip Hallam-Baker hal...@gmail.com wrote: Actually I just want it in writing because my past experience of a similar platform type spec was that it was just another option for developers right up to the point where it was published when I found myself in a BOF

Re: Faraday cages...

2013-08-08 Thread Ted Lemon
On Aug 8, 2013, at 1:47 PM, Phillip Hallam-Baker hal...@gmail.com wrote: Why bother with RFID tags, or badges? Simply register with your cell phone. We can then scan your Wi-Fi and Blue-Tooth signals when you approach the mic. -- Christian Huitema 'Simply' What is this simple

Re: [iaoc-rps] RPS Accessibility

2013-08-07 Thread Ted Lemon
On Aug 6, 2013, at 5:36 PM, Martin Rex m...@sap.com wrote: Maybe attaching such a sign to the MIC from the start could additionally improve the situation. There were signs like this attached to all the mics in all the rooms at this IETF. I never looked at them, and I doubt anybody else did

Re: RPS Accessibility

2013-08-07 Thread Ted Lemon
On Aug 6, 2013, at 5:15 PM, Doug Barton do...@dougbarton.us wrote: What I've seen in other groups that has worked is a volunteer to record the names of speakers *before* they get to the mic, and then each speaker is announced. Of course that's one more volunteer to find, but it's pretty light

Re: Berlin was awesome, let's come again

2013-08-07 Thread Ted Lemon
On Aug 6, 2013, at 7:59 PM, Douglas Otis doug.mtv...@gmail.com wrote: Agreed. One minor downside was needing an additional flight. It seems AB who handles about a third of the traffic rather than Lufthansa that handles about one fifth, was not the best choice where a 6 hour layover extended

Faraday cages...

2013-08-07 Thread Ted Lemon
Dare I ask how many IETFers also kept their cell phones in faraday cages for the duration of the conference?

Re: Faraday cages...

2013-08-07 Thread Ted Lemon
On Aug 7, 2013, at 1:24 PM, Scott Brim scott.b...@gmail.com wrote: I keep my passport in a cage when I'm not handing it to someone. I'm not concerned about my phone. Likewise. The point being, handing everyone in IETF an RFID tag probably doesn't have new privacy implications for most of

Re: Faraday cages...

2013-08-07 Thread Ted Lemon
On Aug 7, 2013, at 4:30 PM, Ole Jacobsen o...@cisco.com wrote: Unless we adopt the WIDE practice where the tag is re-used from meeting to meeting. It's an elegant solution, and not that different from the reason I own a complete set of Suica, Pasmo, ICOCA, PASPY and London Oyster cards. That

Re: [iaoc-rps] RPS Accessibility

2013-08-06 Thread Ted Lemon
On Aug 6, 2013, at 11:27 AM, Dave Crocker d...@dcrocker.net wrote: It was an experiment. It was awkward and inaccurate. It also raised basic privacy concerns, what with wearing something that can be tracked as you move around. Ironically, this IETF everyone who stayed at the

Re: [iaoc-rps] RPS Accessibility

2013-08-06 Thread Ted Lemon
On Aug 6, 2013, at 11:27 AM, Dave Crocker d...@dcrocker.net wrote: An entirely different approach would be to have all speakers make a 'reservation' into a single meetecho (or whatever) online queue, and then get called in order, whether local or remote and independent of what microphone

Re: [iaoc-rps] RPS Accessibility

2013-08-06 Thread Ted Lemon
On Aug 6, 2013, at 1:31 PM, Michael Richardson mcr+i...@sandelman.ca wrote: We can easily have three or four microphones that can play leap-frog around the room. +1 Of course, then we need a facilitator to wrest it away from filibusterers or simply a mechanism for the chairs to mute a mic.

Re: [iaoc-rps] RPS Accessibility

2013-08-06 Thread Ted Lemon
On Aug 6, 2013, at 4:05 PM, Paul Aitken pait...@cisco.com wrote: Could there be a conflict if IETF badges also have RFID tags attached, eg we get Room 1283 at the mic? No. Only known IDs would register. The RFID badge just has a number—it doesn't say Room 1283.

  1   2   3   >