Re: [mif] Last Call for MIF DNS server selection document

[<[e-mail]>]

Keith, Brian,

The problem this draft is addressing has been acknowledged in the
draft-ietf-mif-problem-statement-15.txt section 4.1. The problem statement
is already at the RFC editor's queue.

Based on the acceptance of the problem, this WG was chartered with a goal
of:
--
  1) DNS server selection solution: a specification for describing a way
  for a network to communicate to nodes information required to perform
  advanced DNS server selection at name resolution request granularity
  in scenarios involving multiple namespaces. The specification shall
  describe the information to be delivered for nodes and the protocol to
  be used for delivery.
--

This draft is the solution that has been accepted as a WG work item.

The topic has been discussed for a quite long time and I don't think there
are any such surprises you refer to (except perhaps for individuals who just
now start following the work).

Furthermore, I cannot easily buy the argument (I hope I read your points
right) that a solution should not be developed for an acknowledged problem
out of fear of "legitimizing" the problematic behavior.

I do agree BCP or similar might be nice to have, but would such BCP really
make any difference e.g. if the network administrator just does not want
names to be resolvable on the public Internet.

Best regards,

	Teemu

> -----Original Message-----
> From: ext Keith Moore [mailto:[e-mail]]
> Sent: 09. syyskuuta 2011 01:22
> To: Brian E Carpenter
> Cc: Savolainen Teemu (Nokia-CTO/Tampere); [e-mail];
> [e-mail]; [e-mail]
> Subject: Re: [mif] Last Call for MIF DNS server selection document
> 
> 
> On Sep 8, 2011, at 5:02 PM, Brian E Carpenter wrote:
> 
> > Teemu,
> >
> > On 2011-09-08 18:16, [e-mail] wrote:
> >> Brian,
> >>
> >> Thank you for review. I agree it is a good idea to consult those WGs
> >> (and DHC as well I suppose), but what makes you so concerned of this
> text:
> >>
> >>>>   In deployments where multiple namespaces are present, selection of
> >>>>   correct route and destination and source addresses for the actual
IP
> >>>>   connection is crucial as well, as the resolved destination's IP
> >>>>   addresses may be only usable on the network interface over which
the
> >>>>   name was resolved on.
> >>
> >> I wrote that as I thought it would be useful to talk a little about
> >> bigger picture of some deployments (like in the demo we had few IETFs
> >> back - without presence of DHCPv6 more specific route options the
> >> system would not have worked properly) .. but if that text creates an
> >> unwanted link or dependency or confusion, I think we can drop the
> >> text just as well and focus on the document just to the new options
> >> and leave this kind of additional system-level consideration out of the
> doc.
> >
> > As Andrew pointed out, the draft starts
> >
> >   "...from the premise that operators sometimes include private
> >    namespaces in the answers they provide from DNS servers, and that
> >    those private namespaces are at least as useful to clients as the
> >    answers from the public DNS."
> >
> > I believe that you will discover during IETF LC that many people have
> > strong feelings about this premise; as Andrew implied, conceptually
> > the DNS is a unified global namespace. This draft is a backdoor way of
> > legitimising an ambiguous namespace. I don't think that will have an
> > easy time in IETF LC, especially if it is dropped as a surprise into
> > the DNS community. It's your choice, but I would suggest that exposing
> > it to the DNS WGs now would be a smart move.
> 
> 
> Frankly, I consider this very nearly a showstopper, in the sense that MIF
> needs an extremely good reason to do this, and I haven't seen even a hint
of
> such a reason.    You may recall that I raised this issue in Quebec,
though
> perhaps I was too polite about it.  (Since I hadn't read the document yet,
and
> was coming late into the discussion, I wanted to give the group the
benefit
> of the doubt.)
> 
> I'm quite surprised that MIF was able to get this far with the document
> without the issue being raised.    I'm shocked that this issue appears to
be a
> surprise to the WG.  I think that by itself is likely a sign of a serious
process or
> management failure.
> 
> 
> > It goes further. The IETF has a longstanding issue with technology
> > that encourages walled gardens. See for example RFC 3002. I think
> > there will be quite some discussion, and this will definitely happen
> > even if you try to remove the "system-level" considerations, because
> > they are strongly implied anyway.
> >
> > Personally I'm not sure what I think about this, but it needs to be
> > discussed in the community IMHO.
> 
> +1.
> 
> Keith