Subject: DNSEXT Minutes @ IETF-63

From: Ólafur Guðmundsson<[email-masked]>
Date: Thu, 01 Sep 2005 15:04:39 -0400

[ 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: [email-masked]

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 [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>

---

From: Dean Anderson <[email-masked]>
Date: Sun, 4 Sep 2005 18:17:45 -0400 (EDT)

> implementors either don't know what to do or are ignoring it.

Factor GATT requirements into that. Many countries have agreed [under
GATT] to accept patents issued by other countries, so those patents are
[or will be] enforceable in other GATT countries. [yes, GATT is truely
evil, but that's another story]. You should assume that all patents
propogate to all "civilized"  countries.

> basic theory or scheme of it, perhaps on specific equations. 

Umm, <speaking as LPF President> software patents almost never only cover
specific implementations (ie object code). The issues are how fundamental
the patent is and how broad the patent claims are.  Do you have the patent
numbers for the subject patents?

BTW, one more word of software patent advice: Don't do patent searches,
unless you are patenting something.  Because having done a patent search
[and presumably thinking you've not found anything infringing] is actually
evidence against you for intentional infringement, which carries more
severe penalties.  Once you've admitted that you aren't [or just shouldn't
be] completely ignorant of the infringed patent, you better be sure you
are right. It is usually best to be completely ignorant of the patents so
any infringement is unintentional. [BTW this is an argument against the
patent system--it can't benefit the development of science and technology]

Another patent issue to be aware of: Some patent lawyers think that
possession of [free] software implementations of patented software
infringe on patents. I'll present a summary of both views as accurately as
I can.

Commercial and private usage for non-research purposes plainly does
infringe, but source code possession and research is not so clear.  For
example, the OpenSSL distribution before the RSA patents expired.  I don't
think it is the case that source code possession infringes, but its a view
in dispute and untested in court. My view is based on the notions: That
description of patented technology does not infringe; That you are allowed
to patent enhancements to prior-patents and the prior-patent holder cannot
prevent this; And that a working model must be available at the time of
patent submission---you cannot patent a hypothetical device.

There is an explicit right to have a description of the patented
technology and source code is descriptive of software patents. There must
also be an implicit right that you are that you can use the prior-patented
technology for research on an enhancement, and that you also must be
allowed to use the included prior-patented technology for submission of
your enhancement to the patent office for patenting of your enhancement.
Otherwise, you could not patent an enhancement without the prior-patent
holders' permission, which seems to violate the law allowing such
enhancements.

But as I said, there are expert lawyers with learned opinions who
disagree.  Their view is based on the notion that patent gives one an
absolute, exclusive right over the control of the technology during the
term of the patent. In other words, they have a right not to license, and
if they choose, a right to preventing entirely the private sector use of
the patented technology.  They would probably argue that if you haven't
submitted a patent application, your research isn't really research but
just private usage that they are entitled to prohibit. In verbal "banter"
with such lawyers, some denied entirely any implicit right to research,
which I thought a more dubious position. There is also an argument that
source code aids infringement, particularly binaries [This is also why I
find Kazaa, etc 'aiding' arguments so disturbing, besides other reasons].
There is some support for these views, and for non-trivial conflict in
court. So far, these views are untested. You should consult your lawyer
before deciding on a course of action which could put you at risk.  (And
of course, you should also support the LPF and help abolish software
patents. ;-)

I should add that Av8 Internet and a couple other sites went so far as to
mirror OpenSSL for research in the US before the RSA patents expired
(while using only a patent-licenced version). RSA did not react. However,
this does not conclusively mean anything.

So much for the 2005 patent lecture.... ;-)

		--Dean

-- 
Av8 Internet   Prepared to pay a premium for better service?
www.av8.net         faster, more reliable, better service
617 344 9000

---

From: [email-masked]
Date: Mon, 5 Sep 2005 04:28:19 +0000

thanks Dean.   I'll file this under "arm-chair legal advice"....
 the folks who do this for a living have given good advice to me
 on the implementation we are building.  

 The best advice one can give, unless its from a competent attorney
 who deals in IPR issues, is to get such advice.  Advice from a 
 mailing list is ... less than credible.

--bill

---

From: Dean Anderson <[email-masked]>
Date: Tue, 6 Sep 2005 18:23:07 -0400 (EDT)

Advice from the President of the League for Programming Freedom, an
organization founded by Richard Stallman to fight software patents and
user interface copyrights, an organization that has organized successful
US Supreme Court briefs and has an extensive background and involvement in
Patent, Copyright, and Trademark Law, is better than your usual arm chair
advice.  However, I did advise you to consult a lawyer before doing
anything that could put you at risk.

But the nature of your message suggests that there is something
contradictory to my advice.  What attorney has given you advice
contradictory to mine?

And more to the point, what attorney told you that patent issues are
somehow only covering a specific implementation?

It is particularly odd that you attack my credibility as "arm chair
advice", yet you expect us to accept your assurances.  I can't accept your
assurances. 

I note that on other topics involve law and networks, your associates have
made misrepresentations about legal issues. In some cases that I have
personally been involved with, they have misled their attorneys about the
relevant facts, resulting in incorrect advice based on mis-information.  
And resulting in unnecessary legal conflict. When the mis-information was
corrected and true facts established, their attorneys acknowledged that
our view of the law was right, specifically, that they would comply with
the law and they would cease and desist.

Credibility is established by history of correct statements and correct
analysis.  Lack of credibility is similarly established by a history of
incorrect statements and association with incorrect statements. My
credibility is pretty strong, having been tested over time and vindicated.  
Your credibility has been undermined by the repeated failures of your
associates to make correct statements on other legal topics.  So, I am not
very convinced when you tell us we don't have to worry about some legal
issue.  I am particularly concerned about patent issues, with which I am
pretty well versed.

While your lawyer may have told you something, it has been the case
previously that your associates misled their own lawyers.  Garbage in,
garbage out. 

		--Dean

---

From: [email-masked]
Date: Tue, 6 Sep 2005 22:55:32 +0000

Dean, I take legal advice from my lawyers, not from email lists. You were not
the first and won't be the last to advise getting quality legal opinions. Don't
flatter yourself that you are singled out for special treatment.  If you
would like to join my legal team, then I can put you in touch with my lawyers.
Your comments wrt -our- associates is not germaine to the points raised by the
DNSEXT chair.

--bill

---

From: Dean Anderson <[email-masked]>
Date: Wed, 7 Sep 2005 15:36:13 -0400 (EDT)

Perhaps you could comply with IETF rules and fully disclose the IPR
encumbrances. We cannot take your assurances that there are none.

		--Dean

---

From: [email-masked]
Date: Wed, 7 Sep 2005 20:00:42 +0000

sure.  the filed IPR claims are here:

https://datatracker.ietf.org/public/ipr_search.cgi

--bill

---

From: Thierry Moreau <[email-masked]>
Date: Thu, 08 Sep 2005 16:27:23 -0400

Ólafur Guðmundsson wrote:

> [...]

Well, a different approach to the DNS trust anchor renewal has been 
presented on august 24 to a DNS deployment mailing list ... with 
complete silence as well. I was (naively) hoping some feedback from 
those early adopters before submitting this as an IETF contribution.

The trust anchor key management is similar to the distribution of X.509 
root key certificate. In this area, an IETF draft has been prepared, 
i.e. http://www.ietf.org/internet-drafts/draft-moreau-pkix-takrem-00.txt 
(verion -01 has been submitted today, following comments by Stephen Kent).

For DNS, there are more protocol details for adopting a trust anchor 
rollover scheme like TAKREM ("these details matter tremendously" - Sam 
Weiler). So I prepared a document, see
http://www.connotech.com/takrem_for_dnssec_01.pdf
Title: ‘Trust Anchor’ Integrity Mechanisms for Internet DNS Security

In this document, a new RR id defined, SDDA for "SEP DNSKEY Direct 
Authenticator," with a fairly generic format, and two uses of the SDDA 
RR are suggested, including TAKREM for trust anchor key renewal.

This proposal is both new and comprehensive. The document can be turned 
into an Internet-Draft, but this would need some feedback and discussion.

Regards,

-- 

- Thierry Moreau

CONNOTECH Experts-conseils inc.
9130 Place de Montgolfier
Montreal, Qc
Canada   H2M 2A1

Tel.: (514)385-5691
Fax:  (514)385-5900

web site: http://www.connotech.com
e-mail: [email-masked]