DNSEXT Minutes @ IETF-63

[Ólafur Guðmundsson <[e-mail]>]

[ Moderators note: Post was moderated, either because it was posted by
   a non-subscriber, or because it was over 20K.  
   With the massive amount of spam, it is easy to miss and therefore 
   delete relevant posts by non-subscribers. 
   Please fix your subscription addresses. ]


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: [e-mail]


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



--
to unsubscribe send a message to [e-mail] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>