Re: [DNSOP] DNS names for local networks - not only home residental networks ...

[Ralph Droms]

> On Sep 2, 2017, at 8:29 PM, Warren Kumari  wrote:
> 
> On Fri, Sep 1, 2017 at 4:14 PM, Paul Wouters  wrote:
>> On Fri, 1 Sep 2017, Walter H. wrote:
>> 
 If you are a company and you are using a hardcoded domain of "local",
 then you have been and still are, completely broken. The only fix is to
 rename your network.
>>> 
>>> ACK and which non public domain name I can use for this
>>>  that doesn't conflict now and will not conflict in the future?
>> 
>> 
>> Something that's yours and not squatted. For example
>> internal.mathemainzel.info.
>> 
>> Please see the last three years of dnsops and homenet working group list
>> archives.
>> 
> 
> ... perhaps the other way of looking at the last thirty three years of
> DNS is that people *do* actually want something like this, and that
> perhaps it is time to actually create something specifically for it.
> Our smacking people on the nose with rolled up newspapers and saying
> "no, bad operator" ignores the fact that people still want this, and
> still do this, and there ain't nothing we can do to stop them...
> 
> And so: https://tools.ietf.org/html/draft-wkumari-dnsop-internal-00
> 
> This asks for a Special Use Name, specifically for this sort of thing
> (and, yes, for building test networks, and for labeling devices which
> have no Internet connection, etc). The desire and need for something
> like this has been identified / discussed for a long time - the most
> recent was probably when we decided that .alt would only be for
> non-DNS contexts, and that someone should go make something like this
> for the DNS - think of it like RFC1918 for names.
> It will require an unsecured delegation, for which we currently have
> no process, and this (if people think it is a good idea!) will require
> process to be created -- which A: will take many many years, and B: if
> at least somewhat unlikely to happen -- but, if we don't at least ask,
> we certainly won't get it...

Warren - I've only read part of your draft, and I'll comment on that part of 
it...

I was immediately struck by the parallel between  and 
home.arpa.  How are the two cases different?  Can you explain why this text 
from section 3.2 of your doc applies to internal.arpa and not to homenet.arpa?  

   It may also cause issues when server operators
   override part of the .arpa domain in order to instantiate
   something.arpa.

- Ralph


> 
> And yes, this is somewhat of a straw-man.
> W
> 
> 
>> 
>> Paul
>> 
>> ___
>> DNSOP mailing list
>> DNSOP@ietf.org
>> https://www.ietf.org/mailman/listinfo/dnsop
> 
> 
> 
> -- 
> I don't think the execution is relevant when it was obviously a bad
> idea in the first place.
> This is like putting rabid weasels in your pants, and later expressing
> regret at having chosen those particular rabid weasels and that pair
> of pants.
>   ---maf
> 
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Minor editorial change to draft-ietf-dnsop-sutld-ps

[Ralph Droms]

> On Jul 4, 2017, at 3:39 AM, Randy Bush  wrote:
> 
>> The Special-Use Domain Names Problem Statement document unsurprisingly
>> contains a list of problems.
> 
> is there a companion document with the list of benefits/advantages?

It's a list of problems, not solutions, so there aren't benefits and/or 
advantages.

>  or
> is thins just one of those ietf documents from on high meant to kill
> something?

It's not intended as a dead-end, either.  It is intended as a reference 
document for solution documents to point at.  Warren add numbering to the list 
so the problems could be referenced more easily by solutions documents, such as 
draft-ietf-dnsop-alt-tld-08 

> 
> randy, who does not have a dog in this fight, just smells dog poop
> 

- Ralph


___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] I-D Action: draft-ietf-dnsop-sutld-ps-06.txt

[Ralph Droms]

> On Jun 28, 2017, at 4:14 PM, Russ Housley  wrote:
> 
> Please correct this typo:
>  s/certs for such names/certificates for such names/

The fix will appear in the next rev of the draft.

Thanks, Russ.

- Ralph

> 
> 
>> On Jun 27, 2017, at 8:57 PM, internet-dra...@ietf.org wrote:
>> 
>> 
>> A New Internet-Draft is available from the on-line Internet-Drafts 
>> directories.
>> This draft is a work item of the Domain Name System Operations of the IETF.
>> 
>>   Title   : Special-Use Domain Names Problem Statement
>>   Authors : Ted Lemon
>> Ralph Droms
>> Warren Kumari
>>  Filename: draft-ietf-dnsop-sutld-ps-06.txt
>>  Pages   : 28
>>  Date: 2017-06-27
>> 
>> Abstract:
>>  The Special-Use Domain Names IANA registry policy defined in RFC 6761
>>  has been shown through experience to present unanticipated
>>  challenges.  This memo presents a list, intended to be comprehensive,
>>  of the problems that have been identified.  In addition it reviews
>>  the history of Domain Names and summarizes current IETF publications
>>  and some publications from other organizations relating to Special-
>>  Use Domain Names.
>> 
>> 
>> The IETF datatracker status page for this draft is:
>> https://datatracker.ietf.org/doc/draft-ietf-dnsop-sutld-ps/
>> 
>> There are also htmlized versions available at:
>> https://tools.ietf.org/html/draft-ietf-dnsop-sutld-ps-06
>> https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-sutld-ps-06
>> 
>> A diff from the previous version is available at:
>> https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-sutld-ps-06
>> 
>> 
>> Please note that it may take a couple of minutes from the time of submission
>> until the htmlized version and diff are available at tools.ietf.org.
>> 
>> Internet-Drafts are also available by anonymous FTP at:
>> ftp://ftp.ietf.org/internet-drafts/
>> 
>> ___
>> DNSOP mailing list
>> DNSOP@ietf.org
>> https://www.ietf.org/mailman/listinfo/dnsop
> 
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] AD review: draft-ietf-dnsop-sutld-ps

[Ralph Droms]

Thanks for the review and helpful comments, Benoit.

Ted, Warren - I'm login to be tied up with some family stuff through the 
weekend.  If none of us get to it, I can process Benoit's comments Monday.

- Ralph

> On May 30, 2017, at 11:22 AM, Benoit Claise  wrote:
> 
> Dear authors,
> 
> Here is my AD review.
> 
> 
> - 
>This section presents a list of problems that have been identified
>with respect to the assignment of Special-Use Domain Names.
>Solutions to these problems, including their costs or tradeoffs, are
>out of scope for this document. 
> 
>There is a broad diversity of opinion about this set of problems.
>Not every participant agrees that each of the problems enumerated in
>this document is actually a problem.  This document takes no position
>on the relative validity of the various problems that have been
>enumerated.  Its focused purposes are to enumerate those problems,
>provide the reader with context for thinking about them and provide a
>context for future discussion of solutions.
> 
> So you want to write something such as  ... regardless of whether the 
> problems are valid ones AND regardless of the ownership (IETF, IANA, ICANN, 
> or ...) 
> And it seems that you didn't try to categorize the problems per ownership 
> (this is an IETF or ICANN problem, as an example).
> I guess that this is the way you approached this document, right? You should 
> document this.
> 
> - 
> gTLD Generic Top-Level Domain, as defined in in section 2 of RFC
> 7719 [RFC7719]
> 
> gTLD is not strictly defined in RFC7719, only TLD
> 
> - correct the .home section in 4.2.7, which is solved with Errata ID: 4677 
> 
> 
> MINOR
> - 
>[SDO-ICANN-DAG]
>   Internet Assigned Numbers Authority, "Special-Use Domain
>   Names registry", October 2015,
>    
>   full-04jun12-en.pdf 
> >
> 
> Don't you have a more up to date reference (2012)?
> First page of this document is: "Currently the namespace consists of 22 gTLDs 
> and over 250 ccTLDs operating on various models."
> -
>o  There are several Domain Name TLDs that are in use without due
>   process for a variety of purposes [SDO-ICANN-COLL 
> ].
>   The status of
>   these names need to be clarified and recorded to avoid future
>   disputes about their use.
> 
> I don't understand the sentence "There are several Domain Name TLDs that are 
> in use without due
>   process for a variety of purposes", with a reference that speaks about 
> "Name Collision in the DNS".
> 
> 
> EDITORIAL:
> - "in in". Two occurences in
> TLD Top-Level Domain, as defined in in section 2 of RFC 7719
> [RFC7719]
> gTLD Generic Top-Level Domain, as defined in in section 2 of RFC
> 7719 [RFC7719]
> 
> - OLD:
>Special-Use Domain Name  A Domain Name listed in the Special-Use
>   Domain Names registry.
> NEW:
>Special-Use Domain Name  A Domain Name listed in the Special-Use
>   Domain Names registry [SDO-IANA-SUDR].
> 
> - OLD:
>The history of RFC 6762  is 
> documented in substantial detail in
>Appendix H 
> 
> 
> NEW: 
>The history of RFC 6762  is 
> documented in substantial detail in
>Appendix H of RFC 6762 
> 
> 
> - Expand SSAC on the first occurrence.
>  
> Regards, Benoit
> 

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] extended deadline Re: WGLC for draft-ietf-dnsop-alt-tld

[Ralph Droms]

I see that draft-ietf-dnsop-alt-tld-08 gives the intended status of the 
document as Informational, while it is listed in the datatracker as "In WG Last 
Call: Proposed Standard".  

There are arguments in favor of each status.  The relevant text is in section 5 
of RFC 6761:

   An IETF "Standards Action" or "IESG Approval" document specifying
   some new naming behaviour, which requires a Special-Use Domain Name
   be reserved to implement this desired new behaviour, needs to contain
   a subsection of the "IANA Considerations" section titled "Domain Name
   Reservation Considerations" giving answers in the seven categories
   listed below.

Publishing draft-ietf-dnsop-alt-tld-08 as Proposed Standard meets the 
"Standards Action" requirement.  However, Proposed Standard may not be 
appropriate for draft-ietf-dnsop-alt-tld-08, as the document does not specify a 
new protocol, as such.  draft-ietf-dnsop-alt-tld-08 does specify certain 
behaviors for components of the Internet, which could be thought of as 
providing for interoperability so that Proposed Standard status would be 
appropriate.

On the other hand, publishing draft-ietf-dnsop-alt-tld-08 as Informational 
would require an "IESG Approval" document to meet the requirements of RFC 6761. 
 A short sentence added to draft-ietf-dnsop-alt-tld-08 is likely all that would 
be needed, to the effect of "The IESG has reviewed this document and approves 
of the request to add .alt to the Special Use Domain Names registry."

In any event, in my opinion the WG needs to express its explicit consensus 
about its choice of intended status for draft-ietf-dnsop-alt-tld-08.

- Ralph

> On Apr 7, 2017, at 9:38 AM, Suzanne Woolf  wrote:
> 
> Hi,
> 
> We had initially scheduled the WGLC on this document to be over by now. 
> However, the flurry of activity around the review we were asked to do on the 
> homenet-dot draft, and the general traffic level on the list during IETF 98, 
> suggested to the chairs that we should extend the WGLC.
> 
> We’re hereby formally extending it to next Wednesday, April 12.
> 
> As always for WGLC— we need to hear both support and opposition for taking 
> this draft to the next step in the process.
> 
> thanks,
> Suzanne  & TIm
> 
> 
>> On Apr 1, 2017, at 4:17 PM, Stephane Bortzmeyer  wrote:
>> 
>> On Sun, Mar 12, 2017 at 07:20:55PM -0400,
>> Suzanne Woolf  wrote 
>> a message of 92 lines which said:
>> 
>>> This message opens a Working Group Last Call for:
>>> 
>>> "The ALT Special Use Top Level Domain"
>>> https://datatracker.ietf.org/doc/draft-ietf-dnsop-alt-tld/ 
>>> 
>> 
>> I've read -08 and I believe I understand this draft. I'm not convinced
>> it's useful (most users of alternative resolution systems won't use it
>> and, anyway, I'm not even sure it will be added in the Special-Use
>> registry, which was wrongly frozen by the IESG) but I don't see big
>> issues with the draft, it seems to me it correctly describes the new
>> TLD.
>> 
>> Editorial :
>> 
>> Section 1:
>> 
>> "and that should not be resolved" I cannot parse it. Missing "it"?
>> 
>> Section 5 :
>> 
>> After "and anyone watching queries along the path", add a reference to
>> RFC 7626?
>> 
>> Normative references:
>> 
>> Why is RFC 6303 a normative reference? It is no longer used.
>> 
>> Why is RFC 7686 a normative reference? It is just an example.
>> 
> 
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] I-D Action: draft-ietf-dnsop-sutld-ps-03.txt

[Ralph Droms]

> On Mar 24, 2017, at 8:17 AM, Petr Špaček  wrote:
> 
> On 21.3.2017 13:23, Ralph Droms wrote:
>> Petr, thanks for your review and feedback...
>> 
>>> On Mar 15, 2017, at 6:52 AM, Petr Špaček  wrote:
>>> 
>>> On 14.3.2017 12:28, Ralph Droms wrote:
>>>> draft-ietf-dnsop-sutld-ps-03 includes revised text to address issues 
>>>> raised during the WG last call and other editorial improvements.  The list 
>>>> of issues, discussion and resolution are in GitHub: 
>>>> https://github.com/Abhayakara/draft-tldr-sutld-ps
>>>> 
>>>> There is one substantial addition to the list of problems in section 3: 
>>>> the use of DNSSEC with Special-Use Domain Names.
>>> 
>>> The 03 version is a very good one.
>>> 
>>> I would like to comment on one side-effect of the changes:
>>> The Summary section was removed and the text moved elsewhere. IMHO this
>>> makes the document less understandable to a person who was not involved
>>> with its development.
>>> 
>>> For this reason I propose new Summary section, which would be basically
>>> current 4.1.4.  Liaison Statement on Technical Use of Domain Names.
>>> 
>>> The reference to these two I-Ds can be at the same place as current 4.1.4.
>>> 
>>> 
>>> So the new text would look like:
>>> 
>>> 4.1.4.  Expired Internet Drafts Relating to SUDN
>>>  /links to/
>>>  [I-D.chapin-additional-reserved-tlds]
>>>  [I-D.grothoff-iesg-special-use-p2p-names]
>>> 
>>> 6. Summary
>>>  As a result of processing requests to add names to the Special-Use
>>>  Domain Name registry, as documented in
>>>  [I-D.chapin-additional-reserved-tlds] and
>>>  [I-D.grothoff-iesg-special-use-p2p-names], the IAB initiated a review
>>>  of the process defined in RFC 6761 for adding names to the registry.
>>>  This review was identified as in the charter of the IETF DNSOP
>>>  working group, and the review has been conducted in that working
>>>  group.  The Liaison Statement [SDO-IAB-ICANN-LS] notified ICANN of
>>>  the review, affirmed that the discussion would be "open and
>>>  transparent to participation by interested parties" and explicitly
>>>  invited members of the ICANN community to participate.
>>>  This document is a product of the IETF DNSOP working group review of
>>>  the registry process in RFC 6761.
>>> 
>>> 
>>> I believe that original 4.1.4 nicely summarizes what this document is about.
>> 
>> I agree that some of the text belongs in a more prominent place, to alert 
>> the reader to the process behind the document.  I've opened an issue: 
>> draft-ietf-homenet-dot-03
>> 
>> Our proposed solution is to move some of the detail behind this document 
>> from section 4.1.4 to the Introduction.
>> 
>> OLD:
>> 
>> 1.  Introduction
>> 
>>   [...]
>> 
>>   Special-Use Domain Names [RFC6761] created an IANA registry for
>>   Special-Use Domain Names [SDO-IANA-SUDR], defined policies for adding
>>   to the registry, and made some suggestions about how those policies
>>   might be implemented.  Since the publication of RFC 6761, the IETF
>>   has been asked to designate several new Special-Use Domain Names in
>>   this registry.  During the evaluation process for these Special-Use
>>   Domain Names, the IETF encountered several different sorts of issues.
>>   Because of this, the IETF has decided to investigate the problem and
>>   decide if and how the RFC 6761 process can be improved, or whether it
>>   should be deprecated.
>> 
>> NEW:
>> 
>> 1.  Introduction
>> 
>>   [...]
>> 
>>   Special-Use Domain Names [RFC6761] created an IANA registry for
>>   Special-Use Domain Names [SDO-IANA-SUDR], defined policies for adding
>>   to the registry, and made some suggestions about how those policies
>>   might be implemented.  Since the publication of RFC 6761, the IETF
>>   has been asked to designate several new Special-Use Domain Names in
>>   this registry.  During the evaluation process for these Special-Use
>>   Domain Names, the IETF encountered several different sorts of issues.
>>   Because of this, the IETF has decided to investigate the problem and
>>   decide if and how the RFC 6761 process can be improved, or whether it
>>   should be deprecated.  The IETF DSNOP working group charter was
>>   extended to include conducting a review of the process for adding
>>   n

Re: [DNSOP] .arpa

[Ralph Droms]

> On Mar 23, 2017, at 5:54 PM, Ted Lemon  wrote:
> 
> On Mar 23, 2017, at 5:47 PM, Ralph Droms  wrote:
>> As Matt Larson just pointed out, "different protocol" may turn into a 
>> distraction.  .homenet is asking for an entry in the special-use domain name 
>> registry and a specific kind of entry in the DNS root zone.  I take those 
>> characteristics to differentiate homenet, perhaps as an extension or variant 
>> of DNS.
> 
> Is this even necessary?

"this" == "differentiate homenet from DNS"?

>   The MoU uses the example of in-addr.arpa, which is resolved using the DNS 
> protocol, so from the perspective of the MoU, I don't think it is.
> 

I was mostly referring to the idea that DNSSEC will work because the homenet 
name resolution mechanism is "just DNS".  I thought it was important to point 
out that homenet name resolution isn't exactly DNS, so we should be careful to 
make assumptions about its behavior based on DNS.

- Ralph

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] .arpa

[Ralph Droms]

> On Mar 23, 2017, at 2:30 PM, Ted Lemon  wrote:
> 
> On Mar 23, 2017, at 2:11 PM, Ralph Droms  wrote:
>> No snark intended, but if "the protocol" were really just DNS, we wouldn't 
>> be having this discussion.  Rather, it is the DNS wire protocol using a 
>> local resolution context rather than the root zone.  In any event, yes, the 
>> locally server homenet zone can function with DNSSEC.
> 
> So do locally-served zones, by this definition, use a different protocol?

As Matt Larson just pointed out, "different protocol" may turn into a 
distraction.  .homenet is asking for an entry in the special-use domain name 
registry and a specific kind of entry in the DNS root zone.  I take those 
characteristics to differentiate homenet, perhaps as an extension or variant of 
DNS.

- Ralph

> 

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] .arpa

[Ralph Droms]

> On Mar 23, 2017, at 1:50 PM, Ray Bellis  wrote:
> 
> 
> 
> On 23/03/2017 10:34, Suzanne Woolf wrote:
> 
>> I’m trying to make sure I understand what the special use reservation
>> accomplishes in the absence of the insecure delegation.
>> 
>> If I read your comment correctly, I can infer two things about the
>> protocol, whether the insecure delegation is delayed or refused, at
>> least in the short term:
>> 
>> 1. The protocol is sufficiently functional for deployment without
>> working capability for DNSSEC validation.
> 
> Correct, in so much as "the protocol" is actually "DNS".

No snark intended, but if "the protocol" were really just DNS, we wouldn't be 
having this discussion.  Rather, it is the DNS wire protocol using a local 
resolution context rather than the root zone.  In any event, yes, the locally 
server homenet zone can function with DNSSEC.

As I see the situation, a problem arises if there is a requirement for DNSSEC 
at some point in the future, and ".homenet" is found to be unusable as the 
special-use domain name.  It would be unfortunate to deploy devices with 
".homenet" now and find that needs to be changed in the future.

> 
> The HNCP protocol is only used to configure the domain name used for
> local resolution, but Homenet's zeroconf nature requires that there be a
> default value, and as such Homenet / HNCP is not fully deployable
> without an agreed default.
> 
> The presence of ".home" as that default in RFC 7788 was a mistake, and
> the current pair of drafts is our attempt to rectify that.
> 
> Hence w.r.t Matt Pounsett's argument that the -redact document go first
> and then the assignment of ".homenet" be done later, the Homenet WG has
> argued *very* strongly that this is not acceptable because it leaves
> HNCP in an indeterminate state.

On the other hand, not publishing -redact now leaves ".home" in an 
indeterminate state in an Internet Standard, for example relative to the TLD 
assignment process in ICANN.

> 
>> 2. Having a single-label name is more important for the functioning
>> of the protocol than having DNSSEC validation work.
>> 
>> Is this a fair assessment of the WG’s view?
> 
> Not quite - DNSSEC should work correctly on any Homenet resolver which
> has the appropriate trust anchor configured.
> 
> The insecure delegation is required to allow validating stub resolvers
> in hosts to access .homenet names without the signed proof of
> non-existence that's currently in the root from getting in the way.
> 
> Since those validating stubs are currently exceedingly rare, we can live
> without that insecure delegation _for now_.

Again, I'll argue that "for now" is a potentially problematic way of looking at 
the issue, considering there may be several years of deployment between the 
selection of .homenet as an SUDN and determination of whether or not the 
necessary entry in the root zone can be added.

- Ralph

> 
> Ray
> 
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] .arpa

[Ralph Droms]

> On Mar 23, 2017, at 1:34 PM, Suzanne Woolf  wrote:
> 
> Hi Ray,
> 
>> On Mar 23, 2017, at 1:24 PM, Ray Bellis  wrote:
>> 
>> I consider them to be _independent_.  The special use reservation
>> mustn't be held up waiting for the requested insecure delegation.
> 
> I’m trying to make sure I understand what the special use reservation 
> accomplishes in the absence of the insecure delegation.
> 
> If I read your comment correctly, I can infer two things about the protocol, 
> whether the insecure delegation is delayed or refused, at least in the short 
> term:
> 
> 1. The protocol is sufficiently functional for deployment without working 
> capability for DNSSEC validation.

Clarification: does this mean "without DNSSEC validation initially but DNSSEC 
validation is needed eventually" or  "even if DNSSEC validation is never 
available"?

- Ralph

> 
> 2. Having a single-label name is more important for the functioning of the 
> protocol than having DNSSEC validation work.
> 
> Is this a fair assessment of the WG’s view?
> 
> 
> thanks,
> Suzanne
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] .arpa

[Ralph Droms]

> On Mar 22, 2017, at 1:11 PM, Andrew Sullivan  wrote:
> 
> Hi,
> 
> On Wed, Mar 22, 2017 at 09:19:24AM -0700, Ray Bellis wrote:
>> Arguably I'm not "typical", but IMHO we shouldn't be designing for the
>> lowest common denominator.
> 
> That argument is absurd on the face of it, because anyone sufficiently
> clueful about systems to be using ssh or hand-entering domain names is
> also sufficiently clueful to recognize that maybe they should use the
> google search result that pertains to networking rather than the US
> DoD.  (Presumably these are the same people who have figured out that
> iab.org and iab.com are not the same organizations.)  Therefore,
> homenet.arpa would work just fine for such people, there'd be no
> design for LCD, and also we'd get something that would work and
> wouldn't involve a constitutional crisis for IANA.
> 
>> Either way, the Homenet WG has reached its consensus decision to request
>> ".homenet" rather than ".homenet.arpa".
> 
> Since the point of this discussion is to inform IETF consensus,
> HOMENET's consensus is not the only thing that counts.  It is entirely
> possible that HOMENET's consensus will not be the IETF consensus.
> 
>> To those that say "no insecure delegations in the root zone" because
>> "DNSSEC is good"
> 
> I don't think anyone is saying anything about that.  The point is that
> _someone else_ gets to decide.  The IETF has literally no say in the
> decision about what goes in the root zone itself, and hasn't since the
> IETF signed its MoU with ICANN.  (Some argue that for this reason the
> IETF must never allocate a top-level label.  I do not agree with them,
> but there is absolutely no question about whether we are in a position
> to decide actual registrations in the root zone.)
> 
> The plain fact is that the IETF IANA considerations in
> draft-ietf-homenet-dot-03 makes a request of IANA that the IETF has no
> business making, because we are requesting an entry in a registry
> whose policy is controlled by someone else.  It's clear that the
> weasel words "arrange for" are there to pretend we're not making such
> a request it, but the MUST NOT be signed is an attempt to specify
> protocol operation in a registry where we have no business working.
> If this proceeds as IETF consensus, it will be apparent that it is the
> IETF, not ICANN, that threatens the stability of the IANA
> arrangements.  I hope we do not have to explore that rathole in my
> lifetime.

I agree that the request is misdirected toward IANA and misplaced in an "IANA 
Considerations" section.  If the IETF consensus is to find a way to instantiate 
the appropriate entry in the root zone, such an instantiation should 
acknowledge several realities and recognize that IETF is making a request of 
ICANN.  It seems to me homenet-dot should be revised:

* take the relevant text out of the IANA considerations section
* add a section that
  - motivates and explicitly defines the desired entry in the root zone
  - suggests that a request be made directly to ICANN 
  - explicitly points out that no process for such a request exists, and it 
might be necessary for IETF and ICANN to develop a mutually acceptable process 
before the request from .homenet can be considered
  - asks for IETF advice on this plan

- Ralph

> 
> Best regards,
> 
> A (speaking, of course, for myself)
> 
> -- 
> Andrew Sullivan
> a...@anvilwalrusden.com
> 
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] WG review of draft-ietf-homenet-dot-03

[Ralph Droms]

> On Mar 21, 2017, at 2:34 PM, Tim Chown  wrote:
> 
>> On 21 Mar 2017, at 17:30, Suzanne Woolf  wrote:
>> 
>> Jim,
>> 
>> In the interests of preserving a distinction here that I believe is 
>> important: 
>> 
>>> On Mar 21, 2017, at 10:01 AM, Jim Reid  wrote:
>>> 
>>> 
 On 21 Mar 2017, at 13:54, Paul Wouters  wrote:
 
 Suggesting we postpone .homenet while figuring out a new IETF/ICANN
 process, something that can take years, would basically doom this rename
 and install .home as the defacto standard.
>>> 
>>> At the risk of pouring petrol on the fire, .home *is* the defacto standard. 
>>> Queries for this TLD account for ~4% of the 2016 DITL root server traffic. 
>>> That's more than every delegated TLD except .com and .net. And the traffic 
>>> for .home has been increasing in both absolute and relative terms in recent 
>>> years. 3-4 years ago, it was ~3% of the DITL data set.
>> 
>> “Lots of queries for .home” doesn’t imply that it’s a “defacto standard” for 
>> anything in particular.
>> 
>> Is there any evidence connecting the use of the string “.home” in queries to 
>> the DNS with any particular protocol, type of equipment, network 
>> configuration, or software? 
> 
> In the UK, I believe the largest residential ISP has used the .home suffix on 
> millions of its CPEs for several years.

Do you happen to know how names with the .home suffix are resolved?

- Ralph

> 
> How much of that leaks is another question.
> 
> Tim
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] WG review of draft-ietf-homenet-dot-03

[Ralph Droms]

> On Mar 21, 2017, at 10:12 AM, Paul Wouters  wrote:
> 
>> On Tue, 21 Mar 2017, Ralph Droms wrote:
>> 
>> If draft-ietf-homenet-dot-03 specified homenet.arpa, the IETF could assign 
>> as many different names as wanted for different scoping scenarios, without 
>> interacting with ICANN for each assignment.
> 
> arpa is a loaded name for some non-US citizens.
> 
> localnet.ietf ? :P

Fine suggestion...would require just one interaction with ICANN, then the IETF 
can assign whatever names are requested.

- Ralph

> 
> Paul

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] WG review of draft-ietf-homenet-dot-03

[Ralph Droms]

> On Mar 21, 2017, at 10:05 AM, Philip Homburg  
> wrote:
> 
>> This .home / .homenet issue has already been going on for a very
>> long time. The longer we wait with resolving this issue, the worse
>> the deployment situation will be of software mixing .home vs
>>> homenet.
> 
> Do we really expect homenet to be only ever used in a 'home'? It seems to
> me that homenet is an interesting technology that would work in any small 
> IPv6 network, i.e. a small office. 
> 
> In that context, using the string 'homenet' would be very confusing to users
> outside a home context. Maybe reserving a name that has less context would
> be better.

If draft-ietf-homenet-dot-03 specified homenet.arpa, the IETF could assign as 
many different names as wanted for different scoping scenarios, without 
interacting with ICANN for each assignment.

Just sayin'

- Ralph

> 
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] WG review of draft-ietf-homenet-dot-03

[Ralph Droms]

> On Mar 21, 2017, at 12:22 AM, Andrew Sullivan  wrote:
> 
> Hi,
> 
> On Mon, Mar 20, 2017 at 01:14:25PM -0400, Ralph Droms wrote:
> 
>> Russ - In my opinion, the special-use domain registry is not being
>> used to put the name in the root zone.  The observation is that the
>> special-use definition of this TLD requires both an entry in the
>> special-use domain name registry, and an entry in the root zone
> 
> I am having a hard time making the above two sentences consistent.
> This special-use case requires an entry in the root zone, and so by
> definition the entry into one (the special-use registry) with
> processing rules that require normal DNS processing, combined with the
> request for a provably-insecure delegation, is either incoherent or
> else links the two registries.  I don't know which it is, but I see no
> way it can be other than one of them.

Let me try again...  As I see the process, draft-ietf-homenet-dot-03 defines 
the protocol behaviors for ".homenet".  draft-ietf-homenet-dot-03 requests an 
entry in the root zone for .homent and an entry in the special-use names 
registry.  While those two actions are related, and the entry in the 
special-use names registry may describe behavior that depends on the entry in 
the root zone, I think of the request for the entry in the root zone as coming 
explicitly from draft-ietf-homenet-dot-03 rather than implicitly from the entry 
in the special-use names registry.

The point I'm trying to make is that making the entry in the special-use names 
registry is not a back door to an entry in the root zone.  The request for the 
entry in the root zone has to be explicit; in this case, in 
draft-ietf-homenet-dot-03.

- Ralph

> 
> Best regards,
> 
> A
> 
> -- 
> Andrew Sullivan
> a...@anvilwalrusden.com
> 
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] WG review of draft-ietf-homenet-dot-03

[Ralph Droms]

Ted - has the operation of .homenet, as described in draft-ietf-homenet-dot-03, 
been demonstrated?

- Ralph

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] I-D Action: draft-ietf-dnsop-sutld-ps-03.txt

[Ralph Droms]

Petr, thanks for your review and feedback...

> On Mar 15, 2017, at 6:52 AM, Petr Špaček  wrote:
> 
> On 14.3.2017 12:28, Ralph Droms wrote:
>> draft-ietf-dnsop-sutld-ps-03 includes revised text to address issues raised 
>> during the WG last call and other editorial improvements.  The list of 
>> issues, discussion and resolution are in GitHub: 
>> https://github.com/Abhayakara/draft-tldr-sutld-ps
>> 
>> There is one substantial addition to the list of problems in section 3: the 
>> use of DNSSEC with Special-Use Domain Names.
> 
> The 03 version is a very good one.
> 
> I would like to comment on one side-effect of the changes:
> The Summary section was removed and the text moved elsewhere. IMHO this
> makes the document less understandable to a person who was not involved
> with its development.
> 
> For this reason I propose new Summary section, which would be basically
> current 4.1.4.  Liaison Statement on Technical Use of Domain Names.
> 
> The reference to these two I-Ds can be at the same place as current 4.1.4.
> 
> 
> So the new text would look like:
> 
> 4.1.4.  Expired Internet Drafts Relating to SUDN
>   /links to/
>   [I-D.chapin-additional-reserved-tlds]
>   [I-D.grothoff-iesg-special-use-p2p-names]
> 
> 6. Summary
>   As a result of processing requests to add names to the Special-Use
>   Domain Name registry, as documented in
>   [I-D.chapin-additional-reserved-tlds] and
>   [I-D.grothoff-iesg-special-use-p2p-names], the IAB initiated a review
>   of the process defined in RFC 6761 for adding names to the registry.
>   This review was identified as in the charter of the IETF DNSOP
>   working group, and the review has been conducted in that working
>   group.  The Liaison Statement [SDO-IAB-ICANN-LS] notified ICANN of
>   the review, affirmed that the discussion would be "open and
>   transparent to participation by interested parties" and explicitly
>   invited members of the ICANN community to participate.
>   This document is a product of the IETF DNSOP working group review of
>   the registry process in RFC 6761.
> 
> 
> I believe that original 4.1.4 nicely summarizes what this document is about.

I agree that some of the text belongs in a more prominent place, to alert the 
reader to the process behind the document.  I've opened an issue: 
draft-ietf-homenet-dot-03

Our proposed solution is to move some of the detail behind this document from 
section 4.1.4 to the Introduction.

OLD:

1.  Introduction

   [...]

   Special-Use Domain Names [RFC6761] created an IANA registry for
   Special-Use Domain Names [SDO-IANA-SUDR], defined policies for adding
   to the registry, and made some suggestions about how those policies
   might be implemented.  Since the publication of RFC 6761, the IETF
   has been asked to designate several new Special-Use Domain Names in
   this registry.  During the evaluation process for these Special-Use
   Domain Names, the IETF encountered several different sorts of issues.
   Because of this, the IETF has decided to investigate the problem and
   decide if and how the RFC 6761 process can be improved, or whether it
   should be deprecated.

NEW:

1.  Introduction

   [...]

   Special-Use Domain Names [RFC6761] created an IANA registry for
   Special-Use Domain Names [SDO-IANA-SUDR], defined policies for adding
   to the registry, and made some suggestions about how those policies
   might be implemented.  Since the publication of RFC 6761, the IETF
   has been asked to designate several new Special-Use Domain Names in
   this registry.  During the evaluation process for these Special-Use
   Domain Names, the IETF encountered several different sorts of issues.
   Because of this, the IETF has decided to investigate the problem and
   decide if and how the RFC 6761 process can be improved, or whether it
   should be deprecated.  The IETF DSNOP working group charter was
   extended to include conducting a review of the process for adding
   names to the registry that is defined in RFC 6761. This document is a
   product of that review.

OLD:

4.1.4.  Liaison Statement on Technical Use of Domain Names

   As a result of processing requests to add names to the Special-Use
   Domain Name registry, as documented in
   [I-D.chapin-additional-reserved-tlds] and
   [I-D.grothoff-iesg-special-use-p2p-names], the IAB initiated a review
   of the process defined in RFC 6761 for adding names to the registry.
   This review was identified as in the charter of the IETF DNSOP
   working group, and the review has been conducted in that working
   group.  The Liaison Statement [SDO-IAB-ICANN-LS] notified ICANN of
   the review, affirmed that the discussion would be "open and
   transparent to participation by interested parties" and explicitly
   invited members of the ICANN community t

Re: [DNSOP] WG review of draft-ietf-homenet-dot-03

[Ralph Droms]

> On Mar 20, 2017, at 1:08 PM, Russ Housley  wrote:
> 
> 
>> 
>>> We have a different view of the intended purpose of the special-use TLD 
>>> registry.  Sadly, the RFC does not include language that resolves this 
>>> difference.
>> 
>> I understand that we have different views.   However, I am asking you 
>> specifically to articulate _your_ view.
>> 
>> You have said that in your opinion special-use names must not be published 
>> in the root zone, but that was already obvious from what you said 
>> previously.   What I am asking you to do is explain _why_ special-use names 
>> must not be published in the root zone.
> 
> There are other processes for adding names to the root zone.  In my opinion, 
> using the special-use TLD registry as a means of putting a name, even one 
> that has a different scope and use case, is an end run around that process.

Russ - In my opinion, the special-use domain registry is not being used to put 
the name in the root zone.  The observation is that the special-use definition 
of this TLD requires both an entry in the special-use domain name registry, and 
an entry in the root zone.  There is no process at present for adding such an 
entry to the root zone.  draft-ietf-homenet-dot-03 explicitly recognizes the 
lack of such a process and that a process may need to be developed.

Seems to me the important issue is that the entry in the root zone is required 
for correct operation of the locally-served .homenet zone, even if no process 
exists for creating that entry.  The appropriate parties can collaborate to 
develop any needed processes...

- Ralph

> 
> Russ
> 
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] WGLC for draft-ietf-dnsop-sutld-ps

[Ralph Droms]

> On Mar 16, 2017, at 12:08 PM, Edward Lewis  wrote:
> 
> On 3/15/17, 20:22, "DNSOP on behalf of Russ Housley"  on behalf of hous...@vigilsec.com> wrote:
> 
>> I see that draft-ietf-dnsop-sutld-ps-03 still references 
>> I-D.lewis-domain-names, but I have not seen ant WG Last Call for that 
>> document.  What is the plan?
> 
> Just accidently saw this...I haven't been reading DNSOP much recently.
> 
> FWIW, the document ("-domain-names-") was informally attached to the IAB's 
> Names and Identifier's Program, that program was recently scuttled by the IAB 
> like, maybe, 2-3 weeks ago.  I had been wondering (but more tied up with this 
> week's ICANN meeting) what happens next, and haven't gotten around to dealing 
> with that.  In that sense "Good Question."
> 
> The domain-names draft was never considered for a DNSOP WG document as it is 
> mostly about how this is not a DNS problem.  In 2015, I did get comments from 
> folks on this list and then for most of 2016 the discussion was under the IAB 
> program.  There wasn't much discussion which is the prime reason the document 
> was in a suspended, waiting state.
> 
> The document currently has two pieces.  One is the historical narrative and 
> written to justify clarifying domain names, with "clarifying" being an action 
> not to be undertake without much consideration.  (Having written two 
> clarifications, I've learned.)  The other piece is where I wanted discussion, 
> defining domain names.
> 
> I could edit the document to include just the first piece and submit it to 
> the Independent Stream whatever, Editor.  There's not much reason not to do 
> that - it just hadn't happened while the IAB program was in place 
> (potentially adopting the document).  On the other hand, I was still 
> "discovering" some of the elements of the relevant history as late as 
> December based on the only set of comments I'd received in months (got it in 
> private email in September).
> 
> What are the chances that the Independent Stream Editor will bounce this 
> document towards DNSOP?  So - as a question to the chairs - is it worth DNSOP 
> adopting this document (covering the history) at the risk of it being out of 
> scope for the charter, or is it better to, if the Independent Stream Editor 
> bounces this to DNSOP, reply with a "it's not our bailiwick?"
> 
> I suppose in any case there will be an IETF-wide last call before the 
> document stands a chance of being a vetted, published document.  I've just 
> never thought of any other vetting (WG) to be done.
> 
> Ed

Ed - I think your document is a valuable reference and worth publishing.  The 
first question to ask is whether you want to continue with the publication 
process.  If you do, I'm sure we can find some way to publish it.

I need to re-read the document to refresh myself on the two aspects of the 
document that you mention.  If you really are looking for IETF discussion and 
consensus on the defining domain names, a third path would be an AD-sponsored 
submission, independent of any WG.

- Ralph

> 
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] I-D Action: draft-ietf-dnsop-sutld-ps-03.txt

[Ralph Droms]

draft-ietf-dnsop-sutld-ps-03 includes revised text to address issues raised 
during the WG last call and other editorial improvements.  The list of issues, 
discussion and resolution are in GitHub: 
https://github.com/Abhayakara/draft-tldr-sutld-ps

There is one substantial addition to the list of problems in section 3: the use 
of DNSSEC with Special-Use Domain Names.

In the authors' opinion, draft-ietf-dnsop-sutld-ps-03 addresses all of the WG 
last call issues and the document is ready to be forwarded to the IESG.

- Ralph


> On Mar 13, 2017, at 3:26 PM, internet-dra...@ietf.org wrote:
> 
> 
> A New Internet-Draft is available from the on-line Internet-Drafts 
> directories.
> This draft is a work item of the Domain Name System Operations of the IETF.
> 
>Title   : Special-Use Domain Names Problem Statement
>Authors : Ted Lemon
>  Ralph Droms
>  Warren Kumari
>   Filename: draft-ietf-dnsop-sutld-ps-03.txt
>   Pages   : 27
>   Date: 2017-03-13
> 
> Abstract:
>   The Special-Use Domain Names IANA registry policy defined in RFC 6761
>   has been shown through experience to present unanticipated
>   challenges.  This memo presents a list, intended to be comprehensive,
>   of the problems that have been identified.  In addition it reviews
>   the history of Domain Names and summarizes current IETF publications
>   and some publications from other organizations relating to Special-
>   Use Domain Names.
> 
> 
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-dnsop-sutld-ps/
> 
> There's also a htmlized version available at:
> https://tools.ietf.org/html/draft-ietf-dnsop-sutld-ps-03
> 
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-sutld-ps-03
> 
> 
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
> 
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
> 
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] draft-ietf-dnsop-sutld-ps and draft-ietf-dnsop-alt-tld

[Ralph Droms]

> On Mar 12, 2017, at 7:10 AM, Jari Arkko  wrote:
> 
> For what it is worth, reviewed these documents today
> as an interested individual, and both seem to be OK
> from my (very limited DNS expertise) perspective.
> 
> Thanks for your work on this important space.

And thank you for your review and comments.

> 
> I did have a few mostly editorial comments though.
> 
> In sutld-ps, Section 3:
> 
>  There are several different types of names in the root of the
>  Domain Namespace:
> 
> It would be beneficial to phrase this as a problem, as in what
> issues the fact that there are different types causes.

In the -03 rev of the doc (pre-publication version available here: 
https://github.com/Abhayakara/draft-tldr-sutld-ps 
), we moved that text up to 
the Introduction as background information.  Section 3 then includes specific 
problems that result from the fact of the different types of names.

- Ralph

> 
> Also in the same section:
> 
> The RFC 6761 process took more than ten years from
> beginning to end
> 
> Was name allocation part really 10x more than the rest of
> the protocol development? I was not paying much
> attention to the topic at the time, but I thought there
> also other issues. Also in fairness, mentioning the
> .onion process might be a more representative
> sample. (But I’m not disputing the point of this
> problem, it is real. Just wondering if we can be more
> accurate about the description.)
> 
> Finally, on -alt: For the record, and realising the
> extensive discussion that the WG has had on
> these topics, but I was a bit surprised by the
> choices in -alt to not have a registry and to
> use “alt” (which I associate with some Usenet
> groups, showing my age). I’m quite fine with the
> WG’s recommendations, however.
> 
> Jari
> 
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] WGLC for draft-ietf-dnsop-sutld-ps

[Ralph Droms]

We've extracted issues from the reviews of draft-ietf-dnsop-sutld-ps posted to 
the list so far, and entered them into the GitHub repo: 
https://github.com/Abhayakara/draft-tldr-sutld-ps 
  We're tracking discussion 
and resolution for issues there, as well.  Text revisions for a few issues have 
been committed to the XML source and the associated issues have been closed.

Additional feedback during the WG last call is, of course, encouraged...

- Ralph


> On Feb 2, 2017, at 6:04 PM, Suzanne Woolf  wrote:
> 
> This message opens a Working Group Last Call for:
> 
> "Special-Use Names Problem Statement"
> https://datatracker.ietf.org/doc/draft-ietf-dnsop-sutld-ps/ 
> 
> Proposed status: informational
> 
> Starts: 2 Feb. 2017
> Ends: 23 Feb. 2017 (3 weeks)
> 
> Discussion should go to the mailing list. 
> 
> Is this draft ready to advance for publication as an Informational RFC, and 
> as guidance for possible updates to RFC 6761? Does it describe the relevant 
> issues clearly, and cover all the relevant ones that should be taken into 
> account in future work in the IETF on the special use names registry or RFC 
> 6761?
> 
> If not, can you suggest changes that would get your support for advancing it? 
> (“Send text” if possible!)
> 
> 
> thanks,
> Suzanne & Tim
> 
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] A nudge on the new terms in draft-ietf-dnsop-terminology-bis

[Ralph Droms]

Paul - I finished my review of the terminology doc; added 1 issue today.

- Ralph

> On Feb 8, 2017, at 4:31 PM, Paul Hoffman  wrote:
> 
> [[ Hopefully the WG can focus on multiple topics at once; this one has an 
> effect on the upcoming interim WG meeting. ]]
> 
> [[ We got a few responses to our earlier message about the new terms in 
> draft-ietf-dnsop-terminology-bis-04, but would certainly like to hear more. 
> From our earlier message: ]]
> 
> The authors have tentatively made some substantial changes to the draft, to 
> define "domain name", "global DNS", and "private DNS" in a manner that can be 
> used by other work in the IETF, particularly around RFC 6761. Our first cut 
> of definitions are in the new draft, but we fully expect significant 
> discussion in the WG before there is even rough consensus. We are not even 
> sure that the WG will agree with the idea of adding "global DNS" and "private 
> DNS" to the document. The authors are not even sure they agree with all of 
> this.
> 
> At the same time, we think that it would be easier to track open issues in 
> our GitHub repo at https://github.com/DNSOP/draft-ietf-dnsop-terminology-bis 
> rather than in the document as comments. To be clear, the discussion of how 
> issues are to be resolved should be mostly done on the mailing list, but 
> using GitHub to track issues might give easier-to-follow history of the 
> discussions. We also are open to using GitHub for pull requests for specific 
> changes to the document.
> 
> As a final note, this version of the draft also has some changes not related 
> to the above, and we encourage review of those changes, plus anything else in 
> the draft, of course.
> 
> --Paul Hoffman
> 
> On 27 Jan 2017, at 10:08, internet-dra...@ietf.org wrote:
> 
>> A New Internet-Draft is available from the on-line Internet-Drafts 
>> directories.
>> This draft is a work item of the Domain Name System Operations of the IETF.
>> 
>>Title   : DNS Terminology
>>Authors : Paul Hoffman
>>  Andrew Sullivan
>>  Kazunori Fujiwara
>>  Filename: draft-ietf-dnsop-terminology-bis-04.txt
>>  Pages   : 34
>>  Date: 2017-01-27
>> 
>> Abstract:
>>   The DNS is defined in literally dozens of different RFCs.  The
>>   terminology used by implementers and developers of DNS protocols, and
>>   by operators of DNS systems, has sometimes changed in the decades
>>   since the DNS was first defined.  This document gives current
>>   definitions for many of the terms used in the DNS in a single
>>   document.
>> 
>>   This document will be the successor to RFC 7719.
>> 
>> 
>> The IETF datatracker status page for this draft is:
>> https://datatracker.ietf.org/doc/draft-ietf-dnsop-terminology-bis/
>> 
>> There's also a htmlized version available at:
>> https://tools.ietf.org/html/draft-ietf-dnsop-terminology-bis-04
>> 
>> A diff from the previous version is available at:
>> https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-terminology-bis-04
> 
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] ALT-TLD and (insecure) delgations.

[Ralph Droms]

> On Feb 3, 2017, at 9:10 PM, Andrew Sullivan  wrote:
> 
> On Fri, Feb 03, 2017 at 07:59:24PM -0500, Ted Lemon wrote:
>> Mark, I don't think you've actually given an answer to my question.
>> I understood that .ALT was for alternative naming systems, not for
>> DNS locally-served zones.   We simply need to decide whether or not
>> that's true.   I think either answer is fine; we just need to pick
>> one.
> 
> I agree with this.  I will say that, when I first started working on
> this with Warren, it was really for the use-case where people would
> tread on the namespace as a protocol switch -- we wanted a sandbox in
> which things like onion could live.  My memory is that only after that
> did we start thinking of a sort of 1918-style part of the DNS as
> well.  That may have been a mistake, since as this discussion is
> showing the properties of an in-protocol, in-DNS namespace without
> delegations are somewhat different to alternative-protocol uses that
> do not rely on the DNS at all.

Andrew - I have come around to agree that the properties and requirements of 
non-DNS resolution mechanisms are different from those of DNS resolution that 
does not use the root zone as a resolution context.  I believe that these 
properties and requirements cannot be served by the single .alt delegation, so, 
in my opinion, draft-ietf-dnsop-alt-tld should specify .alt for use of non-DNS 
resolution mechanisms.

How to proceed with DNS resolution that does not use the root zone as a 
resolution context is open for discussion.

- Ralph

> 
> Best regards,
> 
> A
> 
> -- 
> Andrew Sullivan
> a...@anvilwalrusden.com
> 
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] WGLC for draft-ietf-dnsop-sutld-ps

[Ralph Droms]

Thanks for your review and comments, Russ.  I've extracted the issues from your 
review and entered them in the GitHub issue tracker for the document.

- Ralph

> On Feb 6, 2017, at 2:21 PM, Russ Housley  wrote:
> 
>> 
>> This message opens a Working Group Last Call for:
>> 
>> "Special-Use Names Problem Statement"
>> https://datatracker.ietf.org/doc/draft-ietf-dnsop-sutld-ps/ 
>> 
>> Proposed status: informational
>> 
>> Starts: 2 Feb. 2017
>> Ends: 23 Feb. 2017 (3 weeks)
>> 
>> Discussion should go to the mailing list. 
>> 
>> Is this draft ready to advance for publication as an Informational RFC, and 
>> as guidance for possible updates to RFC 6761? Does it describe the relevant 
>> issues clearly, and cover all the relevant ones that should be taken into 
>> account in future work in the IETF on the special use names registry or RFC 
>> 6761?
> 
> I think the document should be published an Informational RFC once the 
> comments are resolved.  I think it offers a good foundation for a future 
> rfc6761bis document.
> 
> I have several comments…
> 
> I think the title should be Special-Use Domain Names Problem Statement.  The 
> abstract talks about domain names, so the title should match.
> 
> Will I-D.lewis-domain-names be published as an Informational RFC as well?  If 
> not, then the Introduction needs to extract highlights from that document.
> 
> These three bullets in Section 3 overlap:
> 
>o  Both ICANN and the IETF have the authority and formal processes to
>   assign names from the pool of unused names, but no formal
>   coordination process exists.  The lack of coordination complicates
>   the management of the root of the Domain Namespace and may lead to
>   conflicts in name assignments [SDO-ICANN-SAC090].
> 
>o  The IETF and ICANN each have administrative authority over the
>   Domain Namespace.  Not all developers of protocols on the internet
>   agree that this authority should reside with the IETF and ICANN.
> 
>o  Although IETF and ICANN nominally have authority over this
>   namespace, neither organization can enforce that authority over
>   any third party who wants to just start using a subset of the
>   namespace.
> 
> I think there is one main point and two observations.  The main point is that 
> both ICANN and the IETF have the authority and formal processes to assign 
> previously unused names.  The first observation is that ICANN and the IETF 
> need to coordinate to avoid conflicts.  The second observation is that some 
> think that the authority is misplaced.  The second observation needs to be 
> expanded to state the consequence, which I assume is squatting.  If I guessed 
> correctly, the text should explain that squatting leads to conflicts.  The 
> third observation is that neither ICANN nor the IETF has any technical means 
> to prevent squatting.
> 
> I think that the Section 3 bullet on .local should explain that the amount of 
> time involved was excessive, but part of the reason was that the process for 
> special-use assignments was being invented.  As a result, .onion took much 
> less time.
> 
> I think that theSection 3  bullet that references 
> https://www.ietf.org/mail-archive/web/dnsop/current/msg14887.html 
>  should be 
> reworded.  The information in the Ed Note probably does not belong in the 
> Informational RFC.
> 
> I think that Section 4.2.5 should include a reference to the SSAC document.  
> I know it is also referenced elsewhere.
> 
> 
> And a few Nits…
> 
> The “SUDN” and “SUTLDN” acronyms are defined, but they are not used very 
> often.  I wonder is spelling it out in every case would be more clear.
> 
> In Section 3, there is bad formatting and duplicate informations in the 
> bullet about ICANN Reserved Names.  I suggest:
> s/(see [SDO-ICANN-DAG]Section 2.2.1.2.1, Reserved Names )/(seeSection 
> 2.2.1.2.1of [SDO-ICANN-DAG])
> 
> In Section 4.1.1:
> s/TOR browser/Tor Browser [TP]/
> s/connecting over TOR/connecting over the Tor network/
> 
> [TP] = https://www.torproject.org 
> 
> In Section 4.1.3:
> s/Memorandum of Understanding[RFC2860]/Memorandum of Understanding [RFC2860]/
> 
> Russ
> ___
> DNSOP mailing list
> DNSOP@ietf.org 
> https://www.ietf.org/mailman/listinfo/dnsop 
> 
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] ALT-TLD and (insecure) delgations.

[Ralph Droms]

> On Feb 6, 2017, at 10:29 AM, Ólafur Gudmundsson  wrote:
> 
> Ted,
> 
> What RFC are you referring to?
> 
> Why do you think .ARPA is for services?
> It's for infrastructure and homenet wants to join the infrastructure.
> 
> It is waste of time arguing if name A or B is better take the one you can get 
> faster.

The WG has considered the alternatives, and WG consensus is to specify 
".homenet"

- Ralph

> 
> Ólafur
> 
> 
>> On February 5, 2017 10:22:35 PM CST, Ted Lemon  wrote:
>> The working group has consensus to give it a try.  We may change our minds 
>> of it takes too long, but it seems worth exploring from a process 
>> perspective anyway. 
>> 
>> On Feb 5, 2017 11:18 PM, "John R Levine"  wrote:
 I'm pretty sure I've explained it enough times on this mailing list and in
 the relevant documents by now. If you don't agree, maybe we should just
 accept that. If you don't remember the explanation, it's in the homenet
 naming architecture doc I wrote.
>>> 
>>> Well, OK, I took another look, and from what I can see, it's a belief that 
>>> people will find toaster.homenet.arpa harder or more confusing to type than 
>>> toaster.homenet.
>>> 
>>> Just out of curiosity, how long is it worth waiting to get .homenet rather 
>>> than .homenet.arpa?  If it took five more years, which at the current rate 
>>> seems optimistic, would homenet still be relevant?
>>> 
>>> R's,
>>> John
> 
> -- 
> Sent from my Android device with K-9 Mail. Please excuse my brevity.
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] ALT-TLD and (insecure) delgations.

[Ralph Droms]

> On Feb 3, 2017, at 3:49 PM, Suzanne Woolf  wrote:
> 
> Hi,
> 
> To sharpen the question slightly….
> 
>> On Feb 1, 2017, at 5:11 PM, Ralph Droms  wrote:
>> 
>> 
>>> On Feb 1, 2017, at 4:42 PM, Mark Andrews  wrote:
>>> 
>>> 
>>> In message <1b8e640b-c38e-4b76-a73d-7178491a9...@fugue.com>, Ted Lemon 
>>> writes:
>>>> 
>>>> On Feb 1, 2017, at 3:50 PM, Ralph Droms  wrote:
>>>>>> It appears to me that requesting an insecure delegation is the right
>>>>>> thing to do, as a "technical use".  We have, so far, been very careful in
>>>>>> what we ask for.  If ICANN does not agree, then we can discuss other
>>>>>> options.
>>>>> 
>>>>> I agree.
>>>> 
>>>> I'm confused.   The .ALT TLD is expected to be used for non-DNS name
>>>> lookups.   So isn't a secure denial of existence exactly what we want for
>>>> .ALT?
>>> 
>>> No.
>>> 
>>>> What is the utility in having an un-signed delegation?
>>> 
>>> Alt can be used for whatever purpose that the user wants to use it
>>> for including names served using the DNS protocol.
>> 
>> The draft restricts use of .alt as follows:
>> 
>>  This label is intended to be used as
>>  the final (rightmost) label to signify that the name is not rooted in
>>  the DNS, and that normal registration and lookup rules do not apply.
>> 
>> ...which would lead me to believe .alt would not be used for names served 
>> using the DNS protocol.
>> 
>> However, the phrase "not rooted in the DNS" might need some clarification.
>> 
>> In particular, would ".homenet.alt" be OK, as it is a locally-served zone, 
>> not a subdomain of the root zone?
> 
> As a slightly broader question, what does the WG want .ALT to do?

Here's a starting point:

The .alt subdomain is to be used for names that are not expected to be resolved 
with the DNS protocol, and names that are expected to be resolved with the DNS 
protocol through a context other than the root zone (e.g., locally served 
zones).
> 
> More specifically, perhaps, what problems discussed in 
> draft-ietf-dnsop-sutld-ps-02.txt do we want it to solve?

Roughly speaking, and open for debate:

Reduces potential conflict between IETF and ICANN assignment of names in the 
Domain Namespace root.
Obviates the need for (most?) interpretations of "technical use".
Addresses some (but not all) of the reasons an entity might commandeer a domain 
name.
Mitigates the problem that newly utilized special use names are assumed to use 
DNS for resolution by most existing software.
Helps separate the regions of the Domain Namespace over which IETF and ICANN 
have authority.
Allows for ad hoc assignment of special use names.

This list might change depending on:

* whether IETF is still allowed to declare names in the Domain Namespace root 
for "technical use"
* there is a registry (and associated process) for names in the .alt subdomain

For example, how do we accommodate both "sitenet.alt." as designated by an 
Internet Standard and "mynewresolver.alt" as used in a local, experimental 
naming system?

- Ralph

> 
> The WG can agree to change the current text, but I think the WG needs to 
> agree on the purpose of ALT, as that seems likely to make it easier to decide 
> what behavior we want to specify for it and, in turn, how it should be 
> implemented.
> 
> 
> Suzanne
> 

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] ALT-TLD and (insecure) delgations.

[Ralph Droms]

> On Feb 1, 2017, at 3:58 PM, Ted Lemon  wrote:
> 
> On Feb 1, 2017, at 3:50 PM, Ralph Droms  wrote:
>>> It appears to me that requesting an insecure delegation is the right thing 
>>> to do, as a "technical use".  We have, so far, been very careful in what we 
>>> ask for.  If ICANN does not agree, then we can discuss other options.
>> 
>> I agree.
> 
> I'm confused.   The .ALT TLD is expected to be used for non-DNS name lookups. 
>   So isn't a secure denial of existence exactly what we want for .ALT?   What 
> is the utility in having an un-signed delegation?
> 

Sorry, I misinterpreted what I was responding to.  I think I agree with Ted 
that what we want is a signed delegation for secure denial of existence.

- Ralph

> 

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] ALT-TLD and (insecure) delgations.

[Ralph Droms]

> On Feb 1, 2017, at 4:42 PM, Mark Andrews  wrote:
> 
> 
> In message <1b8e640b-c38e-4b76-a73d-7178491a9...@fugue.com>, Ted Lemon writes:
>> 
>> On Feb 1, 2017, at 3:50 PM, Ralph Droms  wrote:
>>>> It appears to me that requesting an insecure delegation is the right
>>>> thing to do, as a "technical use".  We have, so far, been very careful in
>>>> what we ask for.  If ICANN does not agree, then we can discuss other
>>>> options.
>>> 
>>> I agree.
>> 
>> I'm confused.   The .ALT TLD is expected to be used for non-DNS name
>> lookups.   So isn't a secure denial of existence exactly what we want for
>> .ALT?
> 
> No.
> 
>>  What is the utility in having an un-signed delegation?
> 
> Alt can be used for whatever purpose that the user wants to use it
> for including names served using the DNS protocol.

The draft restricts use of .alt as follows:

   This label is intended to be used as
   the final (rightmost) label to signify that the name is not rooted in
   the DNS, and that normal registration and lookup rules do not apply.

...which would lead me to believe .alt would not be used for names served using 
the DNS protocol.

However, the phrase "not rooted in the DNS" might need some clarification.

In particular, would ".homenet.alt" be OK, as it is a locally-served zone, not 
a subdomain of the root zone?

- Ralph

> 
> The only requirement is that leaked queries for ".alt" get
> NXDOMAIN and that queries for 'alt.' get a NODATA response other
> than for SOA and NS.  Signing those answers would further constrain
> how the namespace is used.  Additionally such leaked queries should
> be answered as early as possible in the resolution processes to
> reduce the privacy exposure.
> 
> The simple way to achieve that is to recursive server serve a "empty"
> 'alt.' zone.  If there is a secure delegation then every recursive
> server would need to continually transfer a copy of that zone from
> some designated servers as the contents would need to be re-signed
> periodically.  If there is a insecure delegation then no transfer
> of zone contents is needed as the entire contents can be hard coded
> into the server with only the decision about whether to serve the
> zone or not being needed to be made.
> 
> We do this for 10.IN-ADDR.ARPA today.  The rest of the configuration
> of the server decides if 10.IN-ADDR.ARPA is automatially served
> with a way to explictly disable the serving.  For 10.IN-ADDR.ARPA
> we actually constuct a entire zone automatically as people configure
> zones like 0.0.10.IN-ADDR.ARPA and the intermediate names need to
> get a NODATA response.
> 
> Mark
> 
> -- 
> Mark Andrews, ISC
> 1 Seymour St., Dundas Valley, NSW 2117, Australia
> PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] ALT-TLD and (insecure) delgations.

[Ralph Droms]

> On Feb 1, 2017, at 3:47 PM, Bob Harold  wrote:
> 
> 
> On Wed, Feb 1, 2017 at 3:28 PM, Warren Kumari  > wrote:
> Hi there all,
> 
> I have just posted a new version of alt-tld, which folds in a number
> of suggestions and comments from various people -- thank you for
> those. As the document was parked I held off making some of the larger
> edits; if you sent comments and I missed them, I apologize - please
> send them again (or point at them) and I'll try address them.
> 
> 
> The largest outstanding issue is what to do about DNSSEC -- this is
> (potentially) a problem for any / all 6761 type names.
> The root is signed, so if a query leaks into the DNS (as they will),
> an (unaware) validating resolver will try resolve it, and will expect
> either a signed answer, or proof of an insecure delegation; without
> this things will look bogus, and so resolvers will SERVFAIL.
> 
> Clearly, a signed answer isn't feasible, so that leaves 2 options - 1:
> simply note that validation will fail, and that SERVFAIL will be
> returned in many case (to me this seems "correct"), or 2: request that
> the IANA insert an insecure delegation in the root, pointing to a:
> AS112 or b: an empty zone on the root or c" something similar.
> 
> This is a fine thing to request in an IANA consideratons, but isn't
> necessarily *useful* -- the IANA has the technical ability to add
> stuff to the root zone, but not the mandate (this is like walking into
> a bank and requesting the teller gives you a bunch of money - they may
> be able to do so, but aren't actually allowed to.. :-)).
> 
> Some people have suggested "Well, we (or the IAB) can just ask ICANN
> politely to do add this, they are in charge of the DNS root, they'll
> help out, no worries"
> Unfortunately, this is only partly accurate -- adding an (insecure)
> delegation to the root would make .alt be a "real" TLD. ICANN is just
> an organization, they are driven by a multistakeholder[0] process, and
> there is a huge amount of process and similar around creating a new
> TLD -- go read the 300+ page gTLD Applicant Guidebook (Version
> 2012-06-04 ) for a fun taste of this.
> This would likely require convincing "the naming community" that, for
> some reason the IETF is special and should get a "free"[1] TLD, and
> that it is exempt from, well, basically all of the existing
> requirements.
> 
> I'd started putting some strawman text into the draft[2], so that we
> could have something concrete to discuss and poke holes in, but ripped
> it out because it was clearly not going to fly / pure fiction...
> 
> So, what do we want to do here? This is a WG document, the authors
> will (of course) do whatever the WG wants, but my personal view is
> that asking for an insecure delegation, while technically superior, is
> simply not realistic.
> 
> This discussion is somewhat about .alt, but other special use names
> will likely have the same issues and concerns, and so we should
> consider this in the larger context.
> 
> For example, homenet already has had some of this discussion -- see:
> https://mailarchive.ietf.org/arch/search/?email_list=homenet&q=+On+the+TLD+question+and+validatably-insecure+delegation
>  
> 
> 
> 
> W
> [0]: By law, all mentions of ICANN require the use of the word
> "mutistakeholder"Hey, this is no more crazy than some of the other
> new rules
> 
> [1]: Yeah, 'tis not a useable TLD in that you cannot sell names and
> have them work in the DNS, but this is fairly subtle...
> 
> [2]:
> --
> [ Editor note: This section is a strawman (and so is more
> conversational than expected for the final version) -- it is likely to
> change significantly, or more likely, be removed entirely. ]
> 
> The point of adding this entry to the "Special-Use Domain Name"
> registry is to create a namespace which can be used for alternate
> resolution contexts, and which will not collide with entries in the
> IANA DNS root.
> 
> Unfortunately, queries will still leak into the DNS, and, as the DNS
> root zone is signed, validating resolvers which are unaware of .alt
> will attempt to DNSSEC validate responses. If there is not an insecure
> delgation for .alt, DNSSEC validation will fail, and validating
> resolvers will return SERVFAIL, causing additional lookups or other
> unexpected behavior.
> 
> In order to avoid this, the IANA is requested to add an insecure
> delegation to the root-zone, delegating .alt to AS112 nameservers (or
> to an empty zone on hosted by the root).
> --
> 
> 
> It appears to me that requesting an insecure delegation is the right thing to 
> do, as a "technical use".  We have, so far, been very careful in what we ask 
> for.  If ICANN does not agree, then we can discuss other options.

I agree.

- Ralph

> 
> -- 
> Bob Harold
>  
> 
> ___

Re: [DNSOP] Terminology issue #8: context

[Ralph Droms]

> On Jan 29, 2017, at 5:32 PM, Paul Hoffman  wrote:
> 
> On 29 Jan 2017, at 5:26, Ralph Droms wrote:
> 
>>> On Jan 28, 2017, at 4:22 PM, Paul Hoffman  wrote:
>>> 
>>> On 28 Jan 2017, at 12:28, Ralph Droms wrote:
>>> 
>>>> I've submitted three issues to the doc repo:
>>>> 
>>>> Issue #8: 
>>>> https://github.com/DNSOP/draft-ietf-dnsop-terminology-bis/issues/8 
>>>> <https://github.com/DNSOP/draft-ietf-dnsop-terminology-bis/issues/8>
>>>> 
>>>> Add "context" as a facet in the definition of a naming system.  A naming 
>>>> system needs a context in which to perform resolution of a name.  As an 
>>>> example, "locally served DNS zones" (see Issue #10) use the DNS resolution 
>>>> mechanism through a local context rather than through the global root.
>>> 
>>> Is that "context" or "possible contexts"? That is, if you consider 
>>> 1034/1035 as a naming scheme, it seems like there could be "the global 
>>> context" (the root servers that everyone assumed then) and "a local 
>>> context" (hosts.txt) or even a mixed context ("first try to resolve in 
>>> hosts.txt but then go to the root servers if you get an NXDOMAIN", or even 
>>> the reverse of that). Some naming schemes might have other interesting 
>>> mixes of context.
>>> 
>>> But I agree that something like this is a common, and commonly-ignored, 
>>> facet that would be useful to list.
>> 
>> I see your point about "possible contexts".  I was thinking of what's needed 
>> for the evaluation of one specific name.  Another way to describe the facet 
>> is what are the possible contexts.
>> 
>> How about:
>> 
>> * Contexts that can be used for resolving a name and obtaining its 
>> associated data, and the way in which a context is specified for resolution 
>> of a name
> 
> I'm OK with that for now, but hope that, after we have a definition for 
> "resolve", that we can remove the "and obtaining its associated data" because 
> that's part of resolving. (Maybe. Hopefully.)

Hm.  I hadn't noticed I used the words "resolving" and "resolution" without 
definition (either mine or elsewhere in the doc).  I'll also admit that I'm 
still framing this discussion in my head in terms of my PhD work of 30 years 
ago, when papers by Shoch and Saltzer were a little more current and we had a 
lot less operational experience cluttering the conversation.

Looking back more carefully at the other facets of a naming system, how about:

* Contexts in which the protocol is applied to get data from a name, and the 
way in which a context is specified for that application of the protocol

> 
>> I'd like to discuss your example a little.  In my opinion, hosts.txt lookup 
>> and DNS are two different naming systems.  They happen to share the same 
>> name syntax but use different resolution methods.  The client name 
>> resolution code gets handed a name from an app, and then uses one or more 
>> naming systems - in sequence, if more than one - to resolve the name.  In 
>> your example, the client code might go to the hosts.txt naming system first 
>> and then the DNS naming system.
> 
> Client code often goes to a stub resolver (which we do define in 7719). A 
> stub resolver might use the sequence I gave above; in fact, we know of ones 
> that do. So a naming system might go through different mechanisms when doing 
> resolution.

Following the pointers to RFC 1123, it seems a stub resolver only performs DNS 
name resolution.  Not meaning to be pedantic, in my opinion there is another 
type of resolution mechanism in a client, which chooses between different 
naming systems and contexts, one of which is the global DNS (accessed through 
the stub resolver).  I understand that draft-ietf-dnsop-terminology-bis is 
about DNS terminology, but if we agree about that mechanism for choosing among 
naming systems, we should consider naming and defining it in 
draft-ietf-dnsop-terminology-bis.

> 
>> But I'm quite naive about the details and it may be common practice to 
>> consider both hosts.txt and DNS server resolution part of the DNS naming 
>> system.
> 
> Fortunately, it is not common on the Internet with respect to the global DNS. 
> Unfortunately, when it does happen, it causes collisions to have negative 
> consequences when names (not just new TLDs) are added to the DNS.

Thanks for the clarification...

- Ralph

> 
> --Paul Hoffman

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Terminology issue #8: context

[Ralph Droms]

> On Jan 28, 2017, at 4:22 PM, Paul Hoffman  wrote:
> 
> On 28 Jan 2017, at 12:28, Ralph Droms wrote:
> 
>> I've submitted three issues to the doc repo:
>> 
>> Issue #8: https://github.com/DNSOP/draft-ietf-dnsop-terminology-bis/issues/8 
>> <https://github.com/DNSOP/draft-ietf-dnsop-terminology-bis/issues/8>
>> 
>> Add "context" as a facet in the definition of a naming system.  A naming 
>> system needs a context in which to perform resolution of a name.  As an 
>> example, "locally served DNS zones" (see Issue #10) use the DNS resolution 
>> mechanism through a local context rather than through the global root.
> 
> Is that "context" or "possible contexts"? That is, if you consider 1034/1035 
> as a naming scheme, it seems like there could be "the global context" (the 
> root servers that everyone assumed then) and "a local context" (hosts.txt) or 
> even a mixed context ("first try to resolve in hosts.txt but then go to the 
> root servers if you get an NXDOMAIN", or even the reverse of that). Some 
> naming schemes might have other interesting mixes of context.
> 
> But I agree that something like this is a common, and commonly-ignored, facet 
> that would be useful to list.

I see your point about "possible contexts".  I was thinking of what's needed 
for the evaluation of one specific name.  Another way to describe the facet is 
what are the possible contexts.

How about:

* Contexts that can be used for resolving a name and obtaining its associated 
data, and the way in which a context is specified for resolution of a name

I'd like to discuss your example a little.  In my opinion, hosts.txt lookup and 
DNS are two different naming systems.  They happen to share the same name 
syntax but use different resolution methods.  The client name resolution code 
gets handed a name from an app, and then uses one or more naming systems - in 
sequence, if more than one - to resolve the name.  In your example, the client 
code might go to the hosts.txt naming system first and then the DNS naming 
system.

But I'm quite naive about the details and it may be common practice to consider 
both hosts.txt and DNS server resolution part of the DNS naming system.

- Ralph

> 
> --Paul Hoffman

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Big changes in draft-ietf-dnsop-terminology-bis

[Ralph Droms]

I've submitted three issues to the doc repo:

Issue #8: https://github.com/DNSOP/draft-ietf-dnsop-terminology-bis/issues/8 


Add "context" as a facet in the definition of a naming system.  A naming system 
needs a context in which to perform resolution of a name.  As an example, 
"locally served DNS zones" (see Issue #10) use the DNS resolution mechanism 
through a local context rather than through the global root.

Issue #9: https://github.com/DNSOP/draft-ietf-dnsop-terminology-bis/issues/9 


In the definition of "global DNS", add a description of the context to be used 
for the resolution of names under "global DNS"

Issue #10: https://github.com/DNSOP/draft-ietf-dnsop-terminology-bis/issues/10 


Add a new definition for "locally served DNS names", as defined in RFC 6303.  
This definition is likely to be useful in the specification of the home network 
DNS context, which is currently a work item for the homenet WG.

- Ralph

> On Jan 27, 2017, at 1:12 PM, Paul Hoffman  wrote:
> 
> The authors have tentatively made some substantial changes to the draft, to 
> define "domain name", "global DNS", and "private DNS" in a manner that can be 
> used by other work in the IETF, particularly around RFC 6761. Our first cut 
> of definitions are in the new draft, but we fully expect significant 
> discussion in the WG before there is even rough consensus. We are not even 
> sure that the WG will agree with the idea of adding "global DNS" and "private 
> DNS" to the document. The authors are not even sure they agree with all of 
> this.
> 
> At the same time, we think that it would be easier to track open issues in 
> our GitHub repo at https://github.com/DNSOP/draft-ietf-dnsop-terminology-bis 
> rather than in the document as comments. To be clear, the discussion of how 
> issues are to be resolved should be mostly done on the mailing list, but 
> using GitHub to track issues might give easier-to-follow history of the 
> discussions. We also are open to using GitHub for pull requests for specific 
> changes to the document.
> 
> As a final note, this version of the draft also has some changes not related 
> to the above, and we encourage review of those changes, plus anything else in 
> the draft, of course.
> 
> --Paul Hoffman
> 
> On 27 Jan 2017, at 10:08, internet-dra...@ietf.org wrote:
> 
>> A New Internet-Draft is available from the on-line Internet-Drafts 
>> directories.
>> This draft is a work item of the Domain Name System Operations of the IETF.
>> 
>>Title   : DNS Terminology
>>Authors : Paul Hoffman
>>  Andrew Sullivan
>>  Kazunori Fujiwara
>>  Filename: draft-ietf-dnsop-terminology-bis-04.txt
>>  Pages   : 34
>>  Date: 2017-01-27
>> 
>> Abstract:
>>   The DNS is defined in literally dozens of different RFCs.  The
>>   terminology used by implementers and developers of DNS protocols, and
>>   by operators of DNS systems, has sometimes changed in the decades
>>   since the DNS was first defined.  This document gives current
>>   definitions for many of the terms used in the DNS in a single
>>   document.
>> 
>>   This document will be the successor to RFC 7719.
>> 
>> 
>> The IETF datatracker status page for this draft is:
>> https://datatracker.ietf.org/doc/draft-ietf-dnsop-terminology-bis/
>> 
>> There's also a htmlized version available at:
>> https://tools.ietf.org/html/draft-ietf-dnsop-terminology-bis-04
>> 
>> A diff from the previous version is available at:
>> https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-terminology-bis-04
> 
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] getting back to our work on special use names

[Ralph Droms]

> On Jan 13, 2017, at 9:47 PM, Warren Kumari  wrote:
> 
> 
> 
> On Thu, Jan 12, 2017 at 1:41 PM Suzanne Woolf  wrote:
> Dear Colleagues,
> 
> 
> It's time to get back to our work on special use names. As the chairs see it, 
> here's what we need to do between now and IETF 98 (end of March).  We'll be 
> having a DNSOP WG interim meeting shortly, see below.
> 
> 1. We need to advance the problem statement document, 
> https://datatracker.ietf.org/doc/draft-ietf-dnsop-sutld-ps/. Please review 
> and comment on the list. We'd like to have a WGLC on it before IETF 98.
> 
> 
> Some additional background.
> The ICANN SSAC (Security and Stability Advisory Committee) recently (Dec 
> 22nd) published SAC090 - 
> https://www.icann.org/en/system/files/files/sac-090-en.pdf (full disclosure: 
> I'm an author).
> 
> It is short, and easily readable -- I'd strongly encourage you to read it 
> (but I'll provide some teasers to tempt you!).
> It notes that "a central authority to control the way in which domain names 
> are used in all contexts-is both infeasible and undesirable given the 
> robustly non-centralized way in which the Internet ecosystem evolves", and 
> that a coordinated management of the namespace might be best. 
> It also finds that uncoordinated use leads to ambiguity (and instability), 
> and that currently ICANN and the IETF (and others) all allocate from a single 
> namespace.
> It recommends that ICANN
> 1: create criteria for determining what labels can be TLDs.
> 2: figure out how to coordinate with a: the IETF declaring names as "special" 
> (6761) and b: other "private use" names. 

I read SAC090 and also recommend that others read it.  The second 
recommendation affects the IETF and, specifically, would address some of the 
problems listed in draft-ietf-dnsop-sutld-ps.

I've reviewed draft-ietf-dnsop-sutld-ps and added some text citing SAC090; 
we'll publish that new revision soon.

> 
> This is a very quick summary, please go actually read it - there are only ~6 
> pages of actual content, but it recommends coordination with the IETF. So, 
> please, let's try and get this moving -- I'd hate it if the IETF ends up 
> looking more dysfunctional than ICANN :-P
> 
> 
> Also, ~3 days ago someone posted about .onion (and Special Use Names) on 
> hackernews -- https://news.ycombinator.com/item?id=13370488 . This topic is 
> still of interest to a bunch of people...
> 
>  
> 2. Now that we have a working problem statement, we'd like to see proposals 
> on possible changes to IETF procedures to resolve the issues we've raised. 
> We're looking for on-list discussion, preferably with posted I-Ds.
> 
> These proposals do not have to be limited to work for the DNSOP WG; they may 
> also include work we think belongs in other WGs, or requests to the IESG or 
> the IAB (such as liaison statements to groups outside of the IETF).
> 
> We have had a proposal, for the ALT TLD, before us for some time now, which 
> we put aside while we worked on the problem statement. As part of assessing 
> solutions, we need to review 
> https://datatracker.ietf.org/doc/draft-ietf-dnsop-alt-tld/ and determine what 
> the WG wants to do with it. Comments to the list, please.
> 
> Yes please. The document is still parked, but please send me comments *on the 
> draft* and I'll try keep track of them to incorporate. I know that there is 
> much background which can be culled, I'll post a new version to GitHub with 
> that done soon.

Now that we have draft-ietf-dnsop-sutld-ps, would there be any benefit to 
revising draft-ietf-dnsop-alt-tld to point to the specific problems .alt would 
address?

I was going to suggest 1,$g/alternate/alternative/, but consulting 
Merriam-Webster informs me that "For all intents and purposes, alternate and 
alternative are synonymous.  Oh, well.

- Ralph

> 
> W
>  
> 
> 3. We're scheduling an interim WG meeting during the week of January 30 for 
> further work on this topic. We'll provide some possible days/times to the 
> list for feedback shortly, and we can't promise to accomodate everyone's 
> schedule constraints but will do our best.
> 
> 
> best,
> Suzanne & Tim
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] [homenet] WGLC on "redact" and "homenet-dot"

[Ralph Droms]

> On Dec 14, 2016, at 4:48 PM, Ray Bellis  wrote:
> 
> 
> 
> On 14/12/2016 21:16, Jim Reid wrote:
> 
>> So what? End users are not expected to see this string, far less care
>> about it, are they? Surely this string is primarily, if not
>> exclusively, for CPE firmware?
> 
> Actually, yes, they are expected to see this thing.
> 
> It would be what would appear in their browser bar, for example, if
> accessing the web UI of various on-net devices or services.

I know the WG has decided that home network device names should be 
user-friendly, so I'll make something of a moot point..."seeing" isn't the 
issue, in my opinion.  I see ugly names and URLs in my browser bar all the 
time.  "typing" is the real issue ... any time a user has to know, remember and 
reproduce a name for manuaal text entry, user-friendliness is important.

- Ralph

> 
>> Perhaps the way to resolve that is to tackle those misunderstandings
>> and any FUD around them. The self-same issue was discussed ad nauseam
>> ~15 years ago over ENUM.
>> 
>> IMO, the question here for the advocates of a TLD for home networks
>> (for some definition of that term) is “what specifically can you do
>> with .homenet (say) that you can’t do with homenet.arpa (say)?” ie
>> What are the use case(s) and problem statement(s) that need to be
>> addressed? And, as a logical followup, are those issues valid?
> 
> The arguments in favour of a pseudo-TLD are (AFAIK) entirely user
> orientated, and not technical.
> 
> Ray
> 
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] [homenet] WGLC on "redact" and "homenet-dot"

[Ralph Droms]

> On Dec 14, 2016, at 12:37 PM, Michael StJohns  wrote:
> 
> On 12/14/2016 12:34 PM, Steve Crocker wrote:
>> Mike,
>> 
>> A query to the root for .homenet results in a *signed* answer that .homenet 
>> does not exist.  This should suffice for the purpose you have in mind.
> 
> Yup - that's my comment:
> 
> The third way is to do no delegation from the root for .homenet and just 
> ensure that that name never gets registered and published.
> 
>> 
>> Ralph,
>> 
>> Re moving to the homenet list, I will try to send the same info there once I 
>> have time to sign up for that list.
> 
> Actually, I think Ray was probably more right on where this - specifically - 
> should be discussed.  Once done, then Homenet needs to consider what to do 
> about the guidance.

On the other hand, homenet has the expertise in the specific problem space, and 
will ultimately need to make the decision about how to proceed.  Engagement in 
the discussion is likely to help the homenet WG make an informed decision.

- Ralph

> 
> Mike
> 
> 
>> 
>> Steve
>> 
>>> On Dec 14, 2016, at 12:23 PM, Michael StJohns  
>>> wrote:
>>> 
>>> On 12/14/2016 12:07 PM, Ted Lemon wrote:
 I hope it was obvious that I was pretty confident that you actually had a 
 reason.   :)
 
 The issue what what you are saying is that sometimes it is technically 
 correct for a name to not be validatable.   The reason we want an 
 unsecured delegation for .homenet is that .homenet can't be validated 
 using the root trust anchor, because the name is has no globally unique 
 meaning.   So the reason that you've given doesn't apply to this case, 
 although I completely agree with your reason as it applies to the case of 
 names that are globally unique.
>>> 
>>> I went back and forth on this three times in 3 minutes "Steve's right, no 
>>> Ted's right, no, Steve's right" before settling on "I think Steve is mostly 
>>> right, but there may be an alternative third approach".
>>> 
>>> Here's the reasoning:   Either your home router understands .homenet or it 
>>> doesn't.  If it doesn't, then your homenet shouldn't be using .homenet and 
>>> any .homenet lookups to the real world should fail.  If it does, then it 
>>> should trap .homenet queries and do with it what it will.
>>> 
>>> Doing it Steve's way removes one attack surface for non-compliant routers 
>>> on home networks and for all the rest of the networks (e.g. feeding a user 
>>> a URL with a .homenet name on a fake webpage).
>>> 
>>> However, I think doing it Steve's way requires a *real* TLD zone for 
>>> .homenet, if for no other reason than to include NSEC and NSEC3 records 
>>> indicating an empty domain.
>>> 
>>> The third way is to do no delegation from the root for .homenet and just 
>>> ensure that that name never gets registered and published.
>>> 
>>> "If it's stupid and it works, it's not stupid".
>>> 
>>> Mike
>>> 
 
 On Wed, Dec 14, 2016 at 11:59 AM, Steve Crocker  wrote:
 The latter.  All DNS answers at all levels should be signed to assure the 
 querier of the integrity of the answer.  This has been the goal and best 
 practice for a very long time.  For example, it was the explicit objective 
 of the quote substantial DNSSEC effort funded by the US Dept of Homeland 
 Security starting in 2004.
 
 Within ICANN, in 2009 we made it a formal requirement of all new gTLDs 
 must be signed.  The ccTLDs are not subject to ICANN rules but they have 
 been gradually moving toward signed status.  Most of the major ccTLDs are 
 signed and many of the others are too.  Detailed maps are created every 
 week by ISOC.
 
 I will also try to contribute to the homenet mailing list.
 
 Steve
 
 Sent from my iPhone
 
 On Dec 14, 2016, at 11:36 AM, Ted Lemon  wrote:
 
> Is this a matter of religious conviction, or is there some issue with 
> unsecured delegations in the root that you are assuming is so obvious 
> that you don't need to tell us about it?   :)
> 
> On Wed, Dec 14, 2016 at 11:18 AM, Steve Crocker  
> wrote:
> I am strongly opposed to unsecured delegations in the root zone.  No 
> matter what the problem is, an unsecured delegation is not the answer.
> 
> Steve
> 
>> On Dec 14, 2016, at 11:11 AM, Suzanne Woolf  
>> wrote:
>> 
>> Hi all,
>> 
>> DNSOP participants who are interested in the special use names problem 
>> might want to review draft-ietf-homenet-redact 
>> (https://datatracker.ietf.org/doc/draft-ietf-homenet-redact/) and 
>> draft-ietf-homenet-dot 
>> (https://datatracker.ietf.org/doc/draft-ietf-homenet-dot/) for the WGLC 
>> on them in the HOMENET wg.
>> 
>> WGLC comments should go to the WG list, home...@ietf.org.
>> 
>> If you do, it will also be helpful to look at RFC 7788, which specifies 
>> the Home  

Re: [DNSOP] [homenet] WGLC on "redact" and "homenet-dot"

[Ralph Droms]

Is there any way this discussion could be moved to homenet, which is where the 
use case originates and the WG last call is taking place?

- Ralph

> On Dec 14, 2016, at 12:21 PM, Steve Crocker  wrote:
> 
> If it doesn’t have a globally unique meaning, it doesn’t make sense to query 
> the root for an answer.
> 
> What problem is trying to be solved?  I suspect whatever the problem actually 
> is, the answer will be something other than adding an unsecured delegation to 
> the root zone.
> 
> Steve
> 
> 
> 
> 
>> On Dec 14, 2016, at 12:07 PM, Ted Lemon  wrote:
>> 
>> I hope it was obvious that I was pretty confident that you actually had a 
>> reason.   :)
>> 
>> The issue what what you are saying is that sometimes it is technically 
>> correct for a name to not be validatable.   The reason we want an unsecured 
>> delegation for .homenet is that .homenet can't be validated using the root 
>> trust anchor, because the name is has no globally unique meaning.   So the 
>> reason that you've given doesn't apply to this case, although I completely 
>> agree with your reason as it applies to the case of names that are globally 
>> unique.
>> 
>> On Wed, Dec 14, 2016 at 11:59 AM, Steve Crocker  wrote:
>> The latter.  All DNS answers at all levels should be signed to assure the 
>> querier of the integrity of the answer.  This has been the goal and best 
>> practice for a very long time.  For example, it was the explicit objective 
>> of the quote substantial DNSSEC effort funded by the US Dept of Homeland 
>> Security starting in 2004.
>> 
>> Within ICANN, in 2009 we made it a formal requirement of all new gTLDs must 
>> be signed.  The ccTLDs are not subject to ICANN rules but they have been 
>> gradually moving toward signed status.  Most of the major ccTLDs are signed 
>> and many of the others are too.  Detailed maps are created every week by 
>> ISOC.
>> 
>> I will also try to contribute to the homenet mailing list.
>> 
>> Steve
>> 
>> Sent from my iPhone
>> 
>> On Dec 14, 2016, at 11:36 AM, Ted Lemon  wrote:
>> 
>>> Is this a matter of religious conviction, or is there some issue with 
>>> unsecured delegations in the root that you are assuming is so obvious that 
>>> you don't need to tell us about it?   :)
>>> 
>>> On Wed, Dec 14, 2016 at 11:18 AM, Steve Crocker  wrote:
>>> I am strongly opposed to unsecured delegations in the root zone.  No matter 
>>> what the problem is, an unsecured delegation is not the answer.
>>> 
>>> Steve
>>> 
 On Dec 14, 2016, at 11:11 AM, Suzanne Woolf  wrote:
 
 Hi all,
 
 DNSOP participants who are interested in the special use names problem 
 might want to review draft-ietf-homenet-redact 
 (https://datatracker.ietf.org/doc/draft-ietf-homenet-redact/) and 
 draft-ietf-homenet-dot 
 (https://datatracker.ietf.org/doc/draft-ietf-homenet-dot/) for the WGLC on 
 them in the HOMENET wg.
 
 WGLC comments should go to the WG list, home...@ietf.org.
 
 If you do, it will also be helpful to look at RFC 7788, which specifies 
 the Home Networking Control Protocol for homenets. 
 
 The redact draft is intended to remove the inadvertent reservation of 
 “.home” as the default namespace for homenets in RFC 7788. 
 
 The homenet-dot draft is intended to provide a request under RFC 6761 for 
 “.homenet” as a special use name to serve as a default namespace for 
 homenets. It also asks IANA for an unsecured delegation in the root zone 
 to avoid DNSSEC validation failures for local names under “.homenet”. The 
 root zone request to IANA has caused some discussion within the WG, as 
 there’s no precedent for such a request.
 
 Terry Manderson mentioned the homenet-dot draft briefly at the mic in 
 Seoul. 
 
 The WGLC ends this week.
 
 
 Suzanne
 
> Begin forwarded message:
> 
> From: Ray Bellis 
> Subject: [homenet] WGLC on "redact" and "homenet-dot"
> Date: November 17, 2016 at 11:27:08 PM EST
> To: HOMENET 
> 
> This email commences a four week WGLC comment period on
> draft-ietf-homenet-redact and draft-ietf-homenet-dot
> 
> Please send any comments to the WG list as soon as possible.
> 
> Whilst there was a very strong hum in favour of ".homenet" vs anything
> else during the meeting, and there's some discussion of that ongoing
> here on the list - I'd like us to please keep the discussion of the
> choice of domain separate from other substantive comment about the
> drafts' contents.
> 
> thanks,
> 
> Ray
> 
> ___
> homenet mailing list
> home...@ietf.org
> https://www.ietf.org/mailman/listinfo/homenet
 
 ___
 DNSOP mailing list
 DNSOP@ietf.org
 https://www.ietf.org/mailman/listinfo/dnsop
>>> 
>>> 
>>> ___

Re: [DNSOP] special use names and unsecured delegation from the root

[Ralph Droms]

Ted, Suzanne - it might be helpful if the text can stand by itself, to post the 
text to the homenet and snoop WG mailing lists, in addition to adding i too the 
problem statement.

- Ralph

> On Nov 17, 2016, at 3:43 AM, Ted Lemon  wrote:
> 
> It's pretty clear that it needs to be added.   I will do so.
> 
> On Thu, Nov 17, 2016 at 5:00 PM, Suzanne Woolf  wrote:
>> Hi all,
>> 
>> For those of you who were in the HOMENET WG meeting yesterday, you probably 
>> noticed a controversy that’s developed around the proposed .homenet special 
>> use name as the default for homenet naming: the working group is 
>> considering, among other things, whether its special use name needs an 
>> unsecure delegation in the parent zone in order to prevent DNSSEC failures.
>> 
>> If HOMENET is attempting to standardize a single-label special use name (a 
>> “TLD”), which is their current plan, this would mean asking IANA for such an 
>> unsecure delegation in the root, which may pose process problems. If they 
>> want a special use name further down the tree, such as one under .arpa, the 
>> unsecure delegation from the parent may still be required, but shouldn’t 
>> raise the same process questions.
>> 
>> I’m hereby asking the editors of the DNSOP special use names problem 
>> statement document to review that discussion and determine whether it needs 
>> to be added to the problem statement.
>> 
>> It seems to me that it would be very helpful if the problem statement could 
>> describe how DNSSEC is relevant to handling of special use names (including 
>> those that use DNS resolution protocol but don’t have global scope, or those 
>> that aren’t intended to resolve with DNS at all) and under what conditions 
>> it can be a problem.
>> 
>> 
>> thanks,
>> Suzanne
>> 
>> ___
>> DNSOP mailing list
>> DNSOP@ietf.org
>> https://www.ietf.org/mailman/listinfo/dnsop
> 
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Tell me about the ISO 3166 user assigned two-letter codes and TLDs

[Ralph Droms]

> On Sep 29, 2016, at 2:56 AM, hellekin  wrote:
> 
>> On 09/29/2016 05:42 AM, Edward Lewis wrote:
>> 
>> The one option you have is ".example", unfortunately (and in sympathy)
>> I don't have a better suggestion.
>> 
> 
> .example is for documentation.  You can use .invalid for "fake private
> TLD", which makes it very clear that it's not a valid TLD. (Sorry for
> the tautology.)
> 
> This list of two-letter TLDs sounds like a good candidate for
> Special-Use Domain Names.  But then, it prompts another question: if,
> e.g., XA-XZ are reserved for future use, how to handle their *removal*
> from the Special-Use Name Registry once they're assigned again?  Which
> prompts another question: if a name enters the Special-Use Name
> Registry, is it parked (for an indefinite amount of time), or is it
> engraved in stone (and won't move from that registry again)?  And can
> the SUNR hold both types of names (parked and final)?

Good question, not (as far as I know) explicitly addressed in RFC 6761.

Because there is no explicit prohibition on removal of a name from the SUNR, 
publication of an appropriate RFC directing IANA to take such an action would 
be the appropriate action, at least. In my opinion.

The question might actually apply to many IANA registries.  Do the 
"Registration Procedures" apply to "unregistration" as well?  I don't know if 
there is any precedent here.

- Ralph

> 
> ==
> hk
> 
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] moving forward on special use names

[Ralph Droms]

> On Sep 17, 2016, at 11:37 AM, Ted Lemon  wrote:
> 
> I would just like to point out that what we are talking about doing is 
> documenting the problem that we think needs to be addressed.   One of the 
> reasons we published a new document about this is that it seemed that the 
> original effort had gone way too far down the path toward solutions, without 
> there being a clear agreement on what problems exist, and what problems we as 
> a working group can get consensus to try to address.
> 
> This discussion is again going down the solution space path.   I understand 
> the motivation, and I don't disagree with it, but I really would like to get 
> a problem statement before we start talking about solutions.

Emphatically +1.

- Ralph

> 
>> On Sat, Sep 17, 2016 at 10:18 AM, Alain Durand  
>> wrote:
>> What would really help here would be standardize a way to measure toxicity. 
>> We could then track a specific string toxicity over time, and maybe then 
>> define a threshold where it is OK or not OK to delegate that particular 
>> string.
>> 
>> I would personally agree with your assessment that maintaining this list in 
>> 6761 is problematic, for the reason mentioned in section 3.f of darft-adpkja:
>> 
>> "f.  [RFC6761] does not have provision for subsequent management of
>>the registry, such as updates, deletions of entries, etc…”
>> 
>> 
>> Alain.
>> 
>> 
>>> On Sep 16, 2016, at 8:10 PM, John Levine  wrote:
>>> 
>>> This is the toxic waste bit.  The names don't make sense in the 6761
>>> special use registry, since they're not being used in any way that is
>>> or can be standardized, but they also aren't suitable for delegation
>>> due to widespread de facto use.  I also expect that if we redid last
>>> year's debate in anything like the same way, we'd have the same
>>> result, one or two highly motivated people who work for TLD applicants
>>> would sabotage it.
>>> 
>>> As I hardly need tell you, it is utterly unclear whether it makes more
>>> sense to have the IETF reserve them or, to switch hats and encourage
>>> ICANN to put them on a list of names that aren't in use but can't be
>>> delegated as SAC045 suggests.
>>> 
>>> One reason that the latter makes slightly more sense is that it's
>>> likely that some of those names will eventually become less polluted,
>>> so the list needs to be reconsidered every once in a while (years.)
>>> For example, I gather that it's been a decade since Belkin stopped
>>> making routers that leak .belkin traffic, and at some point most of
>>> them will be gone.
>> 
>> 
>> ___
>> DNSOP mailing list
>> DNSOP@ietf.org
>> https://www.ietf.org/mailman/listinfo/dnsop
>> 
> 
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] draft-adpkja-dnsop-special-names-problem-01

[Ralph Droms]

> On Mar 30, 2016, at 2:32 PM 3/30/16, David Conrad  
> wrote:
> 
> Suzanne,
> 
> 
> On Mar 29, 2016, at 5:23 PM, Suzanne Woolf  wrote:
>> I’ve always seen people assume that an entry in the special use names 
>> registry means that ICANN won’t delegate the same string in the DNS root.
> 
> I thought putting a name onto the special use names registries was an 
> exercise in informing ICANN (and the rest of the world) that the IETF was 
> invoking clause 4.3(a) of RFC 2860. The last paragraph of 4.3 states:
> 
> "In the event ICANN adopts a policy that prevents it from complying with the 
> provisions of this Section 4 with respect to the assignments described in (a) 
> - (c) above, ICANN will notify the IETF, which may then exercise its ability 
> to cancel this MOU under Section 2 above."
> 
> Are you suggesting you believe ICANN would want to trigger that exercise or 
> that using the special use registry is not invoking clause 4.3(a) (or 
> something else)?

David - I've reviewed 4.3(a) and the paragraph you quoted, and I honestly don't 
see the connection between invoking 4.3(a), the last paragraph of 4.3 and any 
suggestion on Suzanne's part that ICANN would want to cause the IETF to 
exercise that option?

Would you please explain in a little more detail?

- Ralph

> 
> Regards,
> -drc
> 
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] draft-adpkja-dnsop-special-names-problem-01

[Ralph Droms]

> On Mar 28, 2016, at 5:41 PM 3/28/16, Alain Durand  
> wrote:
> 
> Andrew,
> 
> This is the very registration in 6761 that makes (or would make) those names 
> special, i.e. not ordinary. Those name could as well have been reserved in 
> the previous ICANN gTLD round or in the next one for regular DNS purpose. The 
> is nothing "non-ordinary" about the strings themselves...

Let me make the point again that the document that records the Standards Action 
or IESG approval is what designates a name as a special-use name.  Therefore, 
any designation as a special-use name will have IETF consensus.  RFC 6761 only 
documents the process for recording that designation in the Special-Use Names 
registry.

What do you mean by "reserved in the previous ICANN gTLD round"?  Do you mean 
"assigned to some entity", in which case it's highly unlikely the IETF would 
come to consensus about designating such a name as a special-use name.  Once a 
name has been designated as a special-use name, it is no longer part of the DNS 
namespace available for assignment by ICANN.

But, I may be misunderstanding your point...

- Ralph

> 
> Alain, speaking solely for myself.
> 
>> On Mar 28, 2016, at 3:23 PM, Andrew Sullivan  wrote:
>> 
>> Hi,
>> 
>> I think I've answered these questions before, but in case not, here's
>> what I think:
>> 
>>> On Mon, Mar 28, 2016 at 12:15:15PM -0700, David Conrad wrote:
>>> In what way is ONION not "ordinary"?
>> 
>> The label "onion" indicates that an alternative resolution path is
>> intended.  Moreover, an additional underlying networking protocol is
>> expected to be in use.
>> 
>>> In what way are GNU, ZKEY, BIT, EXIT, I2P, etc., "ordinary" or not 
>>> "ordinary"
>> 
>> An alternative (to DNS) resolution protocol is similarly expected.  In
>> some cases, additional underlying network protocols are expected.  In
>> other cases, it is merely an indication of alternative resolution,
>> with no alternative underlying network technology.  (Part of the
>> reason I wanted the different cases separated is because I think it's
>> an open question whether a different naming protocol with _no_
>> difference in the underlying technology is a legitimate use of 6761.)
>> 
>>> Are HOME, CORP, and MAIL "ordinary"?
>> 
>> Yes.  They're expected to resolve in ordinary DNS contexts, though not
>> necessarily the global one.  My own view is that these ought to be
>> outside the 6761 registry unless some ICANN-based PDP were to
>> determine that they should be permanently reserved and that the
>> reservation ought to be sought in the 6761 registry.
>> 
>> Best regards,
>> 
>> A (as usual, for myself)
>> 
>> --
>> Andrew Sullivan
>> a...@anvilwalrusden.com
>> 
>> ___
>> DNSOP mailing list
>> DNSOP@ietf.org
>> https://www.ietf.org/mailman/listinfo/dnsop
> 
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

[DNSOP] WG last calls on dnssd WG drafts of interest to dnsop

[Ralph Droms (rdroms)]

The dnssd WG is currently conducting two WG last calls of interest to dnsop WG 
participants:

draft-ietf-dnssd-mdns-dns-interop-02
draft-ietf-dnssd-hybrid-03

Both of these last calls are scheduled to conclude on March 31.  The dnssd WG 
chairs would greatly appreciate review and feedback on these documents, posted 
to dn...@ietf.org  Results of the WG last calls will be reviewed at the dnssd 
WG meeting in Buenos Aires.

- Ralph and Tim




signature.asc
Description: Message signed with OpenPGP using GPGMail
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] draft-adpkja-dnsop-special-names-problem-01

[Ralph Droms]

> On Mar 28, 2016, at 9:11 AM 3/28/16, Alain Durand  
> wrote:
> 
> On 3/26/16, 11:30 PM, "DNSOP on behalf of Andrew Sullivan"
>  wrote:
> 
>> I guess my point was merely that your examples seemed only to be
>> arguing from this or that trade or service mark to some conclusion
>> that the IETF had an obvious problem to contemplate.  But the
>> registrations in 6761 are, not going to be part of such disputes; or,
>> if they are, it is a problem the IETF will have confronted in its
>> evaluation.  Waving around possible trademark cases as things one
>> ought to worry about seems to me not to help the discussion.
> 
> 
> Andrew,
> 
> This is the crux of the issue. I have a hard time to believe the statement
> you are making above
> that future RFC6761 registrations will not be the object of trademark & co
> disputes.

I understand Andrew's point to be that the decision process regarding 
trademark, etc., disputes will take place as part of the review process 
inherent in meeting the requirements for publishing 'an IETF "Standards Action" 
or "IESG Approval" specification', which is required in RFC 6761 for adding a 
name to the registry.

> ICANN history has shown us that anything that has a name attached to it is
> a potentially candidate for such a dispute.
> It may or may not have been the case for Onion or Local, but we have no
> guarantees it will not
> be the case for the following ones.
> 
> Now, your second statement that the IETF will confront such potential
> claims during evaluation
> is where I personally express serious reservations. As I mentioned in a
> previous email,
> I do not believe the IETF is well equipped to deal with that. Wishing
> those issues away
> is, IMHO, the very thing that is not helping in this discussion. I trust
> this community
> to make good technical decisions, but I¹m not ready to sign a blank check
> on its ability
> to make good decisions in the trademark/name policy arena.

First, I'll emphasize that the process of designating a name as "special use" 
is separate from the mechanical process of actually adding a new name to the 
Special-Use Names registry.

RFC 6761 explicitly defines the latter process, and implicitly requires open 
IETF review for the former process.  In my opinion, we can focus on the former 
process, of deciding whether a name should be designated as having a special 
use.  This process may have, as you point out, issues regarding trademarks, 
association of names with organizations, and many others.

I'm not trying to wish those issues away, and I don't think Andrew is either.  
Rather, speaking only for myself, I believe that our open process of community 
review and consensus is an appropriate starting point for discussion.

- Ralph

> 
> 
> Alain, speaking for myself.
> 
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] draft-adpkja-dnsop-special-names-problem-01

[Ralph Droms]

> On Mar 25, 2016, at 9:37 PM 3/25/16, Paul Hoffman  
> wrote:
> 
> On 25 Mar 2016, at 8:33, Ralph Droms wrote:
> 
>> I'm responding here with none of my various hats on...
> 
> As are we all. (Or, in some of our cases, wearing none of our organization's 
> jaunty logos...)
> 
>> Here's the tl;dr version.  This document has some useful information and 
>> raises, directly and indirectly, some important questions that the IETF 
>> should consider.  Unfortunately, those useful bits are buried in a polemic 
>> that is directed toward a specific outcome.  If this document is accepted as 
>> a WG document, I strongly suggest that it be heavily edited to extract and 
>> emphasize the useful text and discard the rest.
> 
> Understood. However, you said one very significant thing to support that view 
> that is factually incorrect, and goes to the heart of what I read as a 
> motivator for the longer list of problems in 
> draft-adpkja-dnsop-special-names-problem. You say:
> 
>> RD>> I disagree with this characterization of RFC 6761, which provides
>> an explicit registry for behaviors that are specified in other
>> documents for special handling.  My view of the process defined in RFC
>> 6761 is that an RFC is published that describes the special use for
>> part of the domain namespace.  The decision about whether to
>> standardize that use is implicitly part of the RFC publication
>> process.  Once the decision is made to publish the RFC, the effects of
>> the standardized use of the subset of the namespace is recorded in the
>> RFC 6761 registry.
> 
> But that's *not* what RFC 6761 says. Instead, it says:
>   If it is determined that special handling of a name is required in
>   order to implement some desired new functionality, then an IETF
>   "Standards Action" or "IESG Approval" specification [RFC5226] MUST be
>   published describing the new functionality.

You are right.  I wrote imprecisely and reviewed what I wrote hastily.  I would 
have been more correct to simply quote that text from RFC 6761, and point out 
that RFC 6761 leaves the process for determining that a name is to be 
designated as a special-use name as implicitly out of scope.

> Both an IETF "Standards Action" and an "IESG Approval" require IETF 
> consensus; RFC publication does not.

I agree and it's an important point that the process of designating a name for 
special use requires IETF consensus, which implies IETF review and discussion 
of any potential designation.  It was a point I was trying to make but made 
badly.  Thanks for the clarification.

> My reading of the extensive list of problems in 
> draft-adpkja-dnsop-special-names-problem is that most of them stem from lack 
> of IETF consensus. Both the WG Last Call and IETF Last Call on .onion were 
> contentious and were possibly moved forward more due to exhaustion than 
> actual consensus (see RFC 7282).
> 
> Personally, I don't find listing the problems that came out during those 
> consensus calls a "polemic", but you might.

I'll agree to disagree with you on this point.

> 
> --Paul Hoffman

- Ralph




signature.asc
Description: Message signed with OpenPGP using GPGMail
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] draft-adpkja-dnsop-special-names-problem-01

[Ralph Droms]

Thanks for the quick followup, David...

> On Mar 25, 2016, at 1:04 PM 3/25/16, David Conrad  
> wrote:
> 
> Ralph,
> 
> On Mar 25, 2016, at 8:33 AM, Ralph Droms  wrote:
>> I'm responding here with none of my various hats on...
> 
> Me too.
> 
>> RD>> I think it's more correct to write that RFC 7686 defines ".onion"
>> as a Special-Use Domain Name, which takes it out of the Domain Name
>> space.
> 
> No.  It is still a domain name in the sense that it is within the universe of 
> identifiers under a singly rooted namespace used on the public Internet (the 
> "domain name namespace").  What it is not is a part of the subset of that 
> namespace that is resolved using the DNS protocol/infrastructure.

Yes, you're right.  I understand and actually meant to write what you wrote...

>> RD>> Similarly, why are .uucp and .bitnet "bad precedents"?
> 
> They are bad precedents because of the challenges they caused for network 
> operations. Specifically, the fact that they were local policy considerations 
> meant that references to a .bitnet or .uucp name within one administrative 
> domain would work but would fail when that reference escaped that 
> administrative domain (e.g., in a cc line of an email address). In my view, 
> this is essentially the same problem that led to the IAB publishing 2826. One 
> of my concerns with 6761 is that it can encourage recreating that 
> operationally challenging world without explaining the inherent risks.

Thanks for that explanation.  I think it would be helpful to include it in any 
future revs of the problem statement.

> 
>> I think the common assumption is that everything
>> not lised in the Special-Use Domain Names registry is in the DNS name
>> space, which would make the Registry a complete catalog.
> 
> I disagree. I believe the domain name namespace can be broken down into:
> 
> 1. In the DNS (exists within the root zone)
> 2. Not in the DNS (exists within the special use registry)
> 3. Not defined (everything else)
> 
> The primary issue I have with 6761 is that while it is relatively clear who 
> the authority is for (1) and (2), it does not provide a clear answer about 
> the authority for (3) or how a name gets put into (1) or (2) when taken in 
> the context of 2860, section 4.3.

OK, I agree with your 3 categories.  I think you elaborated on the observation 
about authority for (3) and process for moving a name to (1) or (2) below...

> 
>> By design, RFC 6761 makes no
>> statement about a specific WG or evaluation body or process.
> 
> Which is, of course, one of the key problems. It results in an undefined 
> decision process dependent on the individual subjective evaluation of IESG 
> members.  Given the economic, political, and social implications of the 
> naming hairball, this seems like a really bad idea to me.

It is certainly a key issue and I hope we can get a focused discussion going 
about whether there is consensus that a more well-defined decision process is 
needed and, if so, what are the specifics of that process.

- Ralph

> 
> Regards,
> -drc
> (speaking only for myself)
> 
> 
> 



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] draft-adpkja-dnsop-special-names-problem-01

[Ralph Droms]

I'm responding here with none of my various hats on...

Here's the tl;dr version.  This document has some useful information and 
raises, directly and indirectly, some important questions that the IETF should 
consider.  Unfortunately, those useful bits are buried in a polemic that is 
directed toward a specific outcome.  If this document is accepted as a WG 
document, I strongly suggest that it be heavily edited to extract and emphasize 
the useful text and discard the rest.

If you're still reading...

Let me start with the fundamental difference I have with one of the key 
pre-conclusions of this document.  In my opinion, RFC 6761 and the Special-Use 
Domain Names registry meet the requirement of a complete and useful way to 
record and make available information about domain names designated to be 
special use.  Section 4 of RFC 6761 explicitly leaves the identification of 
special use names to "Standards Action" or "IESG Approval".  I've made several 
comments below in which I think the distinction is important for the accuracy 
and authority of draft-adpkja-dnsop-special-names-problem.

The document does identify some key questions the IETF should
consider:
* does the IETF want to formally sanction protocol switching based on
  the last label?
* should the IETF coordinate the designation of special-use domain
  names with other bodies such as ICANN; if so, how?
* does the IETF want to specify a more formal review process for the
  designation of special-use domain names?

I think this document would be greatly strengthened and far more helpful to the 
dnsop WG and the IETF if it included a clear identification of a list of 
specific problems that have been encountered with the review and publication of 
documents that define special use names in the past, and that might be 
encountered in the future.  Citations of mailing list discussions that lead to 
the identification of the specific problems would be a real plus.

Finally, I think the document would be strengthened by editing out text on 
solutions and editing down the text to state and motivate the problems directly 
and succinctly.

Specific comments, more or less in the order of appearance in 
draft-adpkja-dnsop-special-names-problem-02:

Abstract

   The dominant protocol for name resolution on the Internet is the
   Domain Name System (DNS).  However, other protocols exist that are
   fundamentally different from the DNS, and may or may not share the
   same namespace.

RD>> I think the problem is actually broader than just other
protocols.  We have a namespace that is primarily used for names
intended for resolution through DNS, but, as recorded in RFC 6761,
there are parts of the namespace that are handled in special ways.

   When an end-user triggers resolution of a name on a system which
   supports multiple, different protocols (or resolution mechanisms) for
   name resolution, it is desirable that the protocol used is
   unambiguous, and that requests intended for one protocol are not
   inadvertently answered using another.

RD>> editorial: too much detail for an abstract?

   RFC 6761 introduced a framework by which, under certain
   circumstances, a particular domain name could be acknowledged as
   being special.  This framework has been used twice to reserve top-
   level domains (.local and .onion) that should not be used within the
   DNS, to avoid the possibility of namespace collisions in parallel use
   of non-DNS name resolution protocols.

RD>> I disagree with this characterization of RFC 6761, which provides
an explicit registry for behaviors that are specified in other
documents for special handling.  My view of the process defined in RFC
6761 is that an RFC is published that describes the special use for
part of the domain namespace.  The decision about whether to
standardize that use is implicitly part of the RFC publication
process.  Once the decision is made to publish the RFC, the effects of
the standardized use of the subset of the namespace is recorded in the
RFC 6761 registry.

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

RD>> I would phrase the problem as challenges in the process of
reviewing documents that would standardize special uses of names from
the domain name space.

RD>> Editorial nit: the Introduction is usually the first section of
the body of the document.

RD>> In 2. Introduction, and I'm sorry to be repeating myself, in my
opinion RFC 6761 records the special uses of some domain names, as
approved for publication as an Internet Standard.  I'll also repeat
myself that RFC 6761 describes other alternative special handling
aside from protocol switches.  That alternative special handling must
be considered carefully at the time of publication of the defining
RFC, regardless of the nature of the 

Re: [DNSOP] draft-grothoff-iesg-special-use-p2p-bit

[Ralph Droms]

> On Nov 22, 2015, at 9:03 AM 11/22/15, Stephane Bortzmeyer  
> wrote:
> 
> On Sun, Nov 22, 2015 at 12:08:42PM +0100,
> Christian Grothoff  wrote
> a message of 13 lines which said:
> 
>> We have solicited but failed to receive any feedback from the dnsop
>> chairs or list on how to improve/revise the draft. Hence, there are
>> currently no updates.  I continue to await the chairs asking for
>> last call on this.
> 
> It has been said that post-onion drafts won't be considered until
> 6761bis is out  but it did
> not prevented
>  to
> advance: it will be interesting to see how .home is handled.

In what way has draft-cheshire-homenet-dot-home advanced?  I see that a new 
revision has been published with minor editorial changes, but it still appears 
to be an individual submission that has not been adopted by any WG.

- Ralph

> 
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Requesting review of draft-ietf-dnssd-mdns-dns-interop-01

[Ralph Droms]

Second try...

> On Jul 21, 2015, at 4:06 AM 7/21/15, Ralph Droms (rdroms)  
> wrote:
> 
> Hi - The dnssd chairs would like to get some reviews of 
> draft-ietf-dnssd-mdns-dns-interop-01, "On Interoperation of Labels Between 
> mDNS and DNS," from dnsop participants.  draft-ietf-dnssd-mdns-dns-interop-01 
> is currently in dnssd WG last call and last call comments will be discussed 
> in the dnssd WG meeting this week. 
> 
> Please post your feedback to dnsop or send to Tim and myself.
> 
> - Ralph
> 
> 
> 

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

[DNSOP] Requesting review of draft-ietf-dnssd-mdns-dns-interop-01

[Ralph Droms (rdroms)]

Hi - The dnssd chairs would like to get some reviews of 
draft-ietf-dnssd-mdns-dns-interop-01, "On Interoperation of Labels Between mDNS 
and DNS," from dnsop participants.  draft-ietf-dnssd-mdns-dns-interop-01 is 
currently in dnssd WG last call and last call comments will be discussed in the 
dnssd WG meeting this week. 

Please post your feedback to dnsop or send to Tim and myself.

- Ralph

Bcc: dn...@ietf.org


___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

[DNSOP] Fwd: Last Call: (Special-Use Domain Names) to Proposed Standard

[Ralph Droms]

FYI; review and comment requested...

- Ralph

Begin forwarded message:

From: The IESG 
Date: January 17, 2011 3:00:48 PM PST
To: IETF-Announce 
Subject: Last Call:  (Special-Use 
Domain Names) to Proposed Standard


The IESG has received a request from an individual submitter to consider
the following document:
- 'Special-Use Domain Names'
  as a Proposed Standard

  Abstract

  This document describes what it means to say that a DNS name is
  reserved for special use, when reserving such a name is appropriate,
  and the procedure for doing so.

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
i...@ietf.org mailing lists by 2011-02-14. Exceptionally, comments may be
sent to i...@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

The file can be obtained via
http://datatracker.ietf.org/doc/draft-cheshire-dnsext-special-names/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-cheshire-dnsext-special-names/


No IPR declarations have been submitted directly on this I-D.
___
IETF-Announce mailing list
ietf-annou...@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-announce

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop