[rssac-caucus] possible new work item

[Arturo Servin]

I like the idea.

My technical knowledge is far away from the people that has already raise
their hands to help, so I do not think that I could add any real value to
the document. However count on me to review it and make suggestions.

Regards
as

On Thu, 28 May 2015 at 15:07 Jim Martin <jrmii at isc.org> wrote:

> Joe,
>         Fine idea there! Count me in as part of the work party, should it
> be formed (and I hope it does!)
>
>         - Jim
>
> > On May 19, 2015, at 12:16 PM, Joe Abley <jabley at hopcount.ca> wrote:
> >
> > Hi all,
> >
> > I have a suggestion for a new work item for RSSAC. If RSSAC thinks this
> work would be of value, and there are people willing to work on it, I'd be
> happy to (co-) lead a work party.
> >
> > A rough sketch of a charter follows.
> >
> > Comments would be most welcome!
> >
> > Thanks,
> >
> >
> > Joe
> >
> >
> > Back in the dim mists of time, individual root servers had names chosen
> by the organisation that operated them. Some/all of these names are
> recorded for posterity in the canonical root hints file, e.g. A was
> originally NS.INTERNIC.NET, B was originally NS1.ISI.EDU, F was
> originally NS.ISC.ORG, etc.
> >
> >  ftp://rs.internic.net/domain/named.cache
> >
> > The naming scheme was subsequently changed to <letter>.ROOT-SERVERS.NET,
> with the intent that the response to the priming query (using label
> compression for the ROOT-SERVERS.NET domain) would be smaller, and would
> allow an additional four root servers to be specified without causing the
> priming response to grow beyond the specified non-EDNS(0) message size
> limit using UDP transport. I have seen this cleverness attributed to Bill
> Manning in the past.
> >
> > ROOT-SERVERS.NET was delegated from the NET zone to all root servers.
> The domain exists in the NET registry, defended by a platoon of registry
> locks, and the zone itself is (if I recall correctly) maintained and
> distributed by Verisign to root server operators as part of the root zone
> maintainer function, with changes following a similar process to that used
> for the root zone, including interactions between the three root zone
> partners.
> >
> > In the opinions of some (but not all) people, the existence of the
> ROOT-SERVERS.NET zone is a historical mistake, and it would have been
> better to name the root servers in a way that avoided the necessity for a
> separate zone, e.g. bare single-label names (A, B, C, ...) or multi-label
> names with no delegation (A.ROOT-SERVERS, B.ROOT-SERVERS) provisioned
> directly in the root zone.
> >
> > The presence of a label like ROOT-SERVERS might in effect constitute a
> reserved TLD label, with corresponding impact on ICANN policy for root zone
> management, the technical direction and remit of the IETF/IAB, and the
> intersection of the two. So, there are dragons^Wpolitical considerations,
> although I think RSSAC should constrain itself to technical commentary and
> leave any dragon baiting to others.
> >
> > SAC53 has a thing or two to say about "dotless domains" like A, B, C,
> etc which could no doubt provide a useful citation. A client that sends a
> priming query with EDNS0.DO=1 (which, I gather, is how most priming queries
> are observed to arrive today) does not currently receive a response with
> signatures in the additional section of the response, because the
> ROOT-SERVERS.NET zone is not signed. The lack of signatures in the
> ROOT-SERVERS.NET zone is either a feature or a bug, depending on your
> perspective; if it was to be signed, the question of key management would
> arise. If signatures were present, there might be some operational impact
> caused by the increased size of the priming response.
> >
> > Rather than the naming scheme for root servers remaining a collection of
> partially-remembered anecdotes plus occasional yet regular memes on mailing
> lists about what a mistake the current naming scheme was, I think it would
> be good if RSSAC could produce a document that:
> >
> > 1. Provides a citeable history on how root nameservers were originally
> named and how they are named today, recording the reasons for the change;
> >
> > 2. Considers the risks and benefits of a new naming scheme that avoids
> the zone cut, including impact on root zone partners' processes, on
> operational issues like priming response sizes and backed-in assumptions
> elsewhere about root server names and on security issues relating to DNSSEC
> validation;
> >
> > 3. Considers the risks associated with any transition from the current
> naming scheme to a different one;
> >
> > 4. Makes recommendations as to whether a change from the current scheme
> should be made and, if the recommendation is to make a change, makes
> further recommendations that might frame the way a transition is planned
> and managed operationally. A recommendation that there be no change is an
> equally reasonable outcome; either way the document should include
> high-quality justification and reasoning.
> >
> > All recommendations made would be actionable by ICANN (rather than
> recommendations actionable by the other two partners or anybody else with
> skin in the game), since that is the scope of our role.
> > _______________________________________________
> > rssac-caucus mailing list
> > rssac-caucus at icann.org
> > https://mm.icann.org/mailman/listinfo/rssac-caucus
>
> _______________________________________________
> rssac-caucus mailing list
> rssac-caucus at icann.org
> https://mm.icann.org/mailman/listinfo/rssac-caucus
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/rssac-caucus/attachments/20150529/433b79bd/attachment.html>