Folks,
Please look over these draft minutes and let us know if
there are corrections, additions or deletions.
We're also having a hard time identifying who said this:
@@@-who: On behalf of Morishta: he is trying to update draft, has had
no time, will do before San Diego.
so please let us know if you know/remember that.
Finally, note that the deadline for minutes submission is
Friday, April 2, 2004 at 17:00 ET, so please review and
get comments to us as soon as possible.
Thanks,
Rob and Dave
----
Domain Name System Operations (dnsop) Minutes -- IETF 59
Monday 03.01.2004 (1300-1500)
=============================
CHAIRS: David Meyer <[EMAIL PROTECTED]>
Rob Austein <[EMAIL PROTECTED]>
Minutes recorded by Ted Lemon <[EMAIL PROTECTED]>,
somewhat edited by chairs.
Agenda
------
o Administriva 5 minutes
- Mailing list: [EMAIL PROTECTED]
subscribe dnsop
- Scribe?
- Blue Sheets
o Agenda Bashing 5 minutes
o Status of WG Active Drafts 30 minutes
- draft-ietf-dnsop-dnssec-operational-practices-00.txt
Kolkman/Gieben 10 minutes
- draft-ietf-dnsop-ipv6-dns-issues-04.txt
Durand/Ihren/Savola 10 minutes
- draft-ietf-dnsop-misbehavior-against-aaaa-00.txt
Morishita/Jinmei 10 minutes
o Expired WG Drafts 10 minutes
- draft-ietf-dnsop-respsize 2 minutes
- draft-ietf-dnsop-bad-dns-res-01 2 minutes
- draft-ietf-dnsop-interim-signed-root 1 minutes
- draft-ietf-dnsop-inaddr-required 2 minutes
- draft-ietf-dnsop-serverid 1 minute
- draft-ietf-dnsop-ohta-shared-root-server 2 minutes
o Other Active Drafts 25 minutes
- draft-guette-dnsop-key-rollover-requirements-00.txt
Guette/Courtay 5 minutes
- draft-kato-dnsop-local-zones-00.txt
Kato/Vixie 15 minutes
- draft-yasuhiro-dnsop-increasing-dns-server-00.txt
Morishita 5 minutes
o Object Now or Never Drafts 5 minutes
- draft-warnicke-network-dns-resolution-02.txt 5 minutes
o Milestone Update 30 minutes
Austein/Meyer/All
Austein
Categories:
- IPv6 DNS Ops
- DNSSEC Ops
- ROOT/TLD/Other Systemic DNS ops
Minutes
-------
Agenda bashing...
We decided we don't really need the Tuesday session. So there
will be no Tuesday session.
Authors for some of the drafts aren't here.
===
Brief announcement (on behalf of Daniel Karrenberg, who was not
present):
There's a study in progress trying to measure what fraction of DNS
queries indicate support for EDNS0. This is a work in progress,
nothing final yet, but those who are interested might want to see
http://www.nlnetlabs.nl/downloads/edns0.pdf
===
draft-ietf-dnsop-dnssec-operational-practices-00
Rob Austein: This is the operational practices draft. Lots of
good response initially, nothing recently. We need to keep
pushing on this.
Pekka Savola: I stepped over this one because I received some
encouragement from that I should send some text so I revised it
twice. Since last revision no comments. From my perspective I
would like last call pretty soon; otherwise waiting for nothing.
Rob Austein: anybody think it's not ready for WGLC? Object now if we
shouldn't go to WGLC. [silence] Ok, will last call on the list.
===
draft-ietf-dnsop-misbehavior-against-aaaa-00
Jinmei Tatuya: significant change on this revision submitted
individual draft last June, based on comments we've revised this draft
as a wg document. Most of the changes are historical. My understanding
we are the core of this document is to publish as info rfc. In that
sense I believe ready for WGLC. Will need to remove appendix talking
about conflict examples (incomplete?).
Rob Austein: There is overlap between this and ipv6-dns-issues.
Make sense to keep them separate or to merge them?
Jinmei Tatuya: No particular opinion. In general it would be better to
merge two documents to single one. The less number of documents is
usually better. Would like to merge in that sense, but don't mind
either way.
Pekka Savola: ask at WGLC.
Itojun Hagino: I guess I like to see them produced as separate
documents because latter one talks mostly about existing ipv4
misbehavior over existing ipv4 dns servers while former talks about
slightly different issues.
===
draft-ietf-dnsop-bad-dns-res-01
Piet Barber: recently put in dnsop-bad-res draft just before
deadline. I ask for any comments people have - it hasn't been
brought up on the list. No comments other than from Rob
Austein, eagerly awaiting more.
Rob Austein: how many have read? ... Not enough. This was a
pretty good document a year or two ago, got kind of stale, would
like to get it out while it's still fresh this time.
Piet Barber: I've added several more annoying things we've seen
on root server. Lot more opportunity for misconfiguration which
we see a lot more in com (common?) net. If you have operational
experience with DNS, please get back to us.
Rob Austein: My preference would be to give people time to read
this, but try to do WGLC before San Diego. Anybody think that's
nuts? [no audible response]
==
[Pseudo-draft on resolver API, URL posted to namedroppers]
David Meyer: dnsop-resolver-app-interface - not actually an internet
draft, just posted on a web site. Topic they're trying to bring up is
one we ought to be discussing. Document is not anywhere near ready -
straw proposal. Not sure it's the right way. We do need to think about
semantics of interesting error cases we have, can't just use SRVFAIL
and weird bits to indicate errors.
Sam Weiler: Don't bother reading it - just write something else.
===
draft-ietf-dnsop-ohta-shared-root-server-03
Ohta-san: update is on the mobile [???] or section about
experiment. Just an update this addition to clarify how redundancy can
be achieved with anycast/multicast. There is some modification, want
discussion here or on mailing list about this.
===
draft-warnicke-network-dns-resolution-02
David Meyer: Anybody have comments on warnicke-network-dns-resolution?
How many have read it? You have to read it to comment.
Rob Austein: If there is something really seriously wrong with this,
we need to tell the IESG to tell RFC editor that it should not be
published; otherwise we should leave it alone.
Pekka Savola: I have objections, but based on that classification
it's probably not that serious.
Rob Austein: draft has been in front of wg before, declined to
touch it, went individual path, we're being asked again.
===
draft-ietf-dnsop-respsize
Rob Austein: Plan was to have new version. Dog ate homework. Authors
promised version in time for San Diego after dog incident.
===
draft-ietf-dnsop-interim-signed-root
Has this draft been overtaken by events? [silence]
===
draft-ietf-dnsop-inaddr-required
Any comments? Do we want to bring this back?
Itojun Hagino - I think I have seen more operational troubles
with ipv6 case reverse lookup case. Lack of IPv6 reverse lookup
causes connection delays on stuff so I'd really like to see this
published.
Rob Austein: remember, this is the one where the title is
misleading - this is just considerations for whether to populate
reverse tree, etc. Last time it came up wg insisted it was
important, but didn't get traction on doing it.
Will somebody write text? Author has been pelted with rotten tomatoes
so many times doesn't want to do it anymore. [This turned out to be
incorrect, author is still willing, see discussion on mailing list.]
Itojun Hagino: I'll do it!
===
draft-ietf-dnsop-serverid
David Meyer: Suzanne Woolf has graciously...
Rob Austein: The ISC dog ate this homework too. If the update of this
had come out, it would have backed down on proposal for new
conventions that aren't in shipping software and mostly just
documented existing hacks in existing software. The hack we have now
is that some name server implementations have a magic query you can
send that identifies the server. It's a kludge, the only advantage is
that it's in the field. It's not really right for debugging things
like anycast, because if anycast is flapping, there's no guarantee
that the query goes the right place. Only way to solve that for real
is a protocol extension that gives a mechanism for saying "server,
please identify yourself" in the original query.
I have put together a straw proposal for how to do this as an
individual draft which probably goes to DNSEXT. Motivation is still
waiting for Suzanne's revision of draft-ietf-dnsop-serverid.
===
draft-guette-dnsop-key-rollover-requirements-00 has turned into
draft-ietf-dnsop-key-rollover-requirements-00
Masen Tuci from apnic - dnsop key rollover requirement?
David Meyer: this isn't a wg draft.
Rob Austein: changed names.
Masen Tuci: accepted last IETF meeting, adopted by WG, authors
submitted new version, asked for comments, didn't have any.
Rob Austein: is new version identical to previous?
Masen Tuci: I guess there were some clarifications and minor
modifications.
David Meyer: has anybody read that one?
Masen Tuci: may I relay author's comment? Please read it and send
comments!
===
draft-kato-dnsop-local-zones-00
Kato-san: sorry , have no time to update, objective trying to
write something new by next Sunday meeting.
===
draft-yasuhiro-dnsop-increasing-dns-server-00
David Meyer: has anybody read this?
@@@-who: On behalf of Morishta: he is trying to update draft, has had
no time, will do before San Diego.
David Meyer: When we are notified of that...?
===
Chairs: Ok, that was our list of drafts, what have we missed?
Pekka Savola: don't recall seeing v6 transport guidelines.
[draft-ietf-dnsop-ipv6-transport-guidelines-01]
Rob Austein: Oops. That one already passed WGLC, it's waiting for
some stupid thing. Thanks for reminder.
Pekka Savola: I think it's high-priority work.
Rob Austein: Should have been out a year ago, we (the working
group chairs) blew it.
===
Charter discussion:
David Meyer: We're in the process of updating our charter. That
process is going fairly smoothly. I wanted to let folks know where
we're at. As you know, charter on website was outdated. We have a few
issues that are critical to new charter.
1. DNS Discovery.
2. IPv6 DNSOPS
3. DNSSEC Ops
4. ROOT?TLD/Other Systemic DNS ops.
===
DNS Discovery
The issue here was we've gone around this issue more or less
endlessly. In discussing it with our area directors, they asked us to
write an issues document that describes what the issues are with the
three approaches. Have that ready. Goal is to have it ready to submit
to IESG as informational document by the San Diego IETF. So we're on a
short leash. We've been informed that if we don't complete this work
by that time, the DNS Discovery milestone will be removed from our
charter.
Rob Austein: Point is we've been having this circular discussion,
apparently we can't get consensus. So the idea is to write down the
arguments in coherent form so that people can read them. I'm not sure
we can settle it, but at least get them written down so people who
have not been involved can form their own conclusions.
David Meyer: So to that end we really need to solicit folks who want
to work on this, to be authors and/or editors. Unless we hit the
ground running, it's going to be challenging to have doc ready for
IESG by next IETF. I know that Jaehoon Paul Jeong has a five minute
presentation on this, we can do that now if we like.
Rob Austein: Before we get to that, any other discussion on any other
drafts? [silence] Ok, we're done with everything but DNS Discovery.
David Meyer: This is an issue we really need to solve, let's get
five minutes from Paul.
Jaehoon Paul Jeong: hello everyone. I will talk about DNS
Discovery issues. DNSOP decided to produce a document outlining
the attributes of the three DNS discovery approaches. Document of
DNS discovery will describe the problems and issues with DNS
discovery. etc.
First alternative is RA option. This draft has been burst by four
authors. First solution is RA DNS server option. Second is DHCP
option. Stateless or stateful.
Last approach - well known anycase address. Can be pre-configured in
IPv6 host.
Ordering between RA and DHCP option - M & O messages can be used to
take order between two options. However, in this point, I don't know
how to fly anycast with other solutions. Three options - WKA as last
resort, when IPv6 host cannot get DNS server info through RA and DHCP.
Second option - IPv6 host can configure WKA as the most preferable in
its conf file.
Last, can get explicit fact that WKA for DNS can be used in the
site through RA Hint Option. Hint says WKA can be used. Can be
implemented by RA DNS Server Option with knew flag.
I think we should resolve this in this meeting, we have a short
time to do this document. Need input and comments.
Ohta-san: I think your understanding about mobile scenario has some
misunderstanding. There is no requirement that all the mobile
operators must provide DNS servers, which means if you don't have DNS
servers at home, then if you sometimes lose access to DNS servers
because no local available, that's not a very good environment. So
with mobile environ ent one should have his own DNS server at
home. Because mobile host needs some configuration about home such as
home network address, it is not unreasonable requirement home dns
server address should also be configuration. Mobile node must be
somehow configured. So mobile environment should be dropped.
Jaehoon Paul Jeong: when we use mobile server, time can be optimized.
Ralph Droms: THe description you gave here brings up a thought about
document Rob Austein talking about. Before authors dive in, ought to
frame amount of discussion that goes into it. Every time we bring up
here, has gone on to absorb all available space. So as a bit of
advice, perhaps somehow this has to be limited in frame.
Rob Austein: I'm not sure either. One bit of advice I got from old
IETF person is that, even if we are not going to get to the point
where everybody agrees, we might get to the point where document
describes issues enough that everybody can say "yes, that represents
my position fairly, I think I understand the other positions also,
even though I don't agree." Having watched Paul's (Jaehoon Paul Jeong)
presentation, my initial reaction to it is it's a very good way of
looking at it if we were trying to do all these things at once.
Unfortunately, the WG has no consensus on that. Not going to be able
to settle this in the document - just write it down fairly.
Ralph Droms: We hadn't talked about which comes first, which comes
second. Do we want to try to frame it to tightly describing
alternatives individually, or describe ways they could interact? It
seems like a real rat hole.
David Meyer: My sense of what this document's supposed to do is solve
the problem less than Paul's (Jaehoon Paul Jeong) presentation did.
Describe technical attributes, etc. Describe disadvantages of not
doing them. Qualitatively different than trying to solve the problem.
Rob Austein: We have our AD here. Is this what we're looking for?
David Kessens: It's correct and also the last part we'd like to know
about possible interactions if there are multiple solutions. Document
what the interactions would be. What would need to be coordinated.
Bob Hinden: Good proposal - one way to move ahead. Not sure what
happens after neutral draft is done. Clearly proposal for RA
option, have DHCP, what happens next?
David Kessens: We don't know yet. We will study the document, and
look at it, and see what risks are of doing multiple solutions,
make informed decision.
Bob Hinden: Written to advise IESG?
David (Kessens?): We hope to be able to get something out of this.
Rob Austein: This group was never going to do protocol work anyway -
just try to figure out which way to go. It's possible that we won't be
able to make a recommendation. This seems like the most profitable
thing to do.
Ralph Droms: Can you give us a little more explanation of the WKA
hints option? Why not just send WKA?
Jaehoon Paul Jeong: Indicates that WKA can be used. Without this
option, we assume that address line have addresses of DNS server,
however hint option we can explicitly indicate that WKA have been
deployed. However, this is my suggestion, Ohta-san can suggest
another way. This is my private opinion.
Ralph Droms: So independent of specific WKAs? What's different
between sending WKA and WKA bit?
Jaehoon Paul Jeong: This option is just an indicator - RA option
doesn't contain addresses.
Bob Hinden: One thought on how we might proceed. I won't say it
if you don't want me to.
David Meyer: We're working on a charge from our ADs.
Bob Hinden: I'm trying to be polite and constructive. Making big fuss
over a lot I don't understand. It seems like go ahead with DHCP-lite,
RA looks straightforward. Didn't see any big technical issues. WKA
clearly has issues but strikes me that it's really WKA not just for
DNS but for a range of servers and as such needs to get discussed in
WG with broader scope - discovery of services. Trying to be
constructive, suggest we have DHCP, send RA option to IPv6 WG, then
ask IESG to find a new home for the WKA approach.
Rob Austein: Our problem is picking one. If we want multiple
mechanisms that's fine, but we can't even agree on that.
David Meyer: There's a similar situation that started in routing
area, to do a similar thing, write a document that described
choices between alternatives and their technical attributes.
David Kessens: We would like to have the input of this WG about DNS
matters. Current thinking has been that some of the knowledge
regarding this stuff has been lacking in some of the WGs, although
they could already start on RA option. Would like document to see
what issues are. Even if we decide to go ahead with multiple
solutions, want to know issues. We know this has been going on a long
time, decided we need a deadline.
Ralph Droms: I think I'm hearing a clarification, which is what
the IESG is looking for is what we know about each of these
solutions, but not a recommendation of one versus multiple. Just
taken individually, here's what happens with each.
Rob Austein: If we'd gotten to the point where we could have made a
recommendation with consensus, that would have been cool.
Ohta-san: Comment: WKA approach is a solution, but is not a mechanism.
WKA is by no means discovery. So we should clarify our goal. In last
meeting you made presentation that WKA has several problems based on
wrong understandings - redundancy provided by anycast. Which is why I
modified new draft. It would be good if there is five minutes of
presentation time allocated this week about lack of redundancy of
anycast.
David Meyer: I think that what the IESG is asking us for is pretty
straightforward, and we have been charged with constructing this
document, getting it before IESG by San Diego IETF. So I think that's
what we can say. Parameterization (???) of that.
Bert Wijnen: Both ADS have been involved. All that you said is
correct, with one additional statement: if this WG can't deliver this
document, then this WG is not going to work on it. No other WG will
either. If you're gonna get bogged down in whether you should or
should not do recommendation, if you can't deliver document, we're
just not going to do the work.
David Meyer: So that being said, we need author/editor.
Ohta-san: What is title of document?
Rob Austein: We'll drive off that bridge later.
David Meyer: People have to step up.
Itojun Hagino: I am not step up for writing it. This issue has
been discussed for long time, so we shouldn't waste the result
from there. Could reuse some of the results from discussion over
there.
David Meyer: Who is interested in doing the work that needs to be
done to get document?
Ted Lemon: I can help with.
Ohta-san: Section about WKA.
Pekka Savola: Volunteering.
Jaehoon Paul Jeong: Volunteering.
Rob Austein: Everybody who's signing up is agreeing to work with
editors.
Bob Hinden: Unless this is successful, no further work chartered in
this are. Part of that that bothers me is that the IESG has already
let one of these solutions go through, so by not doing anything, it
picks the outcome by not making progress.
Rob Austein: This is not the place to appeal an IESG decision.
Ralph Droms: I was going to explain why I was shaking my head,
but it's out of scope. I'll volunteer to work on DHCPv6 sections.
===
David Meyer: That's the end of our end of agenda.
Ohta-san: can I make another presentation on WKA?
Editor's note: Ohta-san's made his presentation here.
Rob Austein: my recollection from five years ago is that we had
two proposals for anycast root servers, hardy and ohta. hardy was
non contentious, went through, is being used. I'm surprised to see
section on experiment removed. What happened to that?
Ohta-san: I made almost no effort to do experiments, but my
original belief was confirmed. If you want something about
experiment I can.
Rob Austein: It'd be useful to write down the results.
Ohta-san: Should I write it?
Rob Austein: Yes, please.
Pekka Savola: One comment/clarification. You are making assumption
that anycast address is property of node, not process. I think if
we want to use anycast seriously we would have to have api that
application would join some anycast group, if process dies, anycast
membership is relinquished. The table is still there if process is
buggy. Probably needed for serious use of anycast.
Rob Austein: I've actually seen how at least one of the anycast root
servers does its implementation of this. In that case the way they're
doing it is they have a separate interface. Process listens to that
address. You're correct that at least in that case the server is
listening to a specific address.
Ohta-san: a process may hang.
.
dnsop resources:_____________________________________________________
web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html
mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html
