[07:01:44] Ning KONG joins the room [07:01:48] Ning KONG leaves the room [08:43:40] SUNGUONIAN joins the room [09:11:51] niall joins the room [09:13:45] niall leaves the room [09:28:17] niall joins the room [09:28:49] niall leaves the room: Logged out [10:25:05] mrichardson joins the room [10:44:07] SUNGUONIAN leaves the room [11:34:28] mrichardson leaves the room [11:37:34] mrichardson joins the room [11:48:47] mrichardson leaves the room [12:01:45] danny joins the room [12:01:58] danny leaves the room [12:37:36] mcharlesr joins the room [12:49:25] niall joins the room [13:01:46] Carsten Strotmann joins the room [13:09:39] hallam@gmail.com joins the room [13:10:39] Anyone got the audio feed to work? [13:11:24] Joseph Gersch joins the room [13:12:12] Audio is working here, VLC over Ipv6 [13:12:33] What do I tell VLC? [13:13:06] rhe@wiki.ja.net joins the room [13:13:10] Video Lan Client —> http://videolan.org/ (VLC is the client I'm using) [13:13:23] yone joins the room [13:13:42] I just click on the link, but you should also be able to copy and past the Audio URL into VLC [13:13:55] File -> Open Network [13:14:07] OK thanks, got it [13:14:50] Had not thought of using VLC for that, was using another thing chrome chose for me [13:15:24] avri joins the room [13:16:59] Andrew Newton joins the room [13:18:30] Cary joins the room [13:18:52] there is an IPv6 for the fed? [13:19:00] ogud joins the room [13:19:15] aka joins the room [13:19:27] is there an IPv6 for the audio feed that is? [13:19:43] sure :) [13:19:54] ogud has set the subject to: IETF-78 DNSEXT meeting in progress [13:20:34] that is the default I get here from an IPv6 Network using VLC [13:20:35] Sun Guonian joins the room [13:20:48] 8bc23b4c365a8757 joins the room [13:21:02] Olafur: meeting starting in 10 seconds [13:21:30] weiler joins the room [13:21:48] Olafur: introducing co-chairs, note well, etc... [13:21:57] skudou joins the room [13:22:11] Frederico Neves joins the room [13:22:15] Olafur: Nomcom will soon be asking for input on ADs, IESG, IAB [13:22:22] Chris Griffiths joins the room [13:22:38] slides: existing items [13:23:17] dhankins joins the room [13:23:25] slides: report of chair, dnsext-rfc2671bis-edns0, dnsext-rfc2672-dname [13:24:22] andrew: rfc2671bis-edns0 needs editor [13:24:30] Ning KONG joins the room [13:24:33] olafur: joa damas taking it over [13:24:35] fdupont joins the room [13:25:07] healthyao2000 joins the room [13:25:12] andrew: 2672bis-dname --- cname to go to another draft... two questions for wg [13:25:30] andrew: yes/no? does this issue with cname/dname belong in another doc? [13:25:35] room: silent [13:25:41] andrew: nobody's knows the issue [13:25:44] room: laughter [13:25:57] Jelte joins the room [13:26:21] andrew: dnsext-xnamercode-02. how many people have read? [13:26:23] spadgett joins the room [13:26:24] woolf joins the room [13:26:25] what slide? [13:26:27] andrew: how many understand [13:26:47] slide labeled draft-eastlake-dnsext-xnamercode-02 [13:27:07] Stephen Morris joins the room [13:27:10] andrew: explaining the problem. 2 options. people are still looking perplexed [13:27:14] I hear audio, how do I view slides? [13:27:28] http://tools.ietf.org/wg/dnsext/agenda?item=agenda78.html [13:27:32] thanks [13:27:37] hmz we need datatracker to show submitted-but-not-accepted drafts too [13:27:48] wouter: cname to something and it might not exist and the rcodes don't say which one does not exist [13:28:09] wouter: implementation differences about which rcode is to be used [13:28:31] wouter: do you get the cname or follow it... [13:28:49] andrew: people still looking perplexed [13:28:57] pete: is this relevant to operations? [13:29:00] fujiwara joins the room [13:29:14] joseph.yee joins the room [13:29:20] pete: the answer to that should direct the working group [13:29:31] andrew: we may be making these chains longer [13:29:33] pabigot joins the room [13:29:40] mark andrews: should we be following cnames anyway? [13:30:00] mark: talking about cache poisoning for following out of the zone [13:30:16] mark: attempted to make named not follow cnames [13:30:36] andrew: you think the answer to that question broadens this scope? [13:30:39] mark: yes [13:31:10] andrew: point of all this is about moving text out of 2672bis-dname [13:31:18] andrew: taking to the list [13:31:24] jinmei joins the room [13:31:33] andrew: any objections about taking it to the list? [13:31:43] andrew: hearing no objection... will move to list [13:31:52] jinmei leaves the room [13:31:53] andrew: dnssec registry fixes [13:31:53] jinmei joins the room [13:32:15] andrew: editor now has it under control, but not updated for this meeting [13:32:18] Jim Galvin joins the room [13:32:47] andrew: goes down tsig/md5 dialog and backs it out [13:33:09] Stephen Morris leaves the room [13:33:13] peter: iana not keeping track of 2119 text [13:33:21] andrew: right about process issue [13:33:40] andrew: put column in list that can be empty [13:33:43] Stephen Morris joins the room [13:34:06] andrew: if you want to change the registry, you have to obsolete the doc this draft will represent [13:34:16] Alireza Saleh joins the room [13:34:22] andrew: can't update the rfc, just obsolete it [13:34:34] andrew: allow implementers simply to go to the iana registry [13:34:56] peter: postpone this [13:35:09] andrew: trying to punt to get this out the door. wait for the new draft [13:35:18] andrew: dnssec-bis-updateds draft [13:35:27] Stephen Morris leaves the room [13:35:33] andrew: text about rollover and die [13:36:03] olafur: disagrees about the text [13:36:12] andrew: who else thinks the answer is no. [13:36:25] andrew: who thinks the text for rollover and die is finished [13:36:40] andrew: small number for text not ok, no hums for text ok [13:36:51] Lyman Chapin joins the room [13:37:02] andrew: other issue is proposal from design team meeting [13:37:12] olafur: live demo of rollover and die [13:37:27] fred is hooking up his laptop [13:37:35] fred showing graph with lots of red [13:37:53] fred: we started signing rollover and started at 6am this morning [13:38:15] slide shows peak of 4000 at 8:19 [13:38:24] fred: we still have 2 hours [13:38:26] hta joins the room [13:38:53] slide is not "Existing Cont'd" [13:39:00] andrew: cd bit handling [13:39:12] andrew: talking about design team in Bethsda [13:39:31] Stephen Morris joins the room [13:39:36] andrew is discussing the report and the 3 strategies [13:39:48] pabigot leaves the room [13:39:49] andrew: always set, never set, sometimes set [13:40:45] andrew: we want a default [13:41:05] hardaker joins the room [13:41:11] andrew: any who feel strongly about no default? [13:41:18] room is silent... nobody at mic [13:41:33] andrew: only people who thing there should be a default are on the list [13:42:02] g.e.montenegro joins the room [13:42:03] andrew: I believe most validators have implemented always set [13:42:09] andrew: one implementer nodding head [13:42:52] andrew: asking questions about which to do [13:42:56] room is silent [13:42:56] i am for 'always set' :) [13:43:04] stainlesskim joins the room [13:43:09] so am i [13:43:29] if we hear nothing here, and confirm nothing on the list, the result is.... [13:43:31] ? [13:43:34] matt: rationale for always wet other than affecting code [13:43:54] hta, I think andrew said someting about taking it to the list [13:43:58] danny joins the room [13:44:09] mike st johns: doesn't require doing something weird with the cache [13:44:17] mike: prefer third option, but can live with this [13:44:23] that's what I wonder about ... if nobody says anything on the list, the silence in the room is confirmed.... [13:44:26] there's yet another reason [13:44:30] andrew: specifying a default doesn't mean you can't do the others [13:44:36] marco joins the room [13:44:47] Chris Griffiths leaves the room [13:44:58] you don't need to requery later if you do get CD=1 queries later [13:45:05] sam: option 1 and 3 mean you can't get help from upstream cache? [13:45:08] andrew: yes [13:45:15] sam: 2 allows that [13:45:21] spadgett leaves the room [13:45:21] andrew: yes, there is a trade off [13:45:30] Antoin joins the room [13:45:42] andrew: it would be bad for us to put out a doc that makes all the deployed code wrong immediately [13:45:43] weiber joins the room [13:45:58] olafur: validator in depth not the original idea [13:46:05] sam: they didn't think about caches too [13:46:23] rob austein: some of us were concerned about that but the wg wasn't [13:46:23] scottr joins the room [13:47:02] jim galvin: never set would make all existing validators wrong, but that isn't correct [13:47:09] jim: you just have to have the option [13:47:22] andrew: in the deployed validators, there is no option [13:47:29] spadgett joins the room [13:47:35] jim: if they don't have the option then they are wrong [13:47:44] sam: they are not wrong if we say SHOULD [13:47:46] Chris Griffiths joins the room [13:48:22] andrew: most people are gonna configure root and that collapses 1 and 3 [13:48:30] andrew: for fast and cheap, 1 is the winner [13:48:54] mark andrews: hard part about validators through cache is when under attack? how do you clear the cache [13:49:00] sandoche joins the room [13:49:37] mark: ta's match against cache and stub resolver... stub doesn't set cd [13:50:03] sorry... I am having a hard time paraphrasing him [13:50:14] sam: doesn't matter much between 1 and 2 [13:50:36] sam: either way, we have cleaned up the old instructions... and have allowed the use of cached positive answers. [13:50:50] mark: positive ansers come out of the cache [13:51:06] andrew: look for messages on the list for confirmation then LC [13:51:36] olafur: jabber participants speak now and I will look at this room after the meeting [13:51:57] I think the default should be number 2: never set - we get the most out of dnssec validation. but I can live with 1. [13:52:08] andrew: new work... one item is aliasing. also meeting on Wed. aimed at users of dns [13:52:10] RussMundy joins the room [13:52:38] andrew: about solving the problem they have not the ones they don't have. tell consumers of the dns concerned about aliasing to come wed. [13:52:49] andrew: get as much input as possible [13:52:59] slide is BNAME and competitors [13:53:07] Otmar Lendl joins the room [13:53:16] andrew: aliasing ideas are bname and bname+cname [13:53:21] elmi4711 joins the room [13:53:30] andrew: everybody thinks we should tackle aliasing [13:53:40] bname VS c+dname [13:53:49] you are right [13:54:08] ed: what if the idn problem is intractable, is this a good idea to do anyway? [13:54:22] andrew: some say yes because of architectural purity [13:54:37] mark: i have use cases for ... [13:54:49] jim: solve this problem or the general idn problem? [13:55:03] ed: don't have long term solutions to short term problems [13:55:13] ed: wait until we are convinced we can solve it [13:55:26] ed: is it worth doing if we can't solve their problem [13:55:33] rob: should we do one of these anyway [13:56:01] Why do people think it is just an IDN problem? Perhaps the IDN issues is just the first use of it. [13:56:11] Pass on: justification should be from use cases draft, not from architectural purity [13:56:12] jim: is this a long term solution to a real problem? we have other things to look at in aliasing space [13:56:44] given DNS code deployment cycles, if we don't have a long term problem, we shouldn't do this. [13:57:10] andrew: ed is asking if we should do this anyway for completeness [13:57:23] jim: if we have something to solve a problem we should do it, but this doesn't solve idn [13:58:06] harald: the idn problem? please delete from your vocabulary [13:58:39] There are two problems here, there is ease of administration (let the server makers fix) and there is cache efficiency (worth doing). both seem to be conflated into the requirements specification. A partial problem to the cache efficiency issue is acceptable. [13:58:55] harald: each specific class of problems bname, c+dname might be appropriate but people bend their problems into the shapes of our solution [13:59:09] harald: don't solve solution without describing problem [13:59:36] harald: get out of the way and deploy it solutions to problems [14:00:04] ywang830 joins the room [14:00:10] andre: this problem is general... not about idn. corps registering in all tlds is another example of the problem [14:00:16] Would help here if we were careful to distinguish between 'requirements' and 'problems'. We may not be able to satisfy every requirement, but that is not necessarily blocking. 'Problems' is an ambiguious term [14:01:05] olaf: there might be many tiny solutions to many tiny problems which create a mess [14:01:39] +1 for olaf's comment [14:01:40] olaf: need generic problem description [14:01:59] andrew: two attempts to solve a similar problem in 2 ways [14:02:04] (not only because of deployment, also because of interaction between solutions) [14:02:09] andrew explaining bname [14:02:17] andrew explain c+dname [14:02:32] kongyong1 joins the room [14:02:52] andrew: controversy with c+dname may affect other parts of the dns/clients [14:03:17] wilmer joins the room [14:03:33] unknown: comment on behalf of chinese users, only so many users... we want a solution to the management. agree with harald [14:03:54] xiaodong Li, I think. [14:04:03] sam, I think you are right [14:04:15] Zhen Tsao joins the room [14:04:35] xiaodong: if there is a problem, we should find a solution. no preference to which one [14:04:59] mark: not versus, lets do both [14:05:55] mark: uses cases for both [14:06:18] andrew: back to olaf's comment... we have an old protocol that is fragile. not inclined to do everything [14:06:56] mark: responding about andrew's comment about bname and ttls... [14:07:09] mark: that only gives the bname solution space. i'd implement both [14:07:48] kongyong1 leaves the room: offline [14:07:48] andrew: if we do cname+dname, caching resolvers may answer nxdomain [14:07:50] hmm. So, make BNAME a *PRESENTATION* mode thing, and thus people can't really change them seperately, if that's what they used. (maybe even allocate an RR for it, for DNSUPD...) [14:07:51] mark: incorrect [14:07:54] andrew: oh [14:08:06] andrew: glad that I'm wrong [14:08:22] andrew: primary thing about c+dname is what breaks [14:09:01] unknown: first get replacement of original name... if not exist, dname will be unresolvable [14:09:21] <8bc23b4c365a8757> Jiankang Yao@cnnic [14:09:42] olafur: we ran into this with dnssec, and we had to relax the rules [14:10:00] Carsten Strotmann leaves the room: Replaced by new connection [14:10:01] Carsten Strotmann joins the room [14:10:22] olafur: not every dns type is equivalent. cname prohibition is oriented to data types and not control types [14:10:27] kongyong1 joins the room [14:10:50] ed: if we adopt things like this it is gonna solve some problems, but how many other idn situations will go away [14:11:27] solves the problem at the registry management level [14:11:27] andrew: will discuss on Wed [14:11:54] jim: speaking at reg svc provider, this can be solved in the registry [14:12:21] jim: when you know your policy, just populate multiple entries [14:12:43] andrew: argument made before, possible to do entirely with provisioning [14:12:54] andrew: some say it is infeasiable to do that [14:12:56] other people have already made that argument [14:13:02] andrew: but I take your point [14:13:07] jim: point out of order? [14:13:23] andrew: it is legitimate to say that dns should not change because of this [14:13:33] Point: Maybe the inability of some parties to support that type of provisioning is a business opportunity for others more competent [14:13:52] Ondrej up next [14:14:37] slide authoritative dns side [14:14:46] Stephen Morris leaves the room [14:14:54] ondrej: modified bind9... few changes [14:14:59] slide: recursive dns side [14:15:16] ondrej: tested bind, unbound, one domain [14:15:26] ondrej: tested idn inside [14:15:51] ondrej: works ok [14:15:58] slide: other test [14:16:03] ondrej: postfix works ok [14:16:16] ondrej: sendmail rewrites smtp-to [14:16:20] slide: known problems [14:16:33] ondrej: chained caches are to ask for dname [14:16:42] ondrej: similar to dnssec problem [14:17:08] ondrej: some apps have special cname handling [14:17:20] ondrej: i have not seen these apps [14:17:25] slide: tbd tests [14:17:33] ondrej: what else needs to be tested. send email [14:18:05] andrew: somebody on the list said the tests wre inadequate... whoever said that needs to follow up [14:18:49] unknown: bind was modified, user may not know if their server is modified for this [14:18:53] Larissa Shapiro joins the room [14:19:05] nordmark joins the room [14:19:37] olafur: good point, if c+dname is loaded without warning and is dropped that is a problem [14:19:49] olafur: of the 8 resolver implementations only half support dname [14:20:12] olafur: even the two most recent ones don't support dname [14:20:41] olafur: if you have a problem that you are convinced cannot be solved with either solution, we would like to hear about it [14:20:59] olafur: or cannot be solved with dname or cname by themselves [14:21:06] andrew: long list, I'll send it to the list [14:21:27] technically there is an infinite amount of problems that cannot be solved by this [14:21:31] andrew: any problems that can't be solved by c+dname that can be by banem [14:21:37] room: no answers [14:21:43] peter: deployment timeline? [14:22:03] ywang830 leaves the room [14:22:24] peter: considerations for deployment. what point in the tree are theses changes made, when is it to happen [14:22:39] peter: would answers to those questions impact our decision [14:22:44] ywang830 joins the room [14:22:59] 8bc23b4c365a8757 leaves the room [14:23:06] mark: i did c+dname for half hour... bname is one days worth [14:23:22] mark: for deployment, just needs to be deployed by the authoritative service. [14:23:29] mark: one or two months [14:23:40] matt: can I ask implementers to not lecture operators [14:23:51] marK: we can get the code out there, you just have to use it [14:23:59] matt: ok [14:24:25] andrew: the merits of doing anything are worth looking into [14:24:57] andrew: moving this to a zone file writer, it moves the pain. but if it takes us two years... [14:25:23] ondrej: for bname support you don't need resolvers and c+dname [14:25:39] ondrej: on provisioning, doesn't scale among some operators [14:26:10] andrew: something about developing protocols [14:26:38] andrew: difficulty of changing the dns stands in the way of making this a real solution [14:26:51] andrew: could be better if the solution was with zone file managmeent [14:27:01] andrew is futzing with the slides [14:27:09] andrew: could be done with shadowing [14:27:18] slide: shadowing zone [14:27:44] andrew: argument for shadow zones doesn't require changes on public facing side [14:27:56] andrew: other strategies beside in-dns aliasing [14:28:45] unknown: shadow doesn't change resolver, shadow doesn't work with children... different level of domain space [14:29:12] unknown: shadow only works in one level of zone [14:29:19] speaker is Jiankang Yao (CNNIC, a co-aiuthor on a couple of the drafts) [14:29:24] The question here for me is if the authoritative servers are going to be required to support legacy resolvers by expanding out the aliases or not. If you do not do that expansion then the scheme is not going to be reliably supported for decades (if ever) and is not going to solve any administrative issue Contrawise if you do the expansion of aliases to support legacy then you could do it for everything. [14:29:43] thanks [14:30:15] andrew: if it turns out that either bname or c+dname not useful, does shadow zone have utility independent of it? [14:30:20] room: silent [14:30:40] andrew: can anybody identify utility of shadow zones without bname, c+dname [14:30:52] doug otis: facilitate management at registry [14:31:02] andrew: shadow not good for multiple layers [14:31:27] alfred: if bname or c+dname work, is shadow still worth it [14:31:50] andrew: are shadow or bname,c+dname worth doing at the same time [14:32:02] room: a few people say no [14:32:26] alfred: registry tools and shadow would work but scaling is a problem [14:32:43] alfred: complicated to do at lower ends of the tree [14:33:17] alfred: replication only applies to single state aliasing. multi-state aliasing is different [14:33:38] alfred: organizational solutions are less attractive [14:34:10] alfred: infeasable to solve equivalence problem with organizational methods [14:34:20] lower end of tree is significant: expertise is likely diminish with distance from root [14:34:30] alfred: protocol side and organizational side have differing values [14:34:52] ray joins the room [14:34:55] Jiankang: no 2 perfect solutions [14:35:22] ondrej: don't do shadow because of how long to do deploy [14:35:32] ondrej: bname,c+d just change servers [14:35:39] narten joins the room [14:35:41] ondrej: changes for shadow are in more places [14:35:45] what happens if you have a delegation inside a C+DNAME zone? [14:36:09] andrew: you are saying shadow requires change to provisiioning system...? [14:36:11] ondrej: yes [14:36:35] olaf: but it isn't the need for doing it at the place for the people who are ecentivized to do it [14:36:56] Jiankang: everything needs to change... deployment time is the same [14:36:58] Ray: both Dname and Cname do not allow delegations below them but a zone can have C or D at name x and name y is delegation [14:37:14] andrew: people seem to be saying we shouldn't do shadow. will confirm on list [14:37:15] woolf leaves the room [14:37:18] suzanne is up [14:37:51] i think that if we reach the conclusion that b/c+d does not work, but shadow zones do, that we have reached the conclusion that provisioning *can* solve the problems [14:38:11] 8bc23b4c365a8757 joins the room [14:38:11] slide why this draft exists [14:38:31] suzanne: draft exists becaue of problem statement [14:38:50] suzanne: attempt at problem statement draft for aliases [14:39:23] suzanne: currently existing and not, in dns and not [14:39:40] suzanne: draft is attempt to capture the likes of this discussion [14:39:54] suzanne: explain what wg does no does not do [14:39:57] Olafur - I mean in the zone pointed at - if foo C+DNAME bar, and xxx.bar NS ...., does xxx.foo also exist? [14:40:06] slide: what we're trying to accomplish [14:40:59] suzanne: dns and apps people talk past each other. need common terms and understanding. perhaps this is just a hope [14:41:12] suzanne: implicit in new charter [14:41:17] slide: next steps [14:41:24] suzanne: need more example and use caes [14:41:46] suzanne: need to know the problems [14:42:02] suzanne: idn is a major driver, but not clear if that is the only one [14:42:17] suzanne: clearer set of rationales [14:42:43] suzanne: think it should be a wg doc [14:43:11] andrew: how many people have read the variuos docs? [14:43:20] andrew: read bname draft? [14:43:25] room: half [14:43:30] andrew: c+dname? [14:43:33] i have read them [14:43:36] room: about the same number [14:43:41] andew: shadow? [14:43:45] room: same crowd [14:43:46] y [14:43:56] andrew: identical resolution> [14:43:59] room: fewer [14:44:00] y [14:44:08] y [14:44:24] y [14:44:28] andrew: fewer people read the parts about why we should do it than read the potential solutions [14:44:38] ed: we are burned out reading the solutions to understand the problem [14:44:55] rob: it took us 10 years to get the dnssec problem statement [14:45:11] sm joins the room [14:45:26] pual hoffman: the first time we knew we had the problem was 11 years ago with IDN. we were told not to touch dns [14:45:42] paul: we have been avoiding this. [14:46:15] paul: if idn is the major driver, the problem is still there [14:46:24] harald: talk about contents of the draft? [14:46:26] andrew: yes [14:46:40] Lyman Chapin leaves the room [14:46:51] harald: things that were not stated... dns has not business which two string to match [14:47:03] harald: all mechanisms to match are done by humans [14:47:48] harald: doing things in protocol vs registration, is a matter of avoiding problems [14:48:08] harald: if the problem is spoof sites, the solution is to make sure the two strings are under the same management [14:48:35] harald: in this particular case, it makes sense to put this in the doc. volunteering to write text [14:49:26] Mike: I am seeing a huge confusion of requirements and constraints here. The term problem is being used to refer to both. The underlying problem seems to me that some people's requirements are not realizable. [14:49:40] harald: mechanisms at the protocol layer for 2 equal strings, then we don't have to ask any more. in registration authority space you can't verify it [14:50:03] Zhen Tsao leaves the room [14:50:50] xiaodong: we tried to solve this before years ago but didnt'. let's do it in protocol this time [14:51:06] xiaodong: many users want to use idn [14:51:24] xiaodong: would encourage more registrations especially in .cn [14:51:36] xiaodong: problems go beyond .cn [14:51:52] xiaodong: problem should be solved even if it takes 5 years [14:52:04] xiaodong: think of the users [14:52:33] xiaodong: we need a clear problem statement [14:53:04] ondrej: what is the problem with spoofed domain names in the charter? [14:53:06] This is a variation of the wildcard problem. It seems to me that as with wildcard, the only place that the 'records' should appear on the wire are in zone transfers and DNSSEC. [14:53:32] ondrej: no problem to be kept inside just one dns operator [14:54:33] suzanne: important for us doing tech work that we be able to say why were are doing it [14:55:42] andrew: charter discussion [14:55:49] ray leaves the room [14:55:51] slide: charter timelines [14:56:19] rhe@wiki.ja.net leaves the room [14:56:43] andrew: suggested that the cherter doesn't include problem statement, but it is up in the last item [14:57:15] rhe@wiki.ja.net joins the room [14:57:54] I think we can do it earlier [14:57:55] andrew: how many poeple we could move earlier? [14:57:57] room: one hand [14:58:01] andrew: could not? [14:58:05] room: two hands [14:58:17] But we can only do it earlier by cuting down the requirements [14:58:19] suzanne: don't know if we can [14:58:31] andrew: feel strongly we pick realistic milestones [14:58:51] rob: if we don't have a solution by that time, we declare failture and go home? [14:58:55] andrew: yest [14:59:32] olafur: if mark andrews says it can be implemented fast, do we need the extra time [14:59:40] mark: documentation is hearder than implementation [15:00:20] andrew: willing to be the first wg to come early [15:00:40] unknown: getting it right is the hard part... not in favor of moving up the time [15:00:49] andrew: these days are unrealistic? [15:01:00] Simon Perreault joins the room [15:01:06] unknown: recharter to we do stuff and not other stuff.. we'll be rechartering in a year [15:01:27] unknown: unlikely to reach consensus [15:01:35] andrew: we shouldn't take the work on? [15:01:48] Alex joins the room [15:01:57] niall leaves the room: Logged out [15:01:59] 8bc23b4c365a8757 leaves the room [15:02:07] maybe the IETF should create LG's ("lurking groups")? ;) [15:02:12] unknown: thinking if bname, c+dname then do shadow then reach conclusions that prov systems should od this [15:02:16] Chris Griffiths leaves the room [15:02:20] Chris Griffiths joins the room [15:02:38] woolf joins the room [15:02:49] olaf: pick 2 dates, if the date comes, then look again [15:03:05] olaf: milestones are a goal, then you asses why didn't meet them [15:03:19] olaf: good to have milestones early about if the work is doable [15:03:39] mark: worried about the number of revisions [15:04:44] mark: not seeing suggestions being reflected back... don't want to have to say again that bname ignores what i have said [15:05:13] mark: comments not making it into revisions of drafts as it is [15:05:22] andrew: closer or further out milestone [15:05:30] mark: worried about communication difficulties [15:05:41] sm leaves the room [15:05:55] mark: chairs need to facilitate getting comments back into drafts [15:06:28] suzanne: comfortable with timelines original proposed. would be nice to be done sooner but we shouldn't promise earlier [15:06:42] suzanne: need target date on problem statement [15:06:48] andrew: we will move that and adjust this [15:07:30] peter: different that prob statement in dnssec. most people had a common understanding of the problem of dnssec, but aliasing is different [15:07:51] peter: milestone is not a contract between the ietf and icann [15:07:59] peter: that should be made clear [15:08:27] weiber leaves the room: offline [15:08:42] We would be finished already if people would only see sense and do it my way.... [15:09:04] (for all values of 'my way') [15:09:06] murray: could have big ripple even if you guys drop it [15:09:19] murray: if dropped, must have a doc saying why [15:09:33] andrew: I am hearing that we should move the dates up [15:09:51] andrew: heard no suggestions for additional items to add to the charter [15:10:03] peter: wiki thing? [15:10:15] andrew: I simply havent' done it [15:10:25] kongyong1 leaves the room: offline [15:10:40] peter: precedent says that these type of deliverables don't work [15:10:54] It is not clear to me where DNSCurve and similar issues fit into the charter [15:11:02] andrew: things you didn't get done before are not candidates for putting in the charter [15:11:20] slide: draft-crocker-dnssec-alog-signal-06 [15:11:36] andrew: olafur and I have a conflict, asked paf if we should adopt it [15:11:47] andrew: paf said no unless rules change [15:11:57] dhankins leaves the room [15:12:00] andrew: rules have changed, so now automatically added [15:12:17] andrew: have asked paf to be shepard. any objections? [15:12:29] room: no objections [15:13:04] paf: the reason for chair keeping track of doc is about having two people do the same work [15:13:12] andrew: no procedural objections [15:13:20] slide: draft-kerr-ixfr-only [15:13:24] andrew: adopted [15:13:33] andrew: timeline reasonable? [15:14:16] alfred: concerns about this. we should update axfr to be aligned with this [15:15:16] andrew: not proceed with work we have adopted but replac with larger work? [15:15:22] rob: put a new time on it [15:15:26] avri leaves the room: Replaced by new connection [15:15:29] avri joins the room [15:15:33] andrew: 15th of september? [15:15:36] alfred: yes [15:15:40] andrew: done [15:15:51] slide: draft-dempsky-dnscurve [15:15:58] andrew: need to resolve it [15:16:04] stainlesskim leaves the room [15:16:15] Mike: Strong support for addressing the requirements, strongly against using this as a basis [15:16:17] andrew: not in current charter [15:16:25] stainlesskim joins the room [15:16:29] andrew: if you support, need realistic timelines [15:16:42] andrew: need to come to consensus on the list [15:16:46] Jim Galvin leaves the room [15:16:50] andrew: be nice [15:17:04]