Last Modified: 2005-06-27
| Done | Forward NSEC rdata to IESG for Proposed Standard | |
| Done | Forward RFC2535-bis to IESG for proposed standard | |
| Done | Forward Case Insensitive to IESG for Proposed Standard | |
| Done | Forward LLMNR to IESG for Proposed Standard | |
| Feb 05 | Update boilerplate text on OPT-IN | |
| Feb 05 | Submit KEY algorithm documents RFC253[69]bis and RFC3110 to IESG for proposed standard | |
| Mar 05 | Finalize Zone Enumeration Requirements | |
| Mar 05 | Forward Wildcard clarification to IESG for proposed standard | |
| Apr 05 | Start of process of reviewing the following RFCs and to move them to Draft Standard status | |
| May 05 | Submit to IESG RFC2845 (TSIG)to Draft standard | |
| Jun 05 | RFC2671 (EDNS0) to Draft Standard | |
| Jun 05 | RFC2672 (DNAME) to Draft Standard or revision | |
| Jul 05 | RFC2136 (Dynamic Update) to Draft Standard | |
| Jul 05 | RFC3007 (Secure Update) to Draft Standard | |
| Jul 05 | RFC1995 (IXFR) to Draft standard | |
| Jul 05 | RFC1996 (Notify) to Draft Standard | |
| Sep 05 | RFC2930 (TKEY) to Draft standard | |
| Sep 05 | RFC2181 (Clarify) to Draft Standard | |
| Sep 05 | RFC2308 (Neg Caching) to Draft Standard | |
| Nov 05 | RFC2782 (SRV RR) to Draft Standard | |
| Nov 05 | RFC1982 (Serial Number Arithmetic) | |
| Nov 05 | RFC2538 (CERT RR) to Draft Standard | |
| Nov 05 | FRC2539 (DH Key RR) to Draft Standard | |
| Nov 05 | RFC3226 (Message Size) to Draft Standard |
| RFC | Status | Title |
|---|---|---|
| RFC2782 | PS | A DNS RR for specifying the location of services (DNS SRV) |
| RFC2845 | Standard | Secret Key Transaction Authentication for DNS (TSIG) |
| RFC2929 | BCP | Domain Name System (DNS) IANA Considerations |
| RFC2930 | PS | Secret Key Establishment for DNS (TKEY RR) |
| RFC2931 | PS | DNS Request and Transaction Signatures ( SIG(0)s ) |
| RFC3007 | PS | Secure Domain Name System (DNS) Dynamic Update |
| RFC3008 | PS | Domain Name System Security (DNSSEC) Signing Authority |
| RFC3090 | PS | DNS Security Extension Clarification on Zone Status |
| RFC3110 | PS | RSA/SHA-1 SIGs and RSA KEYs in the Domain Name System (DNS) |
| RFC3123 | E | A DNS RR Type for Lists of Address Prefixes (APL RR) |
| RFC3197 | I | Applicability Statement for DNS MIB Extensions |
| RFC3225 | PS | Indicating Resolver Support of DNSSEC |
| RFC3226 | PS | DNSSEC and IPv6 A6 aware server/resolver message size requirements |
| RFC3363 | I | Representing IPv6 addresses in DNS |
| RFC3364 | I | Tradeoffs in DNS support for IPv6 |
| RFC3425 | PS | Obsoleting IQUERY |
| RFC3445 | PS | Limiting the Scope of the KEY Resource Record out |
| RFC3596 | Standard | DNS Extensions to support IP version 6 |
| RFC3597 | PS | Handling of Unknown DNS Resource Record (RR) Types |
| RFC3645 | Standard | GSS Algorithm for TSIG (GSS-TSIG) |
| RFC3655 | Standard | Redefinition of DNS AD bit |
| RFC3658 | Standard | Delegation Signer Resource Record |
| RFC3755 | Standard | Legacy Resolver Compatibility for Delegation Signer |
| RFC3757 | Standard | KEY RR Secure Entry Point Flag |
| RFC3833 | I | Threat Analysis Of The Domain Name System |
| RFC3845 | Standard | DNSSEC NSEC RDATA Format |
| RFC4033 | Standard | DNS Security Introduction and Requirements |
| RFC4034 | Standard | Resource Records for the DNS Security Extensions |
| RFC4035 | Standard | Protocol Modifications for the DNS Security Extensions |
|
Minutes of the DNSEXT working group 63rd IETF, Paris, France August 3rd 2005 Chairs: Olafur Gudmundsson Olaf Kolkman Scribes: Jelte Jansen (minutes) Wes Griffin (jabber) Previous Minutes ================ There were no comments on the previous minutes. Agenda Bashing ============== There were no comments on the agenda. Documents ========= The documents are handled in a last-call order. Documents that are past last call: draft-ietf-dnsext-mdns-41: waiting for the chairs to go over the document to see if all changes have been made. draft-ietf-dnsext-tsig-sha-04: waiting for a chair to make a summary for the area director. draft-ietf-dnsext-wcard-clarify-08: chair will write summary and submit the document. draft-ietf-dnsext-rfc2538bis-03: exact current state unknown, but it should be close to standard now. Documents in last call: draft-ietf-dnsext-dns-name-p-s-00 and draft-ietf-dnsext-dnssec-online-signing Olaf is not sure what status these documents will need to get, experimental, informational or standards track. There seems to be little interest for these documents, at least on public channels. Peter Koch: DENIC would like to see an implementation for this. They are still evaluating, but this is definitely on their path to DNSSEC. He is not sure that experimental is appropriate, since it modifies the protocol. Olaf: there won't be any difference on the wire, in the way that packets are built. And if the consensus is to put it on the standards track, this discussion would become irrelevant. Olaf asks the working group to heed the last call and look at the documents. draft-ietf-dnsext-dnssec-trans-02: the authors would like another round before last call. Documents close to last call: draft-ietf-dnsext-experiments-01: will be in last call in September. The DNSKEY algorithm documents are all ready for last call, last call will start soon (draft-ietf-dnsext-rfc2536bis-dsa-06, draft-ietf-dnsext-rfc2539bis-dhk-06 and draft-ietf-dnsext-ecc-key-07). Ongoing work: draft-ietf-dnsext-dnssec-bis-updates-01: Olaf asks the working group to send anything of notice (implementors, readers who see weird language, etc.) in the DNSSEC docs to Sam Weiler, so it can be included. draft-ietf-dnsext-nsec3-02: there is a new version of this document. Olaf Kolkman wants at least one workshop with running code before advancing this document, between now and the IETF in Vancouver. Olaf Kolkman mentions that old and expired documents can be found on http://tools.ietf.org/wg/dnsext Update on NSEC3 =============== Roy Arends reports that most of the changes in the document are textual. There is still some uncertainty on whether truncating hashes is a good idea. Now the documents allows for a signal that hashes are truncated. There are some clarifications on dos issues, and an example has been included. They are waiting for -trans and -ter to stabilize before specifying the way to indicate NSEC3 is used. The next version of the document will address rolling NSEC to NSEC3. Some tools have been implemented: an NSEC3-capable signer, based on Net::DNS(::SEC), and a NSEC3-capable server for testing corner cases. There should also be NSEC2 patches for bind, but we'll see that on the list. Mark Kosters: we plan to have nsec3-capable servers before the workshop. Miek Gieben asked why include opt-in? Roy still thinks technically there's nothing wrong with it. OPT-IN would have stopped progress on last docs, now time is right. There was some further discussion if NSEC3 and OPT-IN are separative and/or required. Chair made the comment that if Opt-In feature is removed from NSEC3 then that requires changing the name to NSEC4. A large operator commented that they will not deploy DNSSEC without opt-in for number of operational reasons including significant churn of names. Rob and chairs appeals to room: please review the old discussion on OPT-IN. IPR Issues update ================= Olafur reports that there are two different drafts to manage trust anchors: draft-ietf-dnsext-trustupdate-timers-00 and draft-ietf-dnsext-trustupdate-threshold-00 Both documents have had an IPR claim filed against them. The patent this has been issued in one country at the moment (Israel) but filed in some other countries as well, just not approved (yet). There is a license available that is royalty free, but does have some terms. So implementors either don't know what to do or are ignoring it. Automatic Updates of DNSSEC trust anchors ========================================= Olafur Gudmundsson reports that having no key management standard might become the next excuse for not deploying DNSSEC. Early adaptors may need to bear additional costs configuring trust anchors. The need for configured trust anchors will never disappear, in the best case it might be reduced to only one anchor, the root. Olafur pleas to the working group for more activity here. Authors are frustrated with the complete silence on this issue, they cannot continue until there is discussion, feedback, a list of selection criteria and a time line. Bill Manning: I see silence as consent, and the document should go to last call. Mike StJohns: Well the problem is that there are two documents that met with silence, so my document was approved-by-silence too. Olaf Kolkman: the working group decided once that there should only be one solution. On the other hand these documents do not exclude each other, one is purely operational. Mike StJohns: I disagree, both change resolver behavior. Mark Andrews: We definitely need to decide on one or the other, because it will have impact on how operators do their key management. I do not want to try managing both. Sam Weiler: I'm not sure if we have to make a choice, is there any harm in a resolver not following these drafts? Mike StJohns: by ignoring the timer bit the trust anchors won't be updated and things go stale. Olafur: and in the case of 2 mechanisms there should be signalling for zones to declare which method they use. Mark Andrews: Well something has to notice keys are changing, not necessarily resolvers, so they don't have to change. It could be an external tool. Russ Mundy: My understanding is that the mechanism should not prevent other mechanisms to update keys. Olafur: Yes, this is just a way for validator to do it in-band. Mike: if you have a mechanism people will not pay as much attention, and those who don't will fall behind. Russ: but it was not intended to be an exclusive mechanism. Mike: If operators are making different choices a signalling mechanism becomes interesting. Sam Weiler: I was hearing this 'you have to have a signaling mechanism' as 'you have to have one in-band', which suggests to me that you have to have one whether you use one of these schemes or none at all. If we can get away with saying it's all out of band when you first configure a trust anchor you say which method you're using, then the proposals are not mutually exclusive. Mike: A problem is, the trust anchor may or may not do automatic rollover, but you don't know when you configure your server. Olaf: The keying policy needs to be known. Mike: The policy will be decided by the one that ships the software. Most people will ignore it, do whatever works. Rip Loomis: I have read both drafts, and could not decide on one. Could the authors make statements why their solution is the better one? Or if someone thinks we can do both, please say that. Another point: even if you have auto-rekey, there should still be a methodology to do it manually. Sam Weiler: I heard Mike wants to be able to use schemes with already configures trust anchors. Mike: Well anything we can do to off load operator load on end-users will improve deployment. Like web browser certificates. Olaf: I think we all agree that we don't want people going back to their configuration and changing things all the time. Rip Loomis: I would like a 1 paragraph statement (or abstracts or differences) about the drafts from the authors on the list. Bill Manning: I would like someone unbiased and not involved in these documents to write a short document with abstracts and differences Jim Cassels is volunteered to do this. He agrees. Action point: Jim Cassels will write a short document on the differences between the two automated key rollover drafts. Rob Austein: Could we have a verbal summary now? Wes Hardaker: If i look at other protocols with keys, the ones without automatic key rollover get deployed, but the keys just never change. They are not rolled at all or their lifetimes are exceptionally long. Olaf: We could say we use very short lifetimes, so the operators will get bitten quickly. That's the other way to get keys changed. Wes: Only if you document that in advance in a protocol, otherwise users will do whatever they want. Olafur Summarizes the two drafts, and asks if people have feelings about either one. Mike: the revoke solution deals explicitly with key compromise, not operational errors. Rob Austein (directed to Olaf Kolkman): you recently did tests on bandwidth usage with DNSSEC. Does the n out of m proposal have a lot of impact on servers in that way? Olaf: currently there is an implementation that sends the key in the additional section of the answer packet. With that implementation, it would have a lot of impact. Apart from that, it is an orthogonal question. Only relevant if the DNSKEY RRset lives in the answer or authority section of the packet, because then we'll get truncation issues. We should try to keep the packet sizes below 2048 bits, because that's what i see on the wire now. Olafur shows an old spreadsheet that shows DNSKEY packet sizes for different algorithms with different numbers of keys.
Assuming: domain: ogud.com
Assuming: always a rollover in progress for both KSK and ZSK
Assuming: 2-3 threshold
Assuming: RSA KEYS ZSK: 768 bits KSK: 1536 and all keys sign DNSKEY set
Timers Proposal has 2 KSK and 2 ZSK:
DNSKEY RRset is 1365 bytes on the wire (assuming name compression)
Threshold Proposal: has 3 KSK and 2 ZSK
DNSKEY RRset is 1788 bytes.
There was some discussion on the minimum number of each type of key and one person voiced some concerns that n-of-m mechanism DNSKEY set was worrying large. There was also a comment that ECC keys are much smaller for same strength so that might be part of the solution. Miek Gieben: Back to the proposals. I don't like the revoke bit, if you leave it out of that proposal, then the m out of n stuff seems an implementation of the other proposal without the revoke bit. Mike StJohns: No, the revoke bit helps you maintain coherence. The other proposal has a lot of ways to make mistakes operationally. There's a lot of interesting problems with respect to how you do the stuff. Miek: From what I understand now, you can even combine the two into one thing. Do them both at the same time. Mike: Well it seems that the minimum number of keys is 2, and it can't actually be lower without losing the compromise protection. Sam Weiler: I like the idea of having a revocation mechanism, but I'm a little bit worried about this one. If a resolver that does not know about the revoke bit gets a key that has that bit set, can it still use that key for validation? If so, we may want to look at a different signalling mechanism, and I would suggest that the working group is about to last call a draft written by mister Blacka, which suggests one, which could also be signalling which mechanism is in use. Mike: There is specific language in the document about how the revoke bit does not make it any worse than without it. Sam: I think it might be, because with the revoke bit, you might keep a key published for longer that you otherwise might. Olaf: Changing the revoke bit changes the key, as soon as you swap it you change the key, and the validator does not recognize it as the same key any more. Johan Ihren: First, about packet size. The assumption was that with 4K packet size, we would be safe. With 2K i do not know. We need to look at that further. As regards to the ability to get rid of all trust anchors by mistake, however, DNS is a lot of rope, if people want to shoot themselves in the foot, they can easily do that already, without DNSSEC. DNSSEC just gives them more rope. So in my opinion, the real task here is to find a mechanism that makes it viable to deploy it large-scale, so that it'll actually work on the full Internet. That we'll need software development to make that work without mistakes is kind of clear. If someone chooses to go around software tools that cater towards avoiding mistakes, and makes changes manually, than that person will be in for a bumpy ride regardless. Olaf: On 4K and 2K limits. (shows screen with statistics about packets on reverse zones). You essentially only see 2048 and 4096 advertised as the size clients can handle. 2048 is a significant proportion of that, and so we have to consider it as something the DNSKEY and signatures have to fit in. Rob Austein: We once looked at a proposal that had revocation, and we dropped it because it was too difficult to make it work. The people that got the revocation signal were the people that did not need it. Here, with key id's changing because of the revocation bit, i think we might be okay. Given that, revocation seems at least somewhat useful to me, I don't think it really changes the PKI-ness of DNSSEC. Last comment: I don't really have a strong feeling yet, but i'm leaning more towards the proposal of Mike at the moment. Olaf: Let's have a show of hands. * Who wouldn't mind if we go in the direction of the StJohns document, with revocation, which means resolver updates? Couple of hands. * Who wouldn't mind if we go in the other direction? Again, couple of hands. * Does anyone have a strong preference for either one? Not really. Olaf: I think we need to do this on the list. Jim Cassel, you have an action point. I think we need to decide on this before next meeting in Vancouver. Olafur: Minor point. both documents are expired now. We can either ask the authors to submit a new version or I can ask the area director to have them revived in current state. Mike StJohns: We can't just resubmit it because the boiler plate keeps changing underneath us. If you can get it revived, please do. If not, please let us know and I'm marginally willing to do it. Johan Ihren:I'll submit a new version. NSID ==== Rob Austein reports about a proposal that is not yet a working group item: the NSID proposal. This came out of the work in the dnsop working group, where Rob is co-chair, so he can't author there. There are repeated requests for a standard way to identify the server that gave an answer. Especially in anycast settings where different queries can be answered by different servers this could be very helpful for debugging. The current ad-hoc way uses a separate query in the CHAOS class, and there were effort to make a standard out of this. But those efforts got stuck, and that's were it's been at for a couple of years. Last year we revived that draft, changing the recommendation so that it is no longer an extension of the CHAOS class TXT record hack, and basically the draft was a problem statement, and a description of the existing mechanisms that have already been deployed. That called for a solution, maybe at another group, possibly a protocol extension, that would solve the problem. That's what this draft is supposed to be. It's a very simple mechanism, it's in EDNS, because that's the only place we can put extensions in anymore. There's a flag bit in which you can state in a query: "oh by the way, could you please identify yourself, server", and there's an EDNS option field in which the server can reply, stating what it's identity is. Identity is very carefully left undefined, that's one of the changes since last round. The two open issues from when I presented this last year are: * What should the payload of the response be? It could be the real name, or the real address. There are security issues. So i asked around about this and the feedback i got was, can we please just make it an arbitrary string. So it's basically becomes a cookie that the server operator can use for debugging. The main point of using a protocol extension instead of a separate query is that quick routing changes might change the server your second query goes to. You have to be able to add it in the packet. * Whether or not recursive nameservers can play too. The original request only had to do with authoritative nameservers, but there's no real reason not to do this with recursive nameservers and we know that there are anycast setups with recursive nameservers too. The mechanism is quite explicitly defined as not being transitive. So the bit means 'server I sent this packet to, please identify yourself", so it applies equally well to recursive nameservers. The question is: should it? My personal opinion is that it should, no one argued with me, I did not get a lot of feedback on this one, so I left it like that for the moment. The requirements document is in last call at dnsop, but it got hung up there, long story. So the question is do we want to make a working group item of this, and do we want to wait for the requirements, assuming they ever appear. During discussion there was strong preference shown for getting this document done soon. People like this mechanism, and in particular the fact the string is just an simple identifier that can be set to any value. There was a question about support for recursive queries of NSID, but that issue is not addressed and will not be addressed until after this is done. Document was adopted as WG item and milestone to be added that the WG process to document before next meeting. DNS IANA Considerations ======================= Donald Eastlake presents some drafts about cryptographic algorithms. First something about draft-ietf-dnsext-ecc-key-07: There have been some questions in the past about patents, but as far as is known, these only cover specific implementations, not on the basic theory or scheme of it, perhaps on specific equations. Algorithm number 4 has always been reserved for ECC, and this draft proposes a specific format for ECC keys and signatures in the DNS. People need to read it and comment on it. Olafur: The chairs would like this to hit last call soon, and it would be great if someone can implement it, and can comment on how useful it is. We have been getting statements from cryptographers that ECC's are really good, and that signature and key sizes are significantly smaller than RSA. So it is a very interesting addition, so any technical feedback would be great. Back to IANA considerations: draft-eastlake-dnsext-2929bis-01. Donald Eastlake reports that rfc2929 was the first IANA considerations document for RR types, classes, rcodes, opcodes, header bits, et cetera. It provided some private numbers, depending on how numerous the particular item was, some publication required, and a few higher level IETF consensus or standards actions. What people are mostly interested in was RR types. It defines thing for the other numbers too, but people are mostly worried about the ease or difficulty of getting new RR types. Publication required was supposed to be pretty easy, but it appears that no RR type has ever been allocated based on the provision of publicly available publication. There was a discussion on the list, and there is a mechanism in rfc4020, called "Early Allocation". If something is going to be a standards track parameter, and there's working group consensus, and some other things, then you can get a temporary early allocation of an IANA parameter value. It's supposed to last a year, and then you have to request renewal, if it hasn't progressed to the point where it's in a standards track draft. The discussion on the left was that it was still too strict. For instance there were things that were heading for experimental, there were competing proposals. The early allocation seems to only apply on single proposals that are known to become standard, were early allocation is only there to make things more convenient, but people wanted something more loose than that. So this draft tries to do things easier, and wrote 2929bis. The main effect is to try to make things more liberal. In many cases it replaces what used to say "IETF consensus" with "DNS special allocation policy", and there's a part in the document which defines what this allocation policy is. There are also some other little things in the document, some things about AFSDB, a specification required subset of values for RCODE, and other minor changes, some updates to rfc references. The "DNS special allocation policy" is like rfc4020, but with looser requirements. What it currently says is one of: * Standards action * Approval of something as experimental * Temporary allocation like in rfc4020, but with looser criteria, you need a draft that describes it, and approval by a working group chair and area director, or by two area directors if it's an individual draft. One of the discussion was about the perpetually of the working groups and mailing lists. This draft did assume that the namedroppers mailing list will be perpetual, and it defines a template to request a number. The template is not yet fully defined, this still needs some discussion, but it's similar to registering new mime types. Thomas Narten: What problem are we trying to fix here? People overload the TXT record for a lot of reasons, and only one of them is IETF consensus for getting an RR type. Donald Eastlake: I believe that 100 percent, but this is aimed only at that one problem. Rob Austein: But you're changing RCODE allocation too. Donald: Well if you're making changes anyway, I thought i might include that too, since there were just plain oversights in rfc2929 i think. But then again, if the working group think that this should just be about RR types, then I'll only talk about RR types. Thomas Narten: rfc4020 is really not appropriate for this kind of thing. it was meant for the routing group where they wanted to get code points assigned while they were still drafts before they popped out of the working group. In the case of resource records, a good number of the proposed RR types don't come to the dns extensions working group, because they have nothing to do with dns extensions charter. They're really for some application that wants to use the DNS. My belief is that the role of this working group, with regard to reviewing proposed RR types, is to basically make sure that the definition is specified enough, that is does not cause the DNS system to crash if the size is too big, or cause operational problems and so forth, but not so much about the semantics of what's inside the type. Olaf Kolkman: That's actually the direction this working group is taking. We try to look at the DNS merits of the whole thing and don't make any statements about what the protocol is actually doing. People just need a code point to get stuff on the wire to do experiments, so they can go on. Thomas Marten: Okay. Something else: given that the RR types we have 16 bits, why are we worried about reclaiming unused allocations? Then why are they temporary? Why are we bothering? Donald: Well I got that from the list, people were saying 'why can't people just get these temporarily?'. Margaret Wasserman: I don't know that they have to be temporarily allocated, but if you're going allocate code points based only on ID's you're going to have operational problems if those ID's are going to cease to exist or change fundamentally, and someone sees a code in their configuration file and there's no reasonable pointer for them to figure out what they are supposed to mean. Olaf: I think that was the point of making them temporary. Margaret: But taking them expire from IANA does not remove them from the configuration file. I'm not really sure that making them temporary would solve he potential problems. Donald: Of course, if I was IANA, what i would actually do, is mark them as 'temporary' and later change that to 'temporary, expired' and I would actually roll through them and wouldn't reallocate them until the entire space of temporary allocations has wrapped around. Margaret: I strongly disfavor creating new processes for new situations, and would like to see us trying to fit this into existing standard policy. Then IANA will know what to do and will not come to me anytime anyone wants to allocate a DNS code point. If you keep the process the same you can train someone to do it. Expert review means that we can assign someone else, other than me, who they can go to every time and that person can go through whatever process we write down that they can go through, but it makes the interface with IANA along with our standards service model, and allows us to do whatever we want underneath that. I think that was more or less what Thomas was suggesting, and I think that's sort of a superior process architecture. Olaf: Yes, but it seems that the community is suffering from this. Margaret: Why would an expert review where Olafur was in charge of running this process be any slower than having me run this process? Olafur probably cares more, or has more time to care about whether or not the community is suffering than I do. Donald Eastlake: Even if you had expert review, it's quite likely you want to use this template to gather information. What this currently is, is a distributed expert review, where every working group chair and area director has some small chance of being the expert. And if that's the bottom point, you can eliminate it. We can eliminate the temporariness, and replace the approval part with that of an assigned expert. Rob Austein: Couple of points. I'm not on any side, sometimes I'm for, sometimes against. But I don't think the process is fundamentally broken. I think people are not getting new RR types is not because of the process, it's because they're not asking. Specific points, assuming that this proposal goes forward instead of us saying 'let's just not': Two weeks is too short. People can be on holiday for longer than that and something that went from first proposal to completion within that time is just wrong. Thirdly, rcodes I see as different as this, if you don't know a certain RR type, you should not ask for it. But an RCODE is something you get back. What are you supposed to do if you see an error that you have never seen before? I'm not sure if we should loosen up on rcodes. Thomas Narten: I agree, adding an error code is changing the protocol. It's about semantics, not about bits. (Back to review part) Looking at what you got there, if you replace that last part with 'expert review' then you've plugged it into something that is understood in IETF processing, and it gets you to where you want to go. The purpose of the expert is that sometimes he has to say 'I'm in charge and I have to tell IANA yes or no'. But the expert still has to follow some procedure that it is adequately described in some draft, and reviewed on namedroppers for some time, taking into account that time is longer around Christmas, etc cetera. I'm actually personally not opposed to loosening allocation of new RR types, but I also don't think it's fundamentally broken. The bigger issue is I think how to get a new RR type deployed, as opposed to getting the code point for it. Margaret: There's been some words about how the community is suffering, and currently there is a specification required provision. And personally I can't see how this proposal is any easier or faster than specification required. Olaf: This draft did not come out of the blue. It came from a long discussion on the mailing list. There is a bunch of unhappy people out there, and the reason Donald picked this up, I think, is to make sure that we get a process and we get around the bureaucracy that make people frustrated with the IETF. There's a couple of things that make is difficult. One of the things I see is that when people come to this group for review, and they post on the list and ask for review, you hardly see people picking up that work and doing something. That will not be changed by this procedure. I think we should address that in this working group. We have a responsibility in this working group to do that expert review. If some people do that then we're set for this. And the review essentially takes looking at the DNS part, and any bugs can easily be fixed. It is not a lot of work. This settles with the fact that you have to wait for the bureaucracy to actually get the number. We all want the best here, but there is definitely some responsibility for the DNS experts to take turns and do the review. And then if we can make the process issue easier and get those type codes assigned relatively soon to the people who want to use them and do not want to collide. Sam Weiler: Maybe we should approach this from a different direction, and provide a faster permanent publication scheme, like a permanently archived template, so they can walk in saying 'Here's my template, it's permanent. Now give me my type code." Peter Koch: We have heard arguments of people adding things to the DNS that they can't change the definition of their type codes because of an alleged deployed base. So my question is, how stable does this permanently archived template have to be. And part of the frustration might be comments about what happens to the DNS. The other one is sneaking a definition in, and changing it afterwards. What is the idea about stability in that case? Donald: If people are going to get something allocated and then use it for something other than was originally specified, I don't know if there's anything we can do about that. Donald: Obviously I'm going revive the draft based on the feedback. Currently the changes I plan to make are: - RCODE is always IETF consensus - go to expert review - make template archive permanent - make allocation permanent So the question remains what is going into the template? Obviously RCODE will be removed, and RR class and RR type have a set of questions, like 'why can't you use an existing one?'. Would these questions be adequate, or do we want something else? Thomas Narten: I have a more basic question. How many CLASS types have we assigned in the last ten years? Zero. So why do we need a special accelerated procedure to handle them? Donald: Because it seemed more elegant. Olafur: I would say that class is out of scope. Rob Austein: There are enough layer 9 and above issues with new classes. I'm not sure we want to go into this. Interoperabilty testing report =============================== Olafur reports that there is not really much to report. One effort is underway. Mohsen Souissi reports that they have already started a testing plan at AFNIC. They have realized that the RFC is ambiguous sometimes in rfc2119 department (the MUST/SHOULD wording). Also there is some ambiguity whether the test is really conformance or interoperabilty, so they have to dig into that some more. They have sent the plan to Olafur, and the working group should expect a message from Mohsen with a request for software to be used in the interoperabilty tests. Jaap Akkerhuis: I did some interoperabilty testing for rfc1982 (Serial Number Arithmetic). I have not had time to write it up yet, it will be done next month. Drafts from other WG's requesting review ======================================== None at the moment. Those that were there have been helped. Tahi DNS test tool ================== Nobumichi Ozoe reports that they have started to develop an application layer protocol test for DNS. Information can be found at http://www.tahi.org/dns The test targets clients and servers, and will initially test for conformance to: rfc1034, rfc1035, rfc1123, rfc1995, rfc2131, rfc2308, and rfc3425 Later it will be extended by: rfc671, rfc2781, rfc3596, rfc3401-rfc3405, and rfc4033-rfc4035 A beta version will be available in October 2005, please comment to improve the test tool. There is a mailing list: dnstest@tahi.org Mohsen Souissi: It seems to be very useful for draft standard RFC's, but is it worth it to make this for proposed standards? Is there any collision between compliance tests and interoperability tests? Olafur: I don't think there is a risk in having too many tests. I would really encourage people to help out in any way. I am thinking of interop tests that will become compliance tests. Version 0.something is definitely a rough test, but I think this is a very important development. Rip Loomis: There's a will and a can and an it. As far as I can see now on the website there is no download yet, and an empty mailing archive. Can you send a message to namedroppers when there is more there to review? The room tells Nobumichi Ozoe to say yes. Other things ============ Olaf notices that there are a lot of long discussion on namedroppers, that go nowhere. Good intentions, but no actions. For instance the wildcard discussion. That does not go anywhere unless people write drafts. Please write a draft, so we have a way forward. Rob Austein: one thing, this problem is not specific to our working group. I have a script that counts messages from identifiable addresses and summarizes it onlist. It is entirely up to the chairs and the working group whether or not I ever do anything like this for namedroppers, but the offer is there. Meanwhile, I would strongly urge to anybody who does post to the list: If you need to post more than 2 messages a day, unless you're answering specific questions asked to you, you're probably posting too often. Both Olafur and Olaf will be on vacation. Ed Lewis will be moderator of the list while they're gone. End of meeting |