Subject: 43rd IETF-ORLANDO, FL: DNSIND

From: Randy Bush <[email-masked]>
Date: Thu, 12 Nov 1998 08:16:32 -0800 (PST)

do we have items for the agenda, please?

From: Marcia Beaulieu <[email-masked]>

This is to confirm one session for DNSIND as follows:

	Tuesday, December 8 at 1015-1115
		(other groups scheduled at that time: bridge, vrrp, nfsv4)

Please submit an agenda for these meeting as soon as possible, the
deadline for submitting the agenda is November 30 at 1200 noon ET.

---

From: Robert Elz <[email-masked]>
Date: Sun, 15 Nov 1998 18:21:34 +1100

Date:        Thu, 12 Nov 1998 08:16:32 -0800 (PST)
    From:        Randy Bush <[email-masked]>
    Message-ID:  <[email-masked]>

  | do we have items for the agenda, please?

To get things started, as I see it, we have the following issues to
deal with...

First, any progress on getting the I N and D protocols from PS to DS ?

As I recall it, IXFR needs another implementation, and some inter-op testing.
If the implementation exists, some testing now would be good, with a
report in Orlando.   If not, IXFR remains at PS, and there's nothing about it
to talk about.

For NOTIFY there was still perhaps some TCP NOTIFY testing to be done,
aside from that, I think it was finished.   Has anyone had a chance to do
any testing of NOTIFY using TCP?   If not, I think we can omit this from
the agenda.

For DYNDNS a few RFC clarifications were discovered.   We are going to need
a new draft for this to go to DS.   However, DYNDNS isn't going near DS until
there is also DNSSEC (or a suitable replacement) ready for DS, and I don't
think that DNSSEC is near that stage yet, and TSIG isn't even PS.

Given all of that, I suspect that there is not going to be a need to discuss
any of the I N or D protocols.  However, if we have a new D draft by then, or
relevant implementation reports for I or N, then they can be included.

Aside from that, we have our current drafts to discuss.

Of those, I think that edns0 and edns1 are likely to be the ones most in
need of review.   There should probably be some more brief discussion of
dname and binary-labels, just to make sure that it is generally agreed that
they're about ready to go.

For test-tlds and local-compression, I suppose one more "do we agree"
question can be asked, but I doubt it is worth spending much more time on
them, either the WG agrees that we should send them to the IESG, or I think
they should simply be allowed to lapse.

I'm not sure I really want to comment on the local-names draft, my personal
opinions on that have been heard before.  A brief discussion on that one
(again) probably would not hurt, perhaps it can be dispatched to whence it
belongs.

That leaves (of the dnsind drafts anyway), tsig and 2052bis.   2052bis is
done now I believe, or will be, and will not require discussion.   I'd like
to think that tsig is also done - is there anyone who believes that more WG
time needs to be spent on that?

Aside from dnsind native work, there are a few drafts in other WGs that
probably could do with a DNSIND review.   Of those,
	draft-ietf-dnssec-simple-update-00.txt
is probably the most relevant - it may even be that that draft should be
moved into DNSIND, that will be taken up with its author and the DNSSEC
chair and ADs.

Then there's draft-ietf-ipngwg-dns-lookups-02.txt (the A6 RR type, and PTR
lookup scheme for IPv6) which needs DNS review.

Comments on this?   Is there anything else we need to add?

Note that with a one hour slot there isn't going to be a lot of time for
presentations or similar on any of these drafts - that will require everyone
to have read any of the drafts they are likely to want to make a comment on.
Of course, in theory, that's always true, but in this WG meeting you can
assume that the chair will be quite ruthless in cutting off discussion or
comments which show ignorance of what is in the drafts.

kre

---

From: Randy Bush <[email-masked]>
Date: Sun, 15 Nov 1998 15:59:04 -0800 (PST)

> First, any progress on getting the I N and D protocols from PS to DS ?

none of which i am aware, sigh.  i think olafur is about ready to start an
interoperation testbed.  olafur?

and yes, we don't do tutorials, just issue discussion.  come having read the
drafts.

randy

---

From: Paul A Vixie <[email-masked]>
Date: Mon, 16 Nov 1998 02:16:19 -0800

> think that DNSSEC is near that stage yet, and TSIG isn't even PS.

The interoperability pizza night showed up one glaring error, which was the
use of the term "owned by" to describe a relationship between nodes rather
than between a node and its rrsets.  (Mea culpa.)  The old text was:

   1.2 - Glue RRs

   For the purpose of determining whether a domain name used in the
   UPDATE protocol is contained within a specified zone, a domain name
   is "in" a zone if it is owned by that zone's domain name.  See
   section 7.18 for details.

This is from RFC 2136 (page 3) and no, [7.18] wasn't helpful in clearing up
this error in term use.  [7.18] just explains why you're allowed to add nodes
to a zone which are below a zone cut and why that's OK.  (Which it is, and
has to be, due to Glue RRs, which are of course the subject of [1.2].)

I propose the following replacement text:

   1.2 - Glue RRs

   For the purpose of determining whether a domain name used in the
   UPDATE protocol is contained within a specified zone, a domain name
   is "in" a zone if it is equal to the zone's domain name or is a subdomain
   of the zone's domain name.  See section 7.18 for details.

> relevant implementation reports for I or N, then they can be included.

If noone coughs up a lung at the above suggested text, I'll post RFC2136bis
before the deadline on the 18th.

---

From: Olafur Gudmundsson <[email-masked]>
Date: Mon, 16 Nov 1998 11:20:34 -0500

>interoperation testbed.  olafur?

Yes, I'm writing the invite to participate in testing as we speak. 
What I  would like to do is to schedule 2 slots at IETF for testing,
one informal one on Monday night and a real one on Tuesday night
R or R can you get us a room for testing or will we do that in the hallway. 

	Olafur 

----------------------------------------------------
Olafur Gudmundsson 	    		[email-masked]   (work)
(301)-854-5700   Fax: x5363		[email-masked]   (private)

---

From: Robert Elz <[email-masked]>
Date: Tue, 17 Nov 1998 04:41:37 +1100

Date:        Mon, 16 Nov 1998 11:20:34 -0500
    From:        Olafur Gudmundsson <[email-masked]>
    Message-ID:  <3.0.5.32.19981116112034.009afb20@localhost>

  | R or R can you get us a room for testing or will we do that in the hallway. 

I will ask, and see what is available.

kre

---

From: Robert Elz <[email-masked]>
Date: Tue, 17 Nov 1998 21:48:21 +1100

Date:        Mon, 16 Nov 1998 02:16:19 -0800
    From:        Paul A Vixie <[email-masked]>
    Message-ID:  <[email-masked]>

  | The interoperability pizza night showed up one glaring error, which was the
  | use of the term "owned by"  ...

My notes indicate that there was also a request for clarification of 1.1.3.
That is, related to wildcards.

My memory is hopeless, and it turns out my notes of this are hopeless too
(something to do with it having been after midnight on a long day
probably), so I hope that one of the others remembers exactly what was
wanted.

My recollection is that it was desired to say (explicitly) that the
"wildcarding is disabled" applies to pre-requisite processing, as well
as to the actual update.

Does someone have a suggestion for what wording would actually be suitable?

kre

---

From: Peter Koch <[email-masked]>
Date: Tue, 17 Nov 1998 22:55:30 +0100

> question can be asked, but I doubt it is worth spending much more time on

I've just submitted an updated version of the local compression (lc) draft
with mostly editorial changes.

The EDNS1 document allocates an extended label type for local compression
with long local compression pointers with a reference to the lc draft.
A section defining their use was missing from the "02" version posted in August
due to a clerical error of mine, but now I'm no longer sure it should be in
there.

If local compression shall be available for the new RR types defined in
the IPv6 context, it will have to go to PS no later than those.
But the lc document would have to refer to EDNS1 for the extended label
type allocation, and EDNS1 is going to receive more discussion, so lc
would not be available for SRV, DNAME and probably A6 (local or none
compression is a per RR type decision, which cannot be changed later).

On the other hand, very large RDATA sections are not a problem for now,
so the discussion of edns based long local compression can safely be postponed
until edns1 has settled and can be specified in a separate document should
the need be.

-Peter

---

From: "Donald E. Eastlake 3rd" <[email-masked]>
Date: Wed, 18 Nov 1998 09:43:15 -0500

From:  Robert Elz <[email-masked]>
To:  namedroppers <[email-masked]>
In-Reply-To:  Your message of "Thu, 12 Nov 1998 08:16:32 -0800."
	                  <[email-masked]> 
Date:  Sun, 15 Nov 1998 18:21:34 +1100
Message-Id:  <[email-masked]>

>...

I think edns0 is high priority. Doesn't it at least need an IANA
Considerations section added to get through the IESG???

>they should simply be allowed to lapse.

I am about to submit a very minor update to test-tlds which mostly
just updates the author info.  I believe that, while there is at least
one dissent, there has been and is a working group consensus for
test-tlds and, in its current limited form, it has been cleared by
IANA.

>(again) probably would not hurt, perhaps it can be dispatched to whence it

I am about to submit an updated version of local-names.  I think it
needs to percolate some more and suggest that, if on the agenda, it be
put on the bottom.

>moved into DNSIND, that will be taken up with its author and the DNSSEC

See message I just posted to dnssec and dnsind re simple-update.
While I don't really care what WG group tsig is in, if there is logic
to having a separate "DNS Security" WG, then tsig should have been in
DNSSEC.  (I have been holding up on trying to advance the TKEY draft
waiting for the TSIG draft to go through.)

>comments which show ignorance of what is in the drafts.

If I have time by the cut off (not likely), I plan to post and thus
reactivate the infamous Kitchen Sink RR.  This actualy was of some
popularity but I neglected to incorporate the comments received and it
timed out.  Recently (on a scale of months), two organizations who
apparently were seeking RR types for proprietary RRs were referred to
me by IANA personel apparently in the hopes that their needs could be
satisfied by the SINK RR....

>kre

Thanks,
Donald
============================================================
 Donald E. Eastlake 3rd +1 978-287-4877 [email-masked]
 318 Acton Street       +1 978-371-7148 (fax)   [email-masked]
 Carlisle, MA 01741 USA

---

From: "Matt Crawford" <[email-masked]>
Date: Wed, 18 Nov 1998 08:40:54 -0600

Peter Koch says:
> would not be available for SRV, DNAME and probably A6 ...

I frequently find myself in apparent disagreement with our ADs on
this point.  If successful implementation of specification X requires
information in document Y, then X cannot advance ahead of Y.  But if
you say in your draft that a local-compression pointer is denoted by
a certain bit pattern, nobody needs to have EDNS1 in hand to
implement that.  Indeed, if EDNS1 says that inclusion of a certain
new option indicates that the sender understands local compression
(among other things), then the dependency is purely the other way.

				Matt

---

From: Randy Bush <[email-masked]>
Date: Fri, 20 Nov 1998 06:26:21 -0800 (PST)

>| The interoperability pizza night

there was also thai food for us folk who prefer food.

> That is, related to wildcards.

from the minutes of the interop testing

    Section 1.1.3 needs clarification to indicate that it applies to all
    situations, including pre-requisites.

from the minutes of the subsequent meeting

    In section 1.3 of the paper, the term "owned by" is misleading
    teriminology, and should be rephrased. Paul Vixie will fix the
    document.

randy