Tuesday, May 12, 2015< ^ >
Jared Mauch has set the subject to:
Room Configuration
Room Occupants

[08:50:00] marka leaves the room
[08:53:01] marka joins the room
[10:42:31] marka leaves the room
[10:42:44] marka joins the room
[11:44:01] marka leaves the room
[11:46:07] marka joins the room
[14:34:31] alecmuffett joins the room
[14:34:42] <alecmuffett> tes
[14:34:46] <alecmuffett> test, even
[14:43:37] marka leaves the room
[15:10:42] marka joins the room
[15:11:05] marka leaves the room
[15:12:44] marka joins the room
[15:21:15] marka leaves the room
[15:28:40] ray joins the room
[15:44:21] bortzmeyer joins the room
[15:44:27] Suzanne joins the room
[15:44:45] <bortzmeyer> Time remaining until you can join: 00:18
[15:44:56] <Suzanne> Hi Stephane!
[15:45:44] <bortzmeyer> " Java must be installed on your computer and enabled in your browser " Something is wrong
[15:46:26] <ray> Are the chairs planning on using video sharing?
[15:50:35] <Suzanne> We did plan on using webex for the slides, but the deck isn't extensive and is posted on the IETF website….I emailed the link about an hour ago
[15:51:03] <Suzanne>
[15:52:04] <Suzanne> We can certainly carry back any objections or bug reports re: webex to the IETF secretariat, but for today, it's what we have
[15:52:09] <ray> massive mains hum on the call now
[15:52:46] <bortzmeyer> Yes, I'm an expert, I can start WebEx and log in!
[15:52:52] <Suzanne> Tim's starting the webex now
[15:53:23] <ray> Stephane - please mute your mic
[15:53:59] <bortzmeyer> Ray: done
[15:54:14] <ray> thanks - the 50 Hz hum appears to have been coming from you :(
[15:55:09] <bortzmeyer> ray: which mean I won't be able to talk?
[15:55:21] <ray> perhaps :(
[15:55:30] <bortzmeyer> I can try the phone
[15:55:40] <ray> I thought that was the only option we had
[15:56:32] jreed joins the room
[15:56:47] <bortzmeyer> Phone does not work (busy signal)
[15:57:19] Dan York joins the room
[15:57:47] <ray> thanks Warren :)
[15:57:50] alecmuffett leaves the room
[15:58:01] alecmuffett joins the room
[15:58:09] Paul Hoffman joins the room
[15:58:16] <jreed> in firefox, pdf background doesn't display, so get white text on no (white) background. Opened in different viewer and was fine.
[15:58:22] hellekin joins the room
[15:59:12] <bortzmeyer> OK, phone works
[15:59:53] <hellekin> hello!  Good afternoon from buenos aires
[16:00:58] joins the room
[16:01:22] <bortzmeyer> hellekin: hello
[16:01:38] <bortzmeyer> hellekin: managed to get a working java for webex ?
[16:02:07] marco@nl joins the room
[16:02:09] Lyman Chapin joins the room
[16:02:17] <hellekin> bortzmeyer, an exe file... Is that Java?  Maybe I can try again.
[16:02:27] fujiwara joins the room
[16:02:39] <jreed> Hello fujiwara
[16:02:41] <bortzmeyer> hellekin: apparently, it's Java. An .exe would not have work on my Ubuntu
[16:02:52] <ray> unless you have Wine...
[16:04:23] <> I'm talking to Cindy now
[16:04:38] <Paul Hoffman> Thank you, Andrew.
[16:06:02] <Suzanne> We're still below the obligatory 5 min of goofing around :) Thanks all
[16:06:44] paulwouters joins the room
[16:07:50] <ray> Stephane - I don’t actually hear anything, but the system still thinks you’re speaking continuously
[16:08:12] <alecmuffett> testing jabber
[16:08:15] <bortzmeyer> ray: i'm now in from the phone and there is no option to mute
[16:08:16] <Dan York> it works!
[16:08:19] Francisco Arias joins the room
[16:08:38] tjw ietf joins the room
[16:08:43] <ray> Stephane - if you’re logged into the webex itself you can mute from the UI
[16:08:59] <bortzmeyer> ray: no, Mute is dimmed
[16:09:08] <ray> odd.  oh well
[16:09:48] rbarnes joins the room
[16:09:51] <bortzmeyer> ray: got it, i had to select me first
[16:10:00] <bortzmeyer> ray: is it better?
[16:10:09] <ray> stephane: yes, thanks!
[16:10:26] <> I just turned on recording
[16:10:37] <> Sorry, overlooked that
[16:11:21] Peter Koch joins the room
[16:11:32] jelte.jansen joins the room
[16:12:10] <ray> ajs - can you mute call in user 9?
[16:14:09] john.levine joins the room
[16:15:39] <hellekin> well, I'm afraid I cannot participate in IETF works without Java and a Windows computer.  I'll stay here if you have any question.  Thanks to the people who emailed me for help.
[16:15:52] Ralf Weber joins the room
[16:16:01] <john.levine> You can call in if you have a telephone.
[16:16:23] <john.levine> and view the slides with any PDF viewer
[16:16:44] <hellekin> I don't and calling from Argentina is kind of unpractical.  I don't have a corporation to cover intl roaming costs.
[16:17:18] <hellekin> john.levine, actually I had to download the slides because firefox's internal PDF.js could not read the background, and that made the text unreadable.
[16:17:31] <bortzmeyer> The slides shared are much larger than my screen and I find no way to zoom them out.
[16:17:43] <paulwouters> is there a link to the pdf?
[16:17:45] <Paul Hoffman> hellekin: you can continue to participate on the mailing list. There are *plenty* of people who are active but not in the meeting today.
[16:18:06] <bortzmeyer> paulwouters:
[16:18:11] <hellekin> Paul Hoffman, yes, I guess that's what I need to do :)
[16:18:11] <paulwouters> thanks
[16:18:29] <bortzmeyer> hellekin: and Windows is not necessary, I am on Ubuntu
[16:18:33] <paulwouters> (oh yeah. it fails in firefox pretty badly)
[16:18:49] <hellekin> bortzmeyer, try zathura: zooming out with minus works
[16:18:50] <bortzmeyer> hellekin: with a phone provider that let me call the USA all day long for a flat price (Free, in France)
[16:18:54] <ray> hellekin: it also works fine on Mac OS X
[16:19:17] <hellekin> bortzmeyer, ah yes, is awesome
[16:19:33] <hellekin> bortzmeyer, I can't recommend phone service in Argentina :D
[16:19:37] <jreed> webex (32-bit) doesn't work for me on ubuntu 64-bit, unless something improved in past few months.
[16:20:28] <hellekin> is this room persistent?
[16:20:36] <ray> it should be
[16:20:41] <ray> there’s usually a log, too
[16:20:44] <Paul Hoffman> This room is persistent.
[16:20:52] <hellekin> cool thanks.  Bookmarked.
[16:21:19] <paulwouters> [richard barnes speaking]
[16:22:11] <rbarnes > [peter koch speaking]
[16:22:20] <Paul Hoffman> We can't hear Peter very well
[16:22:24] <rbarnes > peter is a bit hard to hear
[16:22:32] <alecmuffett> Could everyone not speaking please mute,especially all dialled-in users?
[16:22:36] <Paul Hoffman> Warren: please repeat what Peter said.
[16:22:53] <alecmuffett> someone is typing
[16:22:56] <alecmuffett> they are not on mute
[16:24:46] <rbarnes > peter: the registry policy is "Standards Action" or "IESG Approval"
[16:25:11] Ralf Weber leaves the room
[16:25:19] <bortzmeyer> sudden silence...
[16:25:21] Ralf Weber joins the room
[16:32:54] <marco@nl> Is it me, or is .bit not mentioned in any of the drafts? (namecoin)
[16:33:11] <> I think it's in p2pnames, no?
[16:33:16] <bortzmeyer> marco: it is in the Grothoff draft
[16:33:17] <rbarnes > marco@nl: it's in at least one draft, just not on the agenda today
[16:33:19] <marco@nl> let me see
[16:33:21] <marco@nl> thanks
[16:33:48] <marco@nl> it is
[16:39:14] <rbarnes > 36^255 should be enough for anyone
[16:40:52] <ray> 36^63 Richard ;-)
[16:41:08] <bortzmeyer> rbarnes :  let's register .qddchjoiufxxs
[16:41:15] <> "Prophesying is hard, especially about the future."  But anyway, the alt draft is quite clear that it doesn't intend to solve present cases, so let's not conflate this stuff, please
[16:41:32] <hellekin> +1
[16:41:49] <rbarnes > bortzmeyer: show me your 10^n existing stacks using .qddchjoiufxxs, and sure :)
[16:42:24] <ray> .alt should be good for future special cases.   It’s too late for .onion, .home, .corp and .mail
[16:42:33] <alecmuffett> .alt is a lovely idea, but it is going to be a nightmare for mixed experimenters with mixed protocols under a single .ALT TLD to obtain valid SSL certificates\
[16:43:01] jelte.jansen joins the room
[16:43:04] <alecmuffett> Getting .onion accepted as a SSL namespace was hard enough, and Tor is at least a well-defined protocol
[16:44:29] <hellekin> anyway .alt draft specifically does not cover *global* names, and .onion names are globally unique.
[16:44:31] <bortzmeyer> rbarnes : with such a criteria, only Apple and Microsoft would have the rigth to use RFC 6761
[16:44:37] <paulwouters> why start anything new that relies on CAB/Forum :P
[16:44:46] <alecmuffett> :-)
[16:44:47] <Paul Hoffman> The current speaker is listed as "Hugo", but I think he said his name was something different
[16:45:46] Ralf Weber leaves the room: Replaced by new connection
[16:45:50] <Suzanne> thanks Paul
[16:46:09] Ralf Weber joins the room
[16:46:19] <Suzanne> (trying to watch both jabber and webex, I will have some notes on logistics for the secretariat re: interims….
[16:47:08] <> I've seen other interims not use the webex chat.  
[16:47:15] <Paul Hoffman> Interesting point from Peter on RFC 6303
[16:47:39] <Dan York> indeed
[16:47:58] <> Much of Peter's argument here is in effect that 6761 isn't a legitimate document, which I think is problematic for this discussion.
[16:48:00] <Paul Hoffman> Another interesting point from Peter: later change control.
[16:48:13] <rbarnes > +1
[16:48:44] <rbarnes > Paul Hoffman: not interesting.  the only change control is for the DNS handling, which i think the Tor folks will happily work with us on
[16:48:46] <Paul Hoffman> Andrew: agree, but he could have more easily said "6761 is hard to interpret". Like some of our other standards-track documents.
[16:49:10] <Paul Hoffman> Richard: that bit is interesting.
[16:49:40] <rbarnes > Paul Hoffman: maybe, but it's a small bit of text.  it's not like they would be handing over .onion resolution.
[16:50:15] hellekin is missing context
[16:50:38] <tjw ietf> I've got hands up (in order I saw them): Mr. Levine; Mr. Liman, Mr. Soininen
[16:50:42] <rbarnes > hellekin: we are supposed to be discussing whether to adopt the .onion draft (i.e., to do work on that problem)
[16:51:17] <hellekin> rbarnes , I hope you do.  I can't see any reason why not, really.
[16:51:50] <hellekin> isn't it within the charter of DNSOP?
[16:52:10] <paulwouters> its not really dns. so that is a very hard question :P
[16:53:31] Paul Hoffman leaves the room
[16:53:38] <hellekin> but the DNSOP charter also mentions special-use domain names paulwouters
[16:54:45] <hellekin> I think the DNSOP charter was explitcitly rewritten to cover RFC6761 if I remember well.
[16:55:10] <ray> amongst other changes, yes
[16:55:55] <> Since I'm moderator I can't put my hand up, so hand up
[16:56:28] <rbarnes > did the audio just drop for everyone, or just me?
[16:56:30] jelte.jansen leaves the room
[16:56:34] <> didn't drop for me
[16:56:34] <rbarnes > nm, back
[16:56:56] <rbarnes > this beatiful network i'm on likes to stop forwarding packets every so often
[16:57:12] Paul Hoffman joins the room
[16:57:42] <ray> policy process, and much broken technical analysis...
[16:59:42] <hellekin> (what is the physical room name?)
[17:00:03] <ray> On the webex it’s called “RIPE room”
[17:00:44] <ray> At the RIPE venue, it’s called “Meerman”
[17:01:14] <Dan York> "1918 names"
[17:01:25] <paulwouters> (someone typing is not on mute)
[17:03:34] <rbarnes > could you briefly restate your two categories here?  (1) new functionality, and (2) … ?
[17:05:03] <> (1) new functionality and (2) ordinary DNS names that happen not to be in the public DNS
[17:05:16] <> Basically, (2) is like RFC 1918 addresses, AFAICT
[17:05:27] <rbarnes > i see.  thanks.
[17:05:30] <ray> what about (3) names where harm would occur if they were delegated?
[17:05:37] <rbarnes > that matches my understanding of RFC 6761
[17:06:07] <> Yeah, but there are different reasons for that harm
[17:06:08] <rbarnes > ray: c'est magnifique, but ce n'est pas RFC 6761
[17:06:46] <ray> richard: so we put them in 6303-bis?
[17:06:48] <> one is because it breaks the "different protocol" switch (that is, you actually need the NXDOMAIN from the DNS for that to work reliably)
[17:06:55] <paulwouters> but adding it to the special names registry will not prevent any leaks
[17:07:04] <> one is because it steps on other uses which are, at bottom, legitimized by their widespread use
[17:07:17] <paulwouters> if you want that, you need another RFC for a BCP to not forward .onion queries
[17:07:25] Hugo Salgado joins the room
[17:07:26] <> I agree with paulwouters that the special names registry won't promise no leaks
[17:07:27] <Peter Koch> how is 'onion' leakage better or worse than 'home', 'net' and 'corp' (except for a missing application) and should 'collision/leakage' based decisions not be made consistently by one body?
[17:07:29] <paulwouters> (which might need a special names entry as precursor)
[17:07:29] <Paul Hoffman> Still wanting to know who "Hugo" is?
[17:07:38] <hellekin> it won't prevent leaks, but it will enable implementors to deal with it consistently
[17:07:58] <paulwouters> Hugo Maxwell Connery  ?
[17:08:20] <paulwouters> hellekin: another RFC would deal with that. not the registration itself
[17:08:21] <Paul Hoffman> Or Hugo Salgado?
[17:09:32] <hellekin> basically if there's an RFC that says: thou shalt not pass .onion to the DNS, there's plenty of ways for implementors to do it effectively at various steps of the transaction.
[17:09:48] <rbarnes > hellekin: i think that's the point of the .onion draft :)
[17:10:22] <paulwouters> my point was not using two documents that justify each other :)
[17:11:00] <hellekin> paulwouters, the registration is there to ensure that no entity will end up using .onion in the DNS, that is: enforce the Special-Use.
[17:11:14] <hellekin> rbarnes , yes, and the P2PNames draft as well
[17:12:25] <hellekin> paulwouters, I don't think I get the subtlety of your remark about documents justifying each other :)
[17:14:06] <hellekin> Peter Koch, AFAIK .home, .corp, and .mail use the DNS, albeit without registration, but .onion does not use the DNS.  So they're just different cases.
[17:17:23] <rbarnes > someone in the RIPE room — who is speaking?
[17:17:29] <Dan York> hand up
[17:17:39] <Paul Hoffman> hand up also
[17:17:46] <Paul Hoffman> Jelte is speaking to Warren
[17:17:48] <Peter Koch> Jelte is speaking @RIPE
[17:18:42] <hellekin> where are you in the agenda?
[17:19:15] <Hugo Salgado> @Paul Hoffman: no, i'm not
[17:21:01] <jelte.jansen> sorry not in webex so the protocol got a bit unclear to me (and i don't think i have ever been asked to speak *louder*)
[17:21:30] <tjw ietf> str4d, then dan, than paul
[17:21:49] <ray> who’s talking
[17:21:50] <ray> ?
[17:21:59] <Suzanne> Mark McFadden
[17:22:04] <ray> thx
[17:22:08] <> It's not a policy component.  It's a uses-the-DNS component
[17:22:24] <rbarnes > oof, mark, "stability" is a vague thing to engineer for
[17:23:28] <> The problem with the argument Mark is advancing right now is that, if I can create enough evidence of use of any string at all, I have an immediate argument for registration in the special names registry
[17:23:45] <Paul Hoffman> Andrew: that's why my hand is up
[17:24:01] <> so I don't think we can embrace the precedent of, "This thing is in heavy use on the network and therefore it can't be delegated."
[17:24:18] <john.levine> Andrew: but that seems like straightforward engineering
[17:24:25] <Peter Koch> the IETF did not set the criteria for home, corp, mail but is presented with the result of the measurements and deliberation?
[17:24:34] <jelte.jansen> can it be done with an accompanying 'from now on you are on your own if you pull this'?
[17:24:57] <> @Peter: why not?  
[17:25:38] <Suzanne> I just asked Mark in the webex chat what exactly is the engineering impact of reserving those names in the special use names list?
[17:25:42] <ray> I also think it’s reasonable to say that .corp, .home and .mail (and .onion) are already tainted, but anyone else stupid enough to squat in the future deserves what they get.  They can use foo.alt instead.
[17:25:57] <Suzanne> I admit it escapes me. Maybe I worked for a vendor for too long.
[17:25:58] <Peter Koch> foo.invalid, please
[17:26:04] <rbarnes > ray: that sounds like a fine policy to me
[17:26:23] <ray> I did propose some years ago
[17:26:32] <Lyman Chapin> If we treat this as strictly an operational stability issue that we did not invite, do not approve or disapprove, but simply see - and in seeing recognize an obligation to do something about a stability issue - then we are not creating a precedent for hordes of people to begin contriving new instances of "dangerous strings"
[17:26:42] <ray> (for locally scoped names, c.f. 6303)
[17:28:21] <> @Lyman I think I disagree.  Suppose I'm apply for hotel and someone else is getting hotels and I want to do something about that.  If I just rent myself an enormous botnet and create lots of traffic for hotels, I have an argument "hotels shouldn't be delegated because it'll cause problems."  I agree that line is open to others anyway, but it sounds suspiciously like a maintenance-of-DNS-root problem, and that target is painted on another body
[17:28:52] <ray> I think we should allow these four, and .alt, and then *close the registry*
[17:28:59] <john.levine> are we really unable to tell the difference between a botnet and a bunch of users?
[17:29:17] joel jaeggli joins the room
[17:29:37] <rbarnes > this botnet thing keeps coming up.  ISTM that there are ways to detect that, and it would end up blowing back on the applicant
[17:30:01] <Dan York> rbarnes - I agree
[17:30:29] <> that could be.  It seems to me, however, that this is basically a problem with ICANN's root-zone-management rules.  Peter called this "policy laundering" earlier, and I think I agree with him
[17:30:54] <Peter Koch> on what basis would the IETF orchestrate the necessary measurements or verify those provided by 3rd parties?
[17:31:15] <john.levine> history sugests that stupid people will do stupid things no matter what we do
[17:31:38] <rbarnes > john.levine: +100
[17:32:09] <Paul Hoffman> Richard: your +100 invalidates what you just said, I think.
[17:32:53] <Paul Hoffman> You assume that someone would notice that the previous attempt failed, and they shouldn't try.
[17:33:19] <ray> (my hand is up)
[17:33:21] <rbarnes > Paul Hoffman: predictions are hard, especially about the future
[17:33:51] <Paul Hoffman> Richard: generall agree, except what John said.
[17:34:18] <hellekin> I'm not sure I follow correctly but what ray wrote worries me.  Surely .{home,corp,mail}.alt is OK except for the usability issue, but .onion.alt just cannot work: .onion names are unique, i.e., not covered by .alt draft
[17:34:45] <ray> I was including .onion in the four
[17:34:52] <> onion _could_ have been onion.alt, though
[17:35:06] <alecmuffett> ...ten years ago, that would have been prescient
[17:35:08] <ray> and I’d argue that all *future* such apps should use foo.alt
[17:35:10] <Paul Hoffman> Or onion.invalid
[17:35:20] <hellekin> ray so then you were excluding the other 5 pTLDs of the P2PNames draft?
[17:35:21] <rbarnes > i like the adjective "tainted" that ray applied
[17:35:27] <ray> invalid has too much semantic meaning
[17:35:27] <Paul Hoffman> ...which would not hve ben prescient
[17:35:48] <jelte.jansen> .nodns
[17:35:57] <marco@nl> +1
[17:36:04] <rbarnes > let the string wrangling begin
[17:36:21] <> alt saves two octets
[17:36:22] <Paul Hoffman> RIPE room: please mute
[17:36:30] <> and saving octets would be important here
[17:36:34] <jelte.jansen> .thisisnttheresolutionprotocolyourelookingfor
[17:36:37] <rbarnes > .x
[17:36:41] <marco@nl> or just say .no and sacrifice that TLD for this purpose
[17:36:49] <hellekin> jelte :)
[17:36:51] <alecmuffett> Norway will love that
[17:37:14] <ray> I haven’t seen sufficient information about the usage of the other names in P2P to form an opinion on those
[17:37:21] <bortzmeyer> rbarnes : i agree. 1-letter TLD are available
[17:37:22] <> A single-octet label could cause problems for historical reasons, which is why picking three octets is preferred
[17:37:47] <bortzmeyer> ajsaf: can you elaborate on these historical reasons?
[17:37:49] <ray> “alt” has *good* historic relevance here
[17:37:50] <rbarnes > causing problems for legacy stuff seems like a feature, not a bug
[17:37:54] <Paul Hoffman> Thank you, Lyman.
[17:37:56] <ray> (usenet, “alt roots”, etc)
[17:37:58] Weiler joins the room
[17:37:59] <hellekin> ray what information do you need?
[17:38:01] <rbarnes > if old gear drops queries that we want to be dropped...
[17:38:15] hellekin likes .alt, just not for special-use names
[17:38:30] <ray> evidence that the usage is sufficiently high and meritorious to justify a 6761 registration
[17:38:30] <marco@nl> yeah, it could work
[17:38:51] <Francisco Arias> how about one of the two-letter codes that Ed's draft is proposing to reserve (e.g., .xx)?
[17:38:54] <rbarnes > ray: "meritorious" could be a problem
[17:39:03] <ray> Tor has merit ;-)
[17:39:34] <Lyman Chapin> +1 suzanne
[17:39:59] <ray> I’ve been in the queue for 10m (hand up in webex)
[17:40:29] rbarnes leaves the room
[17:40:30] <jelte.jansen> assuming it is something people want to prevent; is the threat of having someone register your shiny new non-tld enough to deter future use of new names ('before they get famous')?
[17:41:03] <tjw ietf> apologies ray, I missed your hand.
[17:41:35] <hellekin> ray, I have yet to release the MMS (meritorious measurement software), we're still on the specs...
[17:41:50] <Dan York> hand
[17:42:12] <hellekin> ray: but I have a draft that details the 7 criteria of the RFC6761 for 6 domains.
[17:43:35] <> I think this argument of Dan's is incoherent.  We already tell people not to use random DNS names at other levels of the tree.  The same thing applies here
[17:43:36] <hellekin> is 10 years of continuous development meritorious enough?
[17:43:41] MAP joins the room
[17:43:48] <> and the 6761 registry doesn't apply just to TLDs
[17:44:05] <Dan York> I love being told my argument is incoherent!
[17:44:47] <hellekin> Andrew, does that mean b32.i2p could be reserved in addition to .i2p for example?
[17:45:03] <> That's my reading of 6761, yes
[17:45:32] <> Though if you're registering a name higher in the tree, there seems little reason to reserve things under it too
[17:45:54] <ray> except to prevent clashes with foo.alt vs bar.alt :(
[17:46:02] <alecmuffett> My personal suspicion is that if the registry is closed, the space of URI schemes will expand to include: interenetwithsomemagicontop://mymagichost.sometld
[17:46:49] <hellekin> I hesitated detailed the specs of that domain, but it shares most characteristics of .onion and .zkey, so the three of them can be described as self-authenticating-globally-unique-hash domains.
[17:47:36] <> I think the idea that any app developer is registering a new TLD just for the app's use is crazy.  New developers don't need to worry about such names — their apps never expose names anyway.  That's why cases like onion are I think more important — they're a switch in the infrastructure, not kewl namez OMFG
[17:48:12] <paulwouters> alecmuffett: where all of this should have been at to begin with!
[17:48:21] <paulwouters> alecmuffett: except: humans.....
[17:48:35] <Dan York> There are developers out there who are building their apps and they don't have a clue that the IETF even exists.  They don't know ICANN exists. They are just out there building cool apps.    They build this app that uses a .ZZZ "domain" for communication in its own kind of namespace… not using DNS but within its own space, like Tor.    The app gets very successful… lots of people use it… and then the developers (or someone) realizes there may be a conflict.  They come to the IETF and we say "Well, sorry, you should have been using .ZZZ.ALT"!    They're not going to change at that point.
[17:48:43] <ray> Onion isn’t really a scheme, though, is it?
[17:48:44] <hellekin> ray my reading of .alt draft is that foo.alt and bar.alt are not delegated and can be used in the same collision space
[17:49:07] rbarnes joins the room
[17:49:13] <ray> since multiple protocols (and schemes) can all tunnel over it
[17:49:14] <alecmuffett> yeah, but people think scheme=protocol
[17:49:20] <alecmuffett> and want to run HTTP or HTTPS
[17:49:27] <alecmuffett> so they don't have to change the browser
[17:49:41] <alecmuffett> This is what comes of taking TBL at face-value :-)
[17:49:44] <paulwouters> alecmuffett: with http dead, lets hope we can keep that information out of newborns
[17:49:59] <rbarnes > paulwouters: let's not count our chickens yet
[17:50:05] <> bye all
[17:50:19] leaves the room
[17:50:20] john.levine leaves the room
[17:50:20] <Paul Hoffman> later!
[17:50:20] Weiler leaves the room
[17:50:23] <marco@nl> NO CARRIER
[17:50:24] <paulwouters> it should have been tor://whatever.onion
[17:50:25] marco@nl leaves the room
[17:50:28] Lyman Chapin leaves the room
[17:50:32] Dan York leaves the room
[17:50:37] Paul Hoffman leaves the room
[17:50:43] <Suzanne> thanks everybody!!
[17:50:51] Francisco Arias leaves the room
[17:50:52] Peter Koch leaves the room
[17:51:11] bortzmeyer leaves the room
[17:51:55] ray leaves the room
[17:52:14] jelte.jansen leaves the room
[17:52:20] <jreed> The blue sheet is for those who just listen too (like in-person attendance). How do we do that for the phone+jabber attendance?
[17:52:30] <rbarnes > paulwouters: no, because you're still doing HTTP over the channel
[17:52:34] <alecmuffett> tor is a circuit protocl
[17:52:45] <alecmuffett> you do HTTP, HTTP, SSH over the channel
[17:53:08] <paulwouters> rbarnes : and you still do tcp on the channel and we dont call it tcp:// either :P
[17:53:25] <alecmuffett> exactly
[17:53:29] <alecmuffett> you're making the argument
[17:53:32] <rbarnes > paulwouters: you're making my point.  normal HTTP isn't tcp://
[17:53:37] <alecmuffett> Tor is a effective layer3 protocol
[17:53:46] <rbarnes > alecmuffett: httpt:// :)
[17:53:54] <alecmuffett> not even that :-P
[17:53:56] <Suzanne> @jreed: we saw you here :)
[17:54:02] <rbarnes >
[17:54:06] <alecmuffett> This is a sore point with some in cab forum
[17:54:10] <jreed> okay
[17:54:18] <alecmuffett> running HTTPS over something which is not backed with DNS seems challenging
[17:54:18] <paulwouters> only technical people think it is layer3. humans think it is layer9 :)
[17:54:42] <alecmuffett> because certificates seem to thing the internet is a DNS space
[17:54:45] <alecmuffett> ^think
[17:55:05] <paulwouters> first, there was the Extension war, then the Mime Wars, then the Protocol wars :)
[17:55:11] <rbarnes > well, HTTP URLs use names within the DNS namespace
[17:55:24] <rbarnes > what we're talking about is separating part of the namespace from the resolution protocol
[17:55:30] <alecmuffett> exactly
[17:55:47] <alecmuffett> and, as all SunOS users know, that's /etc/nsswitch.conf :-P
[17:56:06] MAP leaves the room
[17:56:14] <alecmuffett> Gosh, we can close the registry and let 1000 resolvers bloom...
[17:56:45] paulwouters leaves the room
[17:56:54] <hellekin> /etc/nsswitch.conf is the battelfield of overlay networks.
[17:56:59] <alecmuffett> www.toronion.alt, jkhewrkjhewrkjhewk.content-based-addressing.alt, ...
[17:57:24] <alecmuffett> so many options, and then someone will want an SSL certificate for one of them :-)
[17:57:46] <hellekin> what's the point of SSL certificates again? :)
[17:57:47] <Suzanne> @alecmuffet, another example of the success disaster that is DNS: the namespace is so useful that everyone is using it for everything
[17:58:42] <alecmuffett> ...yes! or that URIs are so flexible they can encode more than the IETF originally envisioned, and some missed assumptions exist even then :-)
[17:59:20] <alecmuffett> how: SSL Onion certs:
[17:59:25] <Suzanne> I'm fine with protocols having uses that the designers didn't expect, it's a good thing!! but I think DNS has gone way too far :)
[17:59:27] <alecmuffett> ...half way down
[17:59:33] Suzanne leaves the room
[17:59:45] <alecmuffett> dropping off now, see you on the list.
[17:59:46] alecmuffett leaves the room
[18:01:21] jreed leaves the room
[18:01:30] Hugo Salgado leaves the room
[18:01:34] rbarnes leaves the room
[18:02:29] hellekin idling here
[18:03:17] MAP joins the room
[18:06:40] MAP joins the room
[18:06:59] Ralf Weber leaves the room
[18:13:28] MAP leaves the room
[18:18:37] MAP leaves the room
[18:34:11] joel jaeggli leaves the room
[18:46:41] joel jaeggli joins the room
[18:47:11] tjw ietf leaves the room
[19:04:18] tjw ietf joins the room
[19:04:48] tjw ietf leaves the room
[19:39:20] marka joins the room
[19:47:58] joel jaeggli leaves the room
[19:58:05] joel jaeggli joins the room
[20:01:05] marka leaves the room
[21:30:56] MAP joins the room
[21:43:19] alecmuffett joins the room
[21:45:50] alecmuffett leaves the room
[21:47:01] alecmuffett joins the room
[21:47:33] alecmuffett leaves the room
[22:10:26] hellekin leaves the room
Powered by ejabberd Powered by Erlang Valid XHTML 1.0 Transitional Valid CSS!