Subject: [dnsop] draft DNSOP minutes (IETF 60)

From: David Meyer <[email-masked]>
Date: Mon, 16 Aug 2004 21:20:58 -0700

Folks,

	Here are the draft minutes. Please send corrections to
	the list.

	Thanks,

	Dave & Rob

-------

Domain Name System Operations (dnsop)

WEDNESDAY, August 4, 2004 (1300-1500)
=====================================

CHAIR(s): David Meyer <[email-masked]>
          Rob Austein <[email-masked]>

MINUTES:  Ted Lemon   <[email-masked]>

==========================================

David Meyer:    Suggests authors look at xml2rfc.
                Agenda bashing.

Olaf Kolkman:   dnssec-operational-practices
                Very few differences between the initial submissions,
                except we did a major language (style, spelling)
                review. Content-wise very little changed. A few recs
                from this group such as turning the recs we made 
                more into tradeoffs. 

                Since there is code around, we would appreciate it if
                people could test what we've described as operational
                practices and see if what we've said makes sense. We'd
                really like feedback. Now there is code and a stable
                spec so people can really give us feedback. 

David Meyer:    One other thing I'd like to ask authors, let us know
                what they would like WG to do with their document.
                Ready for WGLC or still outstanding issues. 

Rob Austein:    Right, and in this case we need more readers before we
                proceed. 

David Meyer:    inaddr-required draft, very little activity.

Rob Austein:    This one's come up before. One issue is that some
                people never get past draft filename. If you look at
                the title it doesn't match that. We have one extremely
                vocal opponent of this draft who tries very hard to
                trash the discussion of it - if he does that again we
                will kick him off the list. 

David Meyer:    (consensus call)

Rob Austein:    Looks like people want to go forward with this.

AD (Kessens):   Do you have a plan to make progress with it?

Rob Austein:    We're ready for WGLC unless someone has some other
                issue. 

David Meyer:    With the exception of the individual who's been
                resisting it, there has been no discussion. 

Someone(??):    Take out the normative language.

Suzanne Woolf:  draft-ietf-dnsop-serverid-02.txt 

                This draft was allowed to expire after going through
                most of the process, dunno if it went to IESG, but
                history is that this document is mechanism for finding
                out which server you're talking to, perhaps in a
                load-balancing or anycast cluster. 

                Hostname.bind appeared specifically to support
                anycast. The draft was to document the existing
                practice and suggest a different name. Specific
                mechanism was send query QTYPE CHAOS hostname.bind TXT
                and get server name. Proposal was to change bind to
                server. When documenting, people noticed problems.

                Some concern about namespace abuse as it's an entire
                TLD in class not used for a whole lot. Also
                implementation specific. Most serious drawback
                operationally, requires a separate query because it's
                not in-band with query that's being answered. Some
                consideration of DNSOP coming up with requirements so
                DNSEXT can go do something. Obvious requirement -
                needs to be in-band. Easy to configure, for dumb
                administrators. Interoperable. Not
                implementation-specific. Preferred if it doesn't
                commit namespace abuse. 02 submitted last week,
                documents this initial set of requirements. People
                have suggested, up to WG to decide, needs to be easily
                extensible. Able to support clients that might want
                to offer information. Should be difficult to disable,
                in interests of encouraging people to share info about
                their servers. Initial attempt at solution submitted
                as individual draft to dnsext, uses EDNS0/OPT
                pseudo-RR. There are some gaps, need to think about
                what we want to put in that field. Comments for this
                document, discuss here. Solution to be discussed in
                DNSEX. tomorrow. Anything on current requirements?
                If you have opinions, send them in.

Matt Larson:    draft-ietf-dnsop-bad-dns-res-02.txt 

                Let me say there's a problem with versioning.
                Submitted -03, came out as -02. No idea
                why. Submitting new version to address what comes out
                of this and subsequent ML discussion, so hopefully
                academic. 

                Can I ask who's read the draft. It's been out a
                couple of years. 

                Upshot: draft discusses 11 specific issues that cause
                varying amounts of problems with .com and .net. Not
                worth going over this in detail, but it all adds up to
                some number of extra useless queries that we see.
                What do we do next? 

                Should we modify protocol. A bunch of these have been
                fixed. There are some other things up here that I
                think are worth having. Some are crossing line from
                ops recommendation to something that should be
                codified in protocol. On authns side, if you leave
                off trailing '.' on NS record, authns server can
                figure it out, emit a warning. 0 TTL on NS records can
                have detrimental effect on your parent, so becomes
                philosophical question what an implementation should
                do. Anybody who operates name servers high up can
                feel pain of aggressive dynamic update clients. Ought
                to be two-step process, probe with NS-aware query and
                only then send update. One thing we see a lot of is
                queries for domain names that look a lot like IP
                addresses. 1.2.3.4 rather than ptr query. What do
                you do about that to remove that noise. One
                possibility: delegate all numeric TLDs to separate set
                of servers. That in a nutshell is the draft and its
                recommendations. Encourage folks to read it. Ask
                co-chairs for next steps.

Rob Austein:    Topical document, looking for WGLC soon. Suspect that
                the way to handle protocol changes are to write it as
                here are the operational problems we've seen, we think
                appropriate fix is this, but don't actually specify
                changes. We don't do that. 

Pekka Savola:   In a related similar subject when we forwarded
                something like this to IESG got feedback back that
                proposed fix, even though good idea, if it hadn't been
                taken up in protocol working group, there might be
                some pushback. 

Rob Austein:    We want to document the requirements. Don't care
                which working group. Ask the AD.

Matt Larson:    So take out recommendations?

Rob Austein:    Lots aren't protocol changes. Maybe one or two are. 

Olaf Kolkman:   If you have protocol recommendations put them in
                another I-D, submit to dnsext.

Matt Larson:    Appreciate comments from WG on things in the draft
                that rise to level of protocol changes.

Olaf Kolkman:   I don't see anything in there that goes beyond
                implementation guideline except for creation of new
                TLDs which is ICANN problem. So I don't think we are
                going to be upset if this goes forward. 

Rob Austein:    Path forward: a couple of people, I'll be one, should
                go through this, if we find stuff that's crossing
                line, discuss with chairs and AD. Don't want to lose
                any of these suggestions. 

Rob Austein:    Ready for WGLC. (lots of hands.)

Rob Austein:    Readers who think not ready for WGLC:

Jinmei Tatuya:  I basically have no objection to having WGLC, but want
                to make one comment, previously I made comment on the
                issuing of queries to name servers, got response from
                ???, have not responded to comment, (joseph?), because
                have not found enough time, but am willing to make
                response. Probably can just do that during WGLC. 

Rob Austein:    Yes, sounds fine.

Matt Larson:    Would like to push out quick revision, is that good?

Rob Austein:    Doesn't matter if it's before or after WGLC.

David Meyer:    On to key roll-over requirements.

Francis Guette: Please read -00 draft, we will be doing 01 soon.
                There is still something unclear needed about
                emergency rollover. In case key known by too many
                persons. Section about it, perhaps you can review it,
                don't know exactly what to do. We know we need to do
                something fast to keep the chain of keys. We received
                no comment. As soon as there is no more issues or
                details to explain, etc, perhaps we can do a WGLC.

                Please help with MIP6 WG, trying to explain what
                DNSSEC is doing, asks for help to rewrite the DNSSEC
                subsection which I called . piece of DNSSEC bashing.
                Route Optimization Security Design Background
                document. Contact me or Gabriel Montenegro. 

Olaf Kolkman:   Haven't read in very long time, most people who were
                involved with DNSSEC have not done so. This very
                topic has been getting a lot of attention recently.
                We have had a few discussions on automatic key
                rollovers recently in DNSEXT. I will do it soon, ask
                others to do it as well.

G. Montenegro:  We have this document, it's a back grounder for MIPv6,
                we have a section on DNSSEC, really need some help
                from this WG. Either email me or Francis. 

Johan Ihrens:   Once upon a time I thought that rollover stuff will 
                certainly not require protocol changes and therefore
                DNSOPS would be place for discussions. However, it
                may well be that we end up with protocol changes which
                is why those other drafts on rollover are being bashed
                out in DNSEXT. My brain isn't large enough to cover
                this topic in two different WGs. Keep it all here or
                push it all into DNSEXT. Can't have requirements doc
                in one group and proposed in another.

Rob Austein:    We usually do.

Francis Guette: For solutions, perhaps these are some already in
                DNSSEC. 

David Meyer:    So how many people have read this?

Rob Austein:    Not much of a showing. Of those who read it, how many 
                thing we need to work on this. Is this something WG
                don't want to work on, or something WG does want to
                work on? 

Russ Mundy:     Think that that's true. We need to read it, need to
                attack the operational requirements. Don't remember
                content anymore. 

Rob Austein:    We need to work on key rollover requirements. We
                don't know this is the right doc. First step is to
                read it. 

David Meyer:    Moving right along, increasing dns server.

Rob Austein:    Olaf just reminded me that we have another WG that
                could use some help. MARID. They're talking about
                using DNS to hold stuff dealing with whether or not to
                accept mail from SMTP senders. Very interesting and
                somewhat loud topic. Some have interesting ideas about
                DNS. They have another meeting. 

Schnitz:        In DNSOP, years ago, producing informational RFC
                addressing what the rest of IETF needs to know about
                the DNS. Abby offered copyright protection for using 
                parts of her book. Did anything come of that?

Olaf Kolkman:   Interesting. One issue I want you to address in
                testing - if there is any preference for any of the
                servers in the query pattern. Like, first one gets
                most. Biggest reason for deploying this not mentioned
                in draft. Glue for net zone requires thirteen
                signatures. We could shrink to five. Signatures are
                big. NS and A records are small. 

Yasuhiro Morishita: Is this a DNSSEC issue. I think that we need to
                testing in DNSSEC environment. 

Rob Austein:    Particular issue for signatures is whether this is a
                good idea or not. Number of RRsets matters.

Paul Vixie:     When we looked into doing this at the time that Bill
                Manning first proposed that we switch to
                root-servers.net, reason we did not go with smaller
                numbers of names has to do with the way the recursive
                and stub clients handle SRVFAIL. In event of SRVFAIL,
                no other address for that name server will be tried.
                Timeout will stimulate retry. We thought that it
                would be bad if there was no fallback in event that
                single server did not have zone loaded. So the two
                suggestions I have are first that some minimum number,
                like two or three names, be used, each with small
                number of records, and second that this be considered
                for TLDs but not roots at this time. 

Yasuhiro Morishita: Root and TLDs not be amended be applied.

Rob Austein:    Not done yet, right?

Yasuhiro Morishita: Right.

Rob Austein:    I assume folks think this is useful work, I certainly
                think so. Anyone else. That looks like good support.

David Meyer:    I looked at id-trackers, generated list of other
                drafts, this stuff is already at IESG. misbehavior
                and ipv6-dns-issues are at IESG but in ad followup.

Pekka Savola:   Been revised a couple of times since it went through
                IESG, some comments from Thomas Narten, would like to
                get feedback. Least important one is whether you
                believe there are some documents that should be
                normative references but are not. Second is whether
                we need to do extra. (loud feedback. So feedback
                would be appreciated. It has some connection to
                protocol work, so feedback. from there would be
                welcome. Last issue - split off some parts of
                document into separate documents. E.g. forward and
                reverse DNS updates. 

Rob Austein:    Have you sent list of questions. Might want to resend.

Jinmei Tatuya:  In my understanding authors can just wait for feedback
                from IESG. I would like to make sure that the authors
                there is nothing for them to do in ad-for-ops status.

David Meyer:    We have to look at if there are discuss comments
                against it, or you can look. We can show you how.

David Meyer:    ad-is-watching - second draft is expired. this is
                local-zones. So I'll talk to AD to see what gives. 

Rob Austein:    Paul, want to say anything about respsize doc?

Paul Vixie:     I know that one person actually read this and found
                clownish commentary I put in draft. Nobody flamed me.
                There is a very controversial comment in this draft. 

Peter Koch:     Have one question or remark. We had funny discussion
                about what is allowed length for domain name. 255,
                256, 253. It'. a bit late now to discuss this
                because this is very basic DNS stuff. Nothing to do
                with your draft, but obviously some basic questions
                yet unresolved. Anything we can do in this or another
                WG to resolve this? 

Paul Vixie:     It is certainly the case that in respsize draft I
                should not have mentioned any numbers because it's
                easy to look in other specs. Should just refer to
                standards. That's how I plan to fix the problem in mu
                small corner of ocean. In larger context, it would be
                interesting to see results of survey of what people
                think is max length of domain name on wire. but for
                myself would be more interested in seeing results than
                doing survey. 

Peter Koch:     So by deferring this somewhere else, I beg to differ
                you, you ignored the problem. So what can we do about
                that? Obviously there is one.

Paul Vixie:     I don't know that there really is one. May be sleeping
                dog. People don't design their businesses/projects
                around ability to use names > 250 chars. If you are
                interested in subject, you are speaking words that
                normally precede the statement "I volunteer." 

Peter Koch:     To volunteer is a transitive word in IETF. You are
                probably right, so may or may not be academic
                problem. In your draft, and in other docs, there are
                consequences out of max length. If there is corner
                case, the one single octet that is missing or not, I
                would like to have the discussion before hand, so we
                don't wind up where Mary did solving basic DNS
                problems in midst of IETF meeting. 

Paul Vixie:     Wasn't at Mary because of lack of strong wind. If
                someone is using query name that is really that long,
                difference will be there will be very few glue records
                in the delegation area. Seems unlikely that difference
                of opinion of one octet is going to change planning
                very much. The fact that someone can concoct an
                experiment where really long name breaks model,
                doesn't matter. When people are asking for names that
                really do exist, you care if they got enough glue. So
                for my part only thing that matters is that I take out
                the number and reference 1035. Until someone writes
                critique of 1035, that's good enough for me.

Olaf Kolkman:   Second argument for all you ever wanted to know about
                DNS but were afraid to ask, would be handy to have.

Paul Vixie:     In terms of process, I do not think this draft is
                ready to progress, because no-one complained. So until
                I have some feeling that someone other than me has
                seen this text, I will say it's not ready to go
                forward. 
 
Rob Austein:    So given that we had a number of people claiming this
                was important work, suggests that there is some work
                to be done in terms of reading doc that hasn't
                happened yet. You're all slackers. Go read the document!

David Meyer:    On to the Non-WG documents...

Pekka Savola:   There was one WG doc that has expired a long time ago
                which hasn't been discussed - don't publish
                unreachable draft. Should work on it or not?

Rob Austein:    The author has in fact said he has no time to work on
                it anymore. thought we had a volunteer, have to check
                notes, have not  made obvious progress on it. Do
                people still feel it's useful? Itojun wanted it. I
                dropped ball on this one, will consult notes. 

David Meyer:    So these were the other drafts that had expired. A
                couple of them have been updated since I made these
                slides. Not sure there's anything to say about them
                other than that they're expired, we've been through
                these a couple of times, wanted to know if anybody
                thought this was work that needs to be brought back or
                let it die (dynreverse, interim-signed) 

Tim Chown:      I think dynreverse is important.

Alain Durand:   Thank you for volunteering to work on it with me.

Rob Austein:    Protocol change?

Alain Durand:   Depends on what you call protocol.

Rob Austein:    Change to whole bunch of deployed code. Dubious about
                this one fitting here.

Alain Durand:   I don't care about this particular draft, way of
                solving problem, but do care to have one solution for
                what to do with reverse DNS. In v4 ISP used to do
                prepopulation, would like to see  solution. Don't care
                what it is. 

Tim Chown:      I'm not saying this document is the perfect way, but this
                is important topic.

Rob Austein:    You're volunteering.

David Meyer:    What I had on agenda next was IPv6 config opts. Would
                like to leave for last. Let's go on to Peter.

Peter Koch:     Would like to ask WG question regarding an idea. Using
                SRV records in DNS to do something that has nothing to
                do with DNS. At the moment we have four regional
                internet registries, you ask for IP addresses, receive
                some information, who to contact for that
                address. Which whois server do I query. Would like
                client to figure it out. 

                Suggestion on table - draft-sanz-whois-srv-01.txt.

Pekka Savola:   Can we assume that hte division between different
                registries will be forever on first byte boundary?

Audience:       no.

Pekka Savola:   Does it work if we can't assume that?

Peter Koch:     No we can't know forever, but where's the problem at
                the moment. Currently the RIRs receive more than /8
                worth of address space. If we have non-octet
                boundaries, could take it down the path, distributing
                it on the next level. 

Paul Vixie:     First, the SRV records in question would have to be at
                apexes of delegated part of tree, not in in-addr zone,
                because can't have anything at point above zone cut. A
                query for these would be referred to authority zone
                for these, which is actually a good thing. With regard
                to CIDR allocations, ipv6 tree, we really need to be
                looking at RFC 1101 as far as networking certainly the
                bind resolver has been able to look up RFC 1101 info -
                getnetbyaddr, this works even in case of RFC 2317 or
                other CIDR delegations. Unfortunate that it requires
                lookup of A record to find mask, but can be done. If
                you were to cast this in terms of additional data to
                go into RFC 1101 network naming schema, this would be a
                wonderful thing.

Peter Koch:     So you are saying that this is only useful in
                conjunction with RFC 1101?

Paul Vixie:     Yes. We have to be able to cover that whole area. This
                is an odd form of label stripping. May be a particular
                WHOIS server for 193.10. Start by looking at /32
                level, don't have to check every bit. RFC 1101 gives way
                to find netmask for closest enclosing network. This is
                a good idea, excellent convention, I know that it
                needs to be done in bottom up fashion rather than
                top-down fashion. This is a better solution, but
                requires RFC 1101. 

Peter Koch:     I again beg to differ. What I was afraid to suggest
                was as you suggested, there may be a more specific
                responsible whois server for /32. So sure you could do
                that, but don't see where RFC 1101 comes into the
				thing there. 

Paul Vixie:     RFC 1101 gives you way to discover that there is a /15
				or a /27 or something. 

Peter:          You still have the closest enclosing delegation on
                octet boundary.

Paul Vixie:     Most frequent use of this other than data mining and
                spamming is complaining about them, need to go to
                closest enclosing. 

Russ Mundy:     We're co-chairing a project that's been underway for
                short length of time that focuses on getting DNSSEC
                deployed. Trying to provide a structure/org that's a
                program office for facilitating things that need to
                happen for DNSSEC to get out there. Need to identify
                what needs to happen. Trying to collect peoples' views
                on what needs to happen. Steve has web site,
                dnssec-deployment.org. We look forward to having folks
                join in, provide criticism and information, working
                with everybody. 

Steve Crocker:  You covered it pretty well. I would emphasize is that
                focus is on post-ietf process. What do you do after
                specs are done. There's a host of little problems,
                chicken-and-egg. Who holds the root key. What if you
                ask for signed, get back unsigned. Verisign has
                created its own DNSSEC consortium. I imagine there
                will be  other specialized groups that focus on stuff.

David Meyer:    Pekka, come up please. We have three more agenda
                items. RIPE survey, DNSSEC, EPP if Scott is
                here. Brief review of DNS config options work.

Pekka Savola:   David Malone asked me to present this. IPv6
                lookups. This misbehavior towards certain kinds of
                queries, esp. IPv6 lookups. Took quite a bit of logs
                and found over 20k DNS servers, did a query looking up
                how many had AAAA records or how many had problems
                looking up them. Not sure if this shows, but the thing
                was that 0% have AAA records, 80% have misbehavior. 

                So there's a big problem for IPv6 hosts. Something
                needs to be done about it. What to do is good
                question. Should we set up  hall of shame?

Scott Hollenbeck: Author of EPP. Work of provreg WG. This doc is
                individual submission, tracking progress of EPP and 
                DNSSEC. (reads notes) 

Rob Austein:    The way Scott phrased it, I think interval is
                recommendation. 

Russ Mundy:     I'm not sure if it's a work item for this WG because
                it's part of a space that WG hasn't dealt with in the
                past. I think it's very important work that needs to
                be done whether part of this WG or not. 

Rob Austein:    I asked Scott to bring this here. This is not DNSEXT
                work because it's not DNS protocol. Not really EPP
                work. This is really about what does DNSSEC need. So
                this seems like the right place to come to get
                help. Don't care if WG adopts it. 

Ed Lewis:       Its a good thing to discuss here. One operator said
                would like to see registries (?) in  common. EPP is
                primarily used in one set of registries, but not all
                registries. Would be good forum for operators to say
                how all registries should treat ???

Scott Hollenbeck: Quick note to ML. Will do.

David Meyer:    DNS configuration options draft. Advisory doc to
                IESG. Wanted to see fi there were solid objections to
                what's in draft, if not, WGLC. Let me remind you of
                the three things. If you've been asleep for last
                couple of years, these are the three options. RA,
                DHCP, WKA. What we want is to move this doc through
                WGLC, get it to  informational, if you have any
                objections, sense that some issue that you have isn't
                covered, please speak up. 

Rob Austein:    Documenting state of inconclusive discussion we've had
                over and over again. If it covers all issues
                adequately, we are done. If there is something
                missing, tell us now.

David Meyer:    Should really get it to informational (after all, this
                is the third time draft has been written).

David Kessens:  Major issues only. No nit-picking please.

David Meyer:    Reminder: this is not a proposal - just documenting
                what has been proposed.

Erik Nordmark:  Seems to make some performance claims based on
                unstated assumptions. E.g. claims that RAs are
                better. Sending this stuff many times a day in case it
                changes. Seems like wasting bytes. Don't know what to
                do about performance claims. Seems to need a bit more
                rigor. 

Rob Austein:    Needs more eyes on that part of text. It's just bytes
                in a message that's going out anyway.

Erik Nordmark:  May be a lot more bytes.

Rob Austein:    Right, so we should back it up.

Jinmei Tatuya:  Not making objection, but my understanding there are
                several substantial comments on previous draft. There
                are significant  changes from previous version, should
                issue last call again. Make solid consensus. Not
                necessarily going to push this idea if you are
                particularly in hurry. 

Rob Austein:    We're in a hurry because in order to get this done we
                had a deadline. The AD can speak for self. AD will be
                cool with taking more time for WGLC if we're making
                serious progress by doing so. Don't want it to drag on
                forever. 

David Kessens:  I can go for it.

-----
AGENDA

 o Administriva                      2 minutes

   - Mailing list: [email-masked]
     subscribe dnsop

   - Scribe?

   - Blue Sheets

 o Agenda Bashing                    5 minutes
   Meyer                                           

 o Review and status of work items           55 minutes

   Active Drafts
   -------------
   draft-ietf-dnsop-dnssec-operational-practices-01.txt   5 minutes
    Kolkman et al
   draft-ietf-dnsop-inaddr-required-05.txt                5 minutes
     Senie
   draft-ietf-dnsop-ipv6-dns-issues-07.txt                2 minutes
    Durand, et al 
    IESG Evaluation::Revised ID Needed (Informational)
   draft-ietf-dnsop-ipv6-transport-guidelines-02.txt      2 minutes
    Durand, et al 
    RFC Ed Queue (BCP)
   draft-ietf-dnsop-key-rollover-requirements-00.txt      5 minutes
    Guette, et al
   draft-ietf-dnsop-misbehavior-against-aaaa-01.txt       2 minutes
    Morishita, et al.
    IESG Evaluation::AD Followup (Informational)
   draft-ietf-dnsop-ohta-shared-root-server-03.txt        1 minute
    Ohta
   draft-ietf-dnsop-serverid-02.txt                       2 minutes
    Woolf
   draft-ietf-dnsop-bad-dns-res-02.txt                   15 minutes
    Larson/Barber

   Expired WG documents
   ---------------------
   draft-ietf-dnsop-resolver-rollover-01.txt              2 minutes
    expired (Kolkman)

   AD is watching
   ---------------------
   draft-ietf-dnsop-respsize-01.txt                       5 minutes
    expired (Vixie/Kato)
   draft-kato-dnsop-local-zones-01.txt                    5 minutes
    expired/no WG document

   Non-WG Documents
   ------------------------
   draft-durand-dnsop-dynreverse-01.txt                   2 minutes
    expired
   draft-ihren-dnsop-interim-signed-root-02.txt           2 minutes
    expired
   draft-yasuhiro-dnsop-increasing-dns-server-01.txt      5 minutes
    expired

 o DNSSEC Deployment Activity                 5 minutes
   Steve Crocker/Russ Mundy

 o IPv6 DNS Configuration Options                        15 minutes

   draft-ietf-dnsop-ipv6-dns-configuration-01.txt
    Jeong, et al

 o RIPE survey                       10 minutes
   draft-ietf-dnsop-misbehavior-against-aaaa-01.txt
   http://www.ripe.net/ripe/meetings/ripe-48/presentations/ripe48-dns-malone.pdf
   Savola, et al.
.
dnsop resources:_____________________________________________________
web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html
mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html

---

From: Francis Dupont <[email-masked]>
Date: Tue, 17 Aug 2004 17:13:06 +0200

In your previous mail you wrote:

   Francis Guette: Please read -00 draft, we will be doing 01 soon.
           ^^^^^^
=> my name is Francis Dupont, Gilles Guette is one of the authors
and I spoke on behalf of them. BTW the 01 is already available.

   
           ^^^^^^  DNSSEC. 

=> same problem.

Thanks

[email-masked]
.
dnsop resources:_____________________________________________________
web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html
mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html

---

From: David Meyer <[email-masked]>
Date: Tue, 17 Aug 2004 08:43:13 -0700

>> and I spoke on behalf of them. BTW the 01 is already available.

Gotcha. Thanks.

>>    Francis Guette: For solutions, perhaps these are some already in

Will fix.

Dave

.

---

From: Dean Anderson <[email-masked]>
Date: Tue, 17 Aug 2004 17:35:47 -0400 (EDT)

>                 will kick him off the list. 

I presume this is directed at me, even though I'm not the only opponent of
this draft, nor even the only vocal opponent.  But before I assume this,
and renew complaints about inappropriate activity by Mr. Austein in
relation to keeping this draft alive despite lack of interest, and despite
numerous editing and factual errors in the draft, and complaints of his
inappropriate action against Av8 Internet and myself in refusing to accept
email from Av8 Internet, refusing not just me personally, but email from
all of Av8 Internet to his official IETF address [email-masked], and falsely
claiming that Av8 Internet's address hijacked.  There are legal
consequences for these abuses, and the IETF has been previously notified
of this.

In any case, neither I nor anyone else has "trashed discussion" of this
draft on the DNSOP list, nor would it be appropriate to kick any opponent
of this draft off the DNSOP list.  This threat is yet another in a series
of inappropriate actions by Mr. Austein in relation to this draft.  

The discussion by the opposition has centered around the false and
misleading statements in the draft describing the policies of other
organizations, and other errors.  Exposing those errors and
inconsistencies is not "trashing the discussion".

The title is misleading given the apparent contents of the draft, but that
is only because the draft is internally inconsistent between its early
paragraphs and its later paragraphs. These inconsistent statements were
added after the notion of making in-addr required was very widely rejected
by nearly all participants.  Despite the introductory paragraphs which
seem to say otherwise, the purpose of the authors in writing this draft is
to make in-addr required, and that proposal has been widely rejected,
despite Mr. Austein's efforts to keep the idea alive.

Dean Anderson
Av8 Internet, Inc

.