Subject: Re: draft-ietf-dnsind-binary-labels-03.txt

From: Randy Bush <[email-masked]>
Date: Mon, 28 Sep 1998 07:14:40 -0700 (PDT)

> No, I thought I was asking a very limited bureaucratic procedural
> question. ... So why copy them on my question?

because you are questioning whether a draft should go forward.

at this point, 75% of the traffic about drafts progressing is going on in
provate email.  this is not reasonable.

randy

---

From: Thomas Narten <[email-masked]>
Date: Mon, 28 Sep 1998 14:26:57 -0400

>  Mar 98 Sep 98  <draft-ietf-dnsind-dname-02.txt> 
>                 Non-Terminal DNS Name Redirection

The WG has asked to advance this document. However, it appears to
depend on EDNS0 (but not EDNS1).

>  Sep 98 New     <draft-ietf-dnsind-edns0-00.txt> 
>                 Extension mechanisms for DNS (EDNS0)

Looking just at the references, this one doesn't appear to have any
normative dependencies.

However, the dname draft itself says:

> 4.  Query Processing
> 
>     To exploit the DNAME mechanism the name resolution algorithms
>     [DNSCF] must be modified slightly for both servers and resolvers.

and

>     DNS clients sending Extended DNS [EDNS0] queries with Version 1 or
>     greater are presumed to understand the semantics of the DNAME
>     record.  The sender of a Version 0 or a non-extended query may
>     not

That is, perhaps the EDNS0 draft should explicitely reference dname
and make it clear what an EDNS0 implementor must also implement with
respect to dname, as there appears to be an interdependency here.

In any case, how close is the WG to being ready to advance the EDNS0
document?

Thomas

---

From: Paul A Vixie <[email-masked]>
Date: Mon, 28 Sep 1998 16:19:23 -0700

>     record.  The sender of a Version 0 or a non-extended query may

...creates a dependency on DNAME inside of EDNS1 but not in EDNS0.  Since
the purpose of splitting EDNS0/1 was to allow EDNS0 to progress immediately,
any dependencies inside of EDNS0 on things which are not already standards
would be errors.

EDNS1 has a longer timeline, intended as it is to synchronize with DNAME.
(Though if DNAME hangs up, we'll probably push the DNAME-related features
of EDNS1 into a new EDNS2 and make the EDNS version numbers *really* fine
grained.)