NCSG-DISCUSS Archives

NCSG-Discuss

NCSG-DISCUSS@LISTSERV.SYR.EDU

Options: Use Forum View

Use Monospaced Font
Show HTML Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
Sam Lanfranco <[log in to unmask]>
Reply To:
Sam Lanfranco <[log in to unmask]>
Date:
Thu, 5 Nov 2015 14:31:55 -0500
Content-Type:
multipart/alternative
Parts/Attachments:
text/plain (1854 bytes) , text/html (2505 bytes)
/Carlos Raul asked me://
///

/How large large is the issue?//
//How many have been reserved under those conditions?//
//Who holds them in the meantime (in escrow)?

/The following is from the Problem Statement:/
/

/http://www.ietf.org/id/draft-adpkja-dnsop-special-names-problem-00.txt
/

and in my opinion means that we should just keep a watching brief on the 
discussion
for now.  - Sam L.

In recent years, using the last label of a domain name (aka TLD) as
    switch to indicate how to treat name resolution has been experimented
    using the framework of [RFC6761].  Examples of such switches include:
    .example (don't resolve), .local (use mDNS), .onion (use tor), any
    TLD registered in IANA-maintained root-zone (use DNS).

    Such usage, which a few commenters have referred to as "protocol
    switching," is not limited to "protocol switch" in the strict sense
    of indicating specific protocols on the wire.  It could indicate to
    switch to another name space (eg .onion), use a different protocol
    (eg tor, or mdns), or indicate to use a local DNS scope by not using
    the DNS root for name resolution (eg .home in homenet) or something
    else altogether.

-and-

  [RFC6761] introduced a framework by which, under certain
    circumstances, a particular domain name could be acknowledged as
    being special.  This framework has been used to make top-level domain
    reservations, that is, particular top-level domains that should not
    be used within the DNS to accommodate parallel use of non-DNS name
    resolution protocols by end-users and avoid the possibility of
    namespace collisions.

    Various challenges have become apparent with this application of the
    guidance provided in [RFC6761].  This document aims to document those
    challenges in the form of a problem statement, to facilitate further
    discussion of potential solutions.

/
/




ATOM RSS1 RSS2