On Tue, 09 Mar 2010, Tony Finch wrote: > On Tue, 9 Mar 2010, Matt Larson wrote: > > > > Even after .net is signed (in Q4 2010) > > I note that Verisign's press releases say "by Q1 2011" which I find rather > hard to interpret. Why don't they say "by the start of 2011"? Do they mean > "in Q1 2011"?
Those are calendar quarters. When encountering "by Q1 2011", I think it is safe to assume that what is meant is "by the end of Q1 2011". That is the intent in this particular case. > People on Twitter have been saying today that Verisign are planning to > sign "during the first half of 2011" though the link they are pointing to > says "by the first half of 2011". > http://searchsecurity.techtarget.com/video/0,297151,sid14_gci1411162,00.html?track=sy160 > > What is the date of the actual deployment deadline? I don't know the source for the text on that web page, but the intent has been to consistently communicate that .net will signed during Q4 2010 and that .com will be signed during Q1 2011. > > There is definitely a trade-off between increased response size and the > > incremental benefits of signing that needs to be weighed and evaluated. > > In what situations is the larger response size a problem for > root-servers.net? Why isn't it a problem for any other domain? I didn't mean to imply that it wasn't. If the address records corresponding to a zone's name servers do not in reside in the zone itself, I'd give strong consideration to not signing the zone containing those address records. For example, .com and .net are hosted on servers named in the gtld-servers.net zone, and we are not necessarily going to sign the gtld-servers.net zone (at least not right away): it's a question that needs careful weighing of the trade-offs. Admittedly, the root zone is special becase its apex NS RRset is queried for (./IN/NS priming queries), whereas other zones don't receive such queries as part of the normal resolution process. Matt _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
