Re: ZONE and VIEW options (Re: 49'th IETF DNSEXT agenda)

[Harald Alvestrand <Harald@Alvestrand.no>]

At 09:31 05/12/2000 -0800, Michael Sawyer wrote:
>[Not sent to agenda@, since I think this is largely off topic there]

oops....sorry.


> > In particular, the ZONE option says that "If the ZONE option is 
> allowed, it
> > MUST return a normally formatted reply with a ZONE optional record,
> > containing the same zone as the one queried.  When replying to AXFR or 
> IXFR
> > queries
> > with ZONE options, the entire zone, including out-of-zone glue, should be
> > returned to the client."
>
>I agree, on re-reading that is confusing.  I think I can remove the
>"including out-of-zone glue" part and have it make more sense; I believe
>in hindsight that that clause is largely meaningless anyway.

dropping ZONE from the doc would make it stronger, IMNSHO.
But I guess I still don't understand what it's good for - adding a more 
fleshed-out use case is probably good for DNS amateurs such as me.


> > The VIEW option "only" has the problem that there is no global namespace
> > for views, no ways of finding out which views are supported by a server,
> > and no specification of the naming scheme for views.
>
>Both of those "problems" were intentional.  The primary goal of the VIEW
>option (which, in my opinion, is the more important of the two) is to
>provide two bits of functionality chich can't be done otherwise.  Both of
>these are currently somewhat Bind9-specific, but I see no reason in the
>way VIEW is defined other people who code similar functionality couldn't
>use the option in the same way.

three, not two.....
global namespace was concerned with the situation where you have 3 
nameservers and 2 views:

   Server A
      view INT primary for .company
      view EXT primary for .company

   Server B
      view INT primary for .firm
      view EXT primary for .firm

   Server C
      view EXT secondary for .company
      view EXT secondary for .firm
      view INT secondary for .club

a client trying to check that the EXT view of .firm was consistent would have
to configure himself with two different names for the same view.
If views were globally named (say, with a domain name under the manager's 
DNS space), those names could not collide.
But this may not be a problem worth solving.

I'll accept your reasoning for the "no way to list views" - although it 
sticks in the craw from a management perspective, DNS isn't a management 
protocol.

The third (naming scheme - wrote that one badly) is an issue that arose 
once where 2 implementations of a protocol interpreted a certain field - 
one could only enter ASCII, and the other was configured with a binary 
value as (unchangeable) default. (TSAPs in X.400, if anyone cares).

This fun event left me with a permanent distaste for namespaces where the 
name is not specified to be either a specific charset or "pure binary".
Saying that "the name consists of ASCII characters", "UTF-8 characters" or 
"binary octets" will all leave me happy.

I understand and like the VIEW option, by now.

Have fun!



--
Harald Tveit Alvestrand, alvestrand@cisco.com
+47 41 44 29 94
Personal email: Harald@Alvestrand.no



to unsubscribe send a message to namedroppers-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.