[19:28:41] --- ehall has joined
[19:30:38] --- ehall has left
[21:33:33] --- ggm has joined
[21:49:16] --- duidsaki has joined
[21:49:26] --- duidsaki has left
[21:51:32] --- tomphelan has joined
[21:53:39] --- mstjohns has joined
[21:54:15] <mstjohns> dnsops is the appropriate abbrev
[21:54:40] <ggm> not on the printed agenda mate.
[21:55:05] <mstjohns> yeah... *sigh* stand corrected
[21:55:08] --- mstjohns has left
[21:56:00] <ggm> 5 minute wait for late arrivers
[21:56:58] <ggm> agenda bash
[21:57:04] <ggm> status of wg/active drafts
[21:57:10] <ggm> expired wg drafts
[21:57:16] <ggm> other active drafts
[21:57:37] <ggm> Object now or never drafts
[21:57:42] <ggm> Milestone update
[21:57:56] <ggm> http://www.1-4-5.net/~dmm/IETF/IETF59/DNSOP/agenda/
[21:58:24] --- mstjohns has joined
[21:58:43] --- fneves has joined
[21:58:55] <ggm> Dave is at the 'con, Scotty (Austein) is in the navigators seat
[21:59:36] --- Ralph has joined
[21:59:37] <ggm> ted volunteers as scribe
[22:00:14] <ggm> paper on edns0: http://www.nlnetlabs.nl/downloads/edns0.pdf
[22:00:33] <ggm> Rob: all there is to say is that its a work in progress, Danny K said expose the URL.
[22:00:47] <ggm> Rob: trying to keep track of how many Q at servers support EDNS0.
[22:01:21] <ggm> If have time, at end, Paul wants 5 min to give thinking on DNS discovery issue
[22:01:41] <ggm> Don't need tues. session. this one is not filled up. so if this one runs to completion will not do tuesday. (Dave)
[22:01:54] <ggm> Dave: authors for drafts not here
[22:02:10] --- paf has joined
[22:02:18] <ggm> Kolkman/Gieben draft Op practices for DNSSEC
[22:02:33] <ggm> Rob: good initial response, then petered out. nothing new since last meeting
[22:02:43] <ggm> Dave: point of order. when get up to make comments please speak clearly
[22:02:51] <ggm> (for minute taker)
[22:03:10] <ggm> Durand/Ihren/Savola draft on ipv6 dns issues (04)
[22:03:34] <ggm> Savola: sent lots of text, since then not many comments. want last call soon. its waiting for nothing
[22:04:01] <ggm> Rob: anybody think its not ready? object now or it goes to last call..
[22:04:05] <ggm> Rob gone to last call on list
[22:04:21] <ggm> Dave: Morishita/Jinmei misbehaviour against AAAA
[22:04:27] <ggm> authors not here. just re-issued
[22:04:41] <ggm> ok. here.
[22:05:02] <ggm> AUthor. significant change on this revision. submitted individual draft on some misbehaviour last june. based on comments
[22:05:47] <ggm> on ML revised as WG doc. most of the changes historical (?) role of doc is to publish as informational. ready for last call except need to remove appendix. accepting that, ready for WG last call
[22:06:08] <ggm> Rob: Q on this. overlap on one discussing minute ago, on gen Ipv6 issues. make sense to continue as separate docs? talked to Pekka?
[22:06:26] <ggm> A: no particular opinion. generally better to merge to single doc.
[22:06:48] <ggm> Pekka agrees to last call it.
[22:07:22] <ggm> Itoijun. Like to see as separate docs, because one talks about V4 behaviour misbehaviour but the former doc is slightly different issue.
[22:07:40] <ggm> Dave Barber bad dns RES version 02
[22:08:14] <ggm> Pete Barber Verisign. Lars and I have put in this res draft, just before draft deadline. asked for comments. not on list since originally done. Rob has commented, nobody else. waiting for feedback
[22:08:39] <ggm> Rob: not enough reading yet. intent was this was last cycle. push out. good doc when first writtten year ago. stale. added stuff
[22:09:06] <ggm> Pete only three secs when first written, several more things been added. seen other stuff on com/net now. more opportunity for misconfig.
[22:09:42] <ggm> Rob: preference to give people time to read. month. then get WG last call before SanDiego. objects?
[22:09:48] <ggm> [no objects]
[22:10:05] <ggm> GLieben/Guette/Courtay draft on resolve app interface.
[22:10:10] <ggm> Rob not yet WG doc.
[22:10:14] <ggm> Dave not much reading.
[22:10:32] --- ogud has joined
[22:10:41] --- amarine has joined
[22:11:15] <ggm> Rob not even on ID repositary. Topic trying to bring up is one we should discuss, doc is not ready. strawman to get people thinking. I don't think its the right way. do need to think. unless abandon stub resolver model, not bother me but bother others, need to think about semantics of error cases and communicate back. can't just use SERVFAIL all the time. Authors trying to start that discussion. any other comments?
[22:11:35] <ggm> Rob: put back to list
[22:11:38] <ggm> Sam don't read, try something else
[22:11:40] <ggm> Rob naughty
[22:12:05] <ggm> Dave: Ohta san draft on shared root server
[22:12:25] <ggm> Ohta. clarify redundancy method with anycast & multicast. some modification. want to have some discussion hopefully here
[22:12:28] <ggm> this week or email list
[22:12:42] <ggm> Dave polls for readers.
[22:12:52] <ggm> Dave no action except read it.
[22:13:03] <ggm> Dave those are the active ones. Now Object now or never
[22:13:15] <ggm> draft warnike network dns resolution.02
[22:13:28] <ggm> Dave: how many have read? if want to comment, have to read it. only one?
[22:13:51] <ggm> Rob: something really seriously wrong, we can object, but otherwise its time to just go. unless horribly broken leave alone
[22:14:07] <ggm> Pekka. have objections, but on that classification, not that serious. use other venues to force this.
[22:14:19] <ggm> Rob: AD here? Dave Kessins said yes thats it
[22:14:23] --- dcrocker has joined
[22:14:26] <ggm> Sam: if not in repositary hard to comment.
[22:14:33] <ggm> Dave; oh, timed out in drafts repo?
[22:14:42] <ggm> Rob Wg declined to touch it.
[22:15:08] <ggm> Dave: ok lets review
[22:15:11] <ggm> expired drafts
[22:15:25] <ggm> Kato/Vixie draft dnsop respsize
[22:15:43] <ggm> Dave: new version? Rob: planned, but not ready. will be in SanDiego. Dave: nothing to say
[22:15:44] --- nsb has joined
[22:16:00] <ggm> Ihren, draft dnsom interim signed root. not here, nothing to say, overtaken by events
[22:16:18] --- nsb has left
[22:16:41] <ggm> draft dnsop inaddr required. Dave. discuss? bring back?
[22:17:21] <ggm> Itojun have seen more operational troubles with Ipv6 reverse lookup. lot of connection delays. really like to see this published
[22:17:26] --- bert has joined
[22:18:06] <ggm> Rob: misnamed. really its considerations. when to populate, how. last time, when came up was important. Volunteer to be pelted with rotten tomatoes on this one?
[22:18:26] <ggm> Itojun volunteered
[22:18:49] <ggm> dnsop serverid. Woolf
[22:20:27] --- sleinen has joined
[22:20:39] <ggm> ROb: same excuse. dog ate the draft. work is ongoing. draft would back down on new conventions not already out there, document existing hacks in existing SW and would discuss the issues to make them not adequate. the hack we have now is some server impls have magic query. kludge. only recommendation is that its deployed. not right for debugging anycast, if routes flap, no guarantee Q goes to same place. look at dynamics, solve for real with proto extensions which is not this group. EDNS0 extension to identify server. I (rob) for DNSEXT have straw proposal how to do this. its individ draft, motivation still waiting for susanne. done by San Diego
[22:20:49] <ggm> Dave: woolf to produce another draft?
[22:21:04] <ggm> Rob: yes. to be done in DNSEXT. Dave. time to discuss before San Diego
[22:21:29] --- sleinen has left
[22:21:35] --- sleinen has joined
[22:21:39] <ggm> Other active drafts
[22:21:57] <ggm> Guette/Courtay draft on key rollover requirements.
[22:22:01] <ggm> (missed name)
[22:22:15] <ggm> any difference apart from name? (rob)
[22:22:24] <ggm> (A) clarifications, nits. minor mods
[22:22:25] <sleinen> The name is Mohsen Soussi (AFNIC) I think
[22:22:42] <ggm> Dave: Q. anybody read the key rollover draft? [1-2]
[22:22:52] <ggm> (A) relay to author comment. read, send comments to authors. thankyou
[22:22:57] <ggm> Rob should flog on list too
[22:23:25] <ggm> draft kato dnsop local zones. kato/vixie
[22:23:35] <ggm> Dave: read? comments? [floor gave to paul directly]
[22:23:56] <ggm> Kato: apologize, no time to update because of personal reasons [Kato got his PHD btw. we should applaud him!]
[22:24:21] <ggm> Morishita draft on increasing dns server.
[22:24:39] <ggm> on behalf of morishita also unable to update draft, will do before next meeting
[22:24:49] <ggm> Dave. all of drafts.
[22:25:28] <ggm> Pekka: v6 guidelines? ROb: passed WG last call. waiting for some nits pass. Now charter milestores update
[22:26:42] <ggm> DNS discovery issues. critical to new charter -talk about in second. IPV6 DNS ops DNSSEC ops ROOT/TLD/Other systemaic DNS ops
[22:26:42] <ggm> core to what we do
[22:26:55] <ggm> (this is all dave btw)
[22:28:11] <ggm> Dave: gone around this issue more or less endlessly. discussing with ADs. have asked us to write issues doc, describe what the issues are with all three approaches. RA/DHCPlike/WKS -have it ready, submit to IESG by San Diego. That means that we're on short leash with timeframes. most important aspect is if this is NOT done, will be removed from charter and become out of scope.
[22:28:40] --- yone has joined
[22:28:48] <ggm> Rob been having circular discussion. nothing coming out of WG. write down arguments in coherent form so they can be if not settled, let people not involved in this know whats going on.
[22:29:26] <ggm> Dave: need to solicit folks who want to work on this, to be authors and/or editors. hit ground running. challenging to have doc ready for IESG by next IETF. Paul has 5min on this -go ahead now if we like?
[22:30:04] <ggm> Rob: want to ask. any other discussions on other drafts? not trying to slide on dns discovery. just close off on other issues. fine if nothing to do, stuff in draft, discuss now and then get to dns discovery. going once.. twice .. gone.
[22:30:32] <ggm> Dave: 5 mins from Paul, see where we go.
[22:31:39] <ggm> Jaehoon Paul Jeong on V6 DNS discovery
[22:32:18] <ggm> DNSOP decision. AD/chairs decide document three approaches. details op attributes, deployment scenarios, multi solution resolution
[22:32:43] <ggm> RA. delivered along with prefix information options
[22:33:11] <ggm> DHCP -recursive ns option, delivered by dhcpv6 server, or stateless dhcpv6 server (-hte)
[22:33:18] <ggm> third one, WKS, preconfigured.
[22:33:46] <ggm> ordering can be applied
[22:34:04] <ggm> don't know how to apply anycast addr solutions with other options
[22:34:19] <ggm> WKS are last resort.
[22:34:49] <ggm> can use hint option to say WKS can be used
[22:35:44] --- bert has left: Logged out
[22:36:15] <ggm> prefix del env. when gets subnet prefix address can be piggybacked. leaf router adv. with RA options
[22:36:30] <ggm> Mobile. MIPv6 HMIPv6 NEMO -RA options.
[22:36:33] <ggm> Discussion.
[22:38:56] <ggm> Ohta. you do not understand mobile requirements. not required from all operators to provide DNS servers. if none at home network, then if you move, you sometimes loose access to service, since none local. not very good environment to go with DNS. with mobile env, one should have his own DNS server at home. and because mobile host needs some configuration about its home, security key etc, it is not unreasonable requirement that home DNS server should also be configured. mobile node must be somehow configured, do not need protocol. drop mobile env. drop from scenario
[22:39:06] <ggm> Paul. optimized to use local
[22:41:30] <ggm> Ralf Droms. descriptions given here, brings up thought that doc rob was planning to write before San Diego. ought to try and frame or limit the discussion in that document. every time brought up here gone on ad infinitum. could happen during draft writing. as advice, perhaps, has to be limited and framed. no idea how. Rob: one bit of advice given in another context, from old IETF person. not going to get to where everyone agrees. might get to point where doc descirbes issues well enough so everyone involved can see position displayed, and can understand all other positions, even if don't agree. having watched Pauls presentation, initial reaction is good way to look at it, if trying to do all three at once. we've not even decided that. are we doing one/some/all? cant settle in doc, need to write down. Ralf: exactly why to frame in doc.
[22:42:48] <ggm> Rob: is this what AD wants?
[22:43:17] <ggm> David Kessins: correct, also want to know about possible interactions if we have to do multiple solutions. Rob: document interactions? David: yes.
[22:44:48] --- duidsaki has joined
[22:45:04] <ggm> Hinden. good presentation. Q about doc, not sure what happens afterwards. David K. we don't know yet [lughter] depends on document. risks of multiple solutions. make informed decision Hinden: doc to advise IESG. with output? DavidL: yes ROb: this group is NOT going to do protocol work. just been asked to figure out which direction to go. possible we won't be able to make recommendation.
[22:46:54] <ggm> Ralph with specific Q. can you give us more explanation of the WKS hints option. didn't understand why do HINT, why not just put WKS in. Paul Hint can be used. without this option, we assume every site have valid address for DNS server. this hint option can explicitly indicate that. however, this is my opinion. Ohta san has another opinion. this is my private opinion Ralph this is single flag, with no specific address. trying to differentiate. between sending WKS, sending bit to say USE WKS
[22:47:36] <ggm> Hinden. thoughts on how to proceed and NOT write doc.
[22:49:25] <ggm> Dave: orders down from AD. can talk to them if you like. David: go Hinden: still think making big fuss over stuff. DHCP/DHCP-lite/v6 -have options, RA options look straightforward, didn't see big tech issues, WKS, has issues, strikes me its not just for finding DNS servers, range of servers, needs to get discussed in WG with broader scope, Discovery Services or something like that. My constructive sggstion, we have DHCP, send RA option to v6 WG, thats where it should get done, and then ask IESG to find a new home for WKS.
[22:50:19] <ggm> Rob: one thing bob, WG issue is do we need multiple mechanisms, advisable, better to have 1, 2 3. thats the part that neither you nor Paul really cover. IF we want multiple mech, fine. we can't agree on that.
[22:51:16] <ggm> Dave: ops area may be place to look at this with broader perspective DavidK: want input of this WG on DNS matters.
[22:52:51] <ggm> David: want document to see issues. if we decide to go multi, know issues, new WG working on it also know issues. we do know its been going on for long time, thats why deadline. cannot wait any longer. thats current thinking Ralph: clarification being heard. IESG looking for is 'what we know about eachone of these solutions' but not recommendation is that it? Summary [david and interactions]
[22:53:21] <ggm> Rob: if we had WG consensus would be cool but we don't Ralph one vs many is a potential issue, but we don't have to worry. Rob: write down, don;t have to settle.
[22:54:36] <ggm> Otha. WKS approach is solution, but not mechanism. others are mechanisms. WKS is not discovery. clarify goal lastly, in last meeting, presentation on this, we know several problems, redundancy, provided by anycast, why I wrote draft. to have explanation of how anycast can NOT provide redundancy. if there is 5 minutes of time, I can present.
[22:58:00] <ggm> Dave: here is what I want to do. What IESG/ADs are asking for is pretty straightforward. charged with producing this doc by San DIego. otherwise this will not be work item for WG. I think thats what we can say. Bert (other AD) both ADs have been involved with WG chairs. all you said is correct. additional,. if this WG cannot deliver this document this WG is not going to work on it, but another WG can't work on the area either. either do it, even with recommendation and move forward quickly but if bogged down in should/shouldn't etc can't deliver, its not going to be done. if we don't know requirements. Dave: we need people to author or edit document. now step up and write part <x> Ohta: what is title David: don't care. want work. Dave: step up to write part <x> or work is not done. Itojun. not stepping up (!) discussed lot in V6 WG. should not waste results from there. could re-use some of their text. or results. from discussions over there Dave: framed the issue. interested. who in the room is interested in doing work to get document before IESG by San Diego>?
[22:59:13] <ggm> willing to do docu. ted. pekka. bob. paul [Rob] all volunteer
[23:00:08] --- sleinen has left
[23:00:14] <ggm> Hinden. unfair part is that one method has gone through. not all three equal
[23:00:22] <ggm> ROb: out of scope. not place to appeal
[23:00:31] <ggm> Bob (hinden) will talk to bert
[23:00:40] <ggm> Ralf. volunteer too
[23:00:50] --- jm has joined
[23:01:16] <ggm> at end of agenda. more?
[23:01:20] --- Gordon58 has joined
[23:01:39] <ggm> Ohta: want to present.
[23:01:44] <ggm> ggm: no second slot?
[23:01:55] <ggm> Rob: no. we reserved it, but no. we're done.
[23:02:53] <ggm> Ohta: drafy-ietf-dnsop-ohta-shared-root-server-03
[23:03:22] <ggm> have millions of roots.
[23:04:00] <ggm> updates. remove section on experiment add section on redundancy considerations. -confusion about expecting anycast to provide redundancy.
[23:04:59] <ggm> slide on anycast and some redundancy -shows risk of loss of service, when route still announced.
[23:05:19] <ggm> shows that with 2 anycast addrs, still get ability to see service when anycast route held up and service not there.
[23:07:02] <ggm> slide showing cannot have 2 anycast same address on same subnet. as for 2 unicast.
[23:08:41] <ggm> Rob: removing bit about experiment. wayback 5 years. had two different proposals for anycast roots. hardie-anycast and ohta-anycast. hardie went through, being used. disagreement with administrative issues in ohta-anycast. Q, point of Exp, was to find out if it worked. little suprised to see section removed. I thought the draft was here to write up the experiment. or overtaken by vents
[23:10:15] <ggm> Ohta. thought from beginning no problem, just work. I made almost no effort to perform exp. have not seen any dificulty. I think original statement confirmed, so I dropped it. but if you want to see result of experiment. Rob: write them down, see them. separate document? Ohta: possible
[23:12:08] <ggm> Pekka. can discuss 1-2 slides forward. (anycasy diag.) assume address properly of node, not process. Ohta: yes of course Pekka: but compare to multicast addr, property of process, not node. Ohta: multicast? Pekka: yes. process has address not node. I think you are assuming anycast addrs are configured on node, independant of process. if want to use anycast seriously we need api in application, so process can own anycast group
[23:13:27] <ggm> Ohta. anycast just works with current s/w. new API complex Rob: seen v4 anycast, in that case, the way done have separate i/f, loopback, assign anycast to that. process listens to that address. ad-hoc api. correct that server is listening to specific address. Ohta: process may hang Sam: routing withdrawn if process dies
[23:13:33] <ggm> Ohta done
[23:14:08] --- amarine has left
[23:14:16] <ggm> CLOSED. enjoy extra hour of freedom
[23:14:17] --- yone has left
[23:14:28] --- paf has left
[23:14:32] --- duidsaki has left
[23:14:33] --- Ralph has left: Disconnected
[23:14:42] --- mstjohns has left
[23:14:44] --- fneves has left
[23:19:56] --- ogud has left
[23:23:23] --- ggm has left
[23:25:04] --- dcrocker has left: Disconnected
[23:32:19] --- Gordon58 has left: Disconnected
[23:35:39] --- tomphelan has left
[23:46:52] --- jm has left: Disconnected