Re: [renum] draft-liu-6renum-gap-analysis-03

["Leo Liu(bing)" <[e-mail]>]

Hi, Ran

Thanks for your comments. See replies inline please.

> -----Original Message-----
> From: Ran Atkinson [mailto:[e-mail]]
> Sent: Friday, December 09, 2011 8:55 PM
> To: Sheng Jiang
> Cc: Brian E Carpenter; Leo Liu(bing); [e-mail]
> Subject: Re: draft-liu-6renum-gap-analysis-03
> 
> 
> On 09  Dec 2011, at 01:49 , Sheng Jiang wrote:
> > Yes, our statement above is mainly based on BIND implementations.
> > We think most of DNS servers are BIND-based, 80% and above
> > (unverified estimation). So, Bind itself is the majority.
> 
> BIND is quite common with ISPs and content providers,
> but Microsoft Server might well be the majority for
> *enterprise* sites.  Since this document is focused
> on renumbering situations, Microsoft Server's DNS
> might well be the majority for the renumbering situation.
> 

[Bing] Our company also uses Microsoft, I think we need a brief investigation on whether it is quite common, then we can update the draft accordingly. 

> Unlike UNIX deployments of BIND, which stand alone,
> Microsoft reportedly has fully integrated DNS with
> other services (e.g. DHCP, Windows Work groups) inside
> the Microsoft Windows Server.
> 
> So reports say that there is no "flat file" with DNS entries.
> Reportedly, there is also no "loading of the DNS entries".
> Instead, there is full integration of DNS with the
> other services, and things are GUI-based and systemic
> for the whole deployment.
> 
> I'm told that Apple's MacOS X Server takes a very
> similar approach to Microsoft Windows Server, with
> integration and a GUI front-end for the whole deployment.
> Apple apparently does use BIND code behind-the-scenes,
> but system administrators never interact with BIND
> directly and again there are no "flat files" to load
> because everything is behind a common server GUI.
> 
[Bing] If it is true, I think we can add something like "if you deploy Microsoft/apple, the DDNS issue is much easier" after the relevant gap analysis. The gap itself is still meaningful, since it is a real problem if we didn't deploy the integrated solutions like ms/apple.

> > We will contact Cricket Liu for the detail and
> > how common this is. We will update our text accordingly.
> 
> Why not start first by reading his book (which is quite clear) ?
> It is a published O'Reilly book and should be readily available.
> 
> According to the book, Microsoft Windows Server automatically
> enables Dynamic DNS Update between the Windows clients and
> the Windows server in a number of situations.  So deployment
> of Dynamic DNS UPdate is proportional to deployments of
> Microsoft Windows server, which ought to be pretty common
> in an enterprise scenario.
> 
[Bing] I searched his book online, but it seems it's not easy to get one in China, hope there could be Chinese version in the future :)
We can seek other relevant books/materials.

> >> In Section 10, the above draft in part says:
> >>> In the LAN, Secure DHCPv6 ([I-D.ietf-dhc-secure-dhcpv6]) or
> >>> SeND ([RFC3971], Secure Neighbor Discovery) deployment
> >>> may need to validate prefixes.
> >>
> >>
> >> If one thinks that configuring keys for Secure Dynamic
> >> DNS Update is difficult or challenging, then it is
> >> unavoidable to conclude that neither Secure DHCPv6
> >> nor SEND are actually deployable at present.
> >>
> >> I think the problems with key management deserve their
> >> own subsection in Section 10 -- as a category of "gap"
> >> that ought to be addressed.  That new subsection ought
> >> to note the operational issues with key provisioning
> >> and key management for Secure Dynamic DNS Update
> >> (at least for non-MS nodes) and equally or more so
> >> for Secure DHCPv6 and SEND.  One would hope these
> >> would not fall into the "unsolvable gap" category,
> >> but in any event these gaps do need to be clearly
> >> documented.
> >
> > The key management is a complicated issue. It is worth
> > a separated draft. It is relevant. However, we don't
> > think it is a renumbering specific issue.  We will add
> > some new text for it. But we would like to leave it out of scope.
> 
> I do not think that ignoring the issue or declaring it
> out-of-scope is a legitimate position to take for this
> document.
> 
> IETF rules require that ALL documents must fully address
> Security Considerations *within their own document*.
> 
> Ignoring that topic -- or shunting it off to other
> documents -- will result in a Last Call objection from me
> and possibly others on the very solid technical grounds
> that the Security Considerations are known to be deficient.
> 
> >> Similarly, there is a practical operational "gap" in
> >> that we have no way to automatically update ACLs during
> >> a renumbering event.  This also needs to be documented
> >> as a gap.
> >
> > We did list ACL as part of filter, see Section 6.3.
> 
> I did.  It is not nearly clear enough.
> 
[Bing] We can add more description.

> More text is needed -- and since it is a Security
> Consideration it also needs to be referenced in the
> Security Considerations section of the document.
> 
> Last, it is very very rude and offensive to take any
> private email and post it to any public mailing list
> without prior permission of the author -- as you
> have done today.
> 
> Yours,
> 
> Ran