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

From: Suzanne Woolf <[email-masked]>
Date: Thu, 2 Feb 2017 18:04:05 -0500

This message opens a Working Group Last Call for:

"Special-Use Names Problem Statement"
https://datatracker.ietf.org/doc/draft-ietf-dnsop-sutld-ps/ <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

---

From: "John Levine" <[email-masked]>
Date: 3 Feb 2017 02:42:09 -0000

>If not, can you suggest changes that would get your support for advancing it? (“Send text” if possible!)

It's closer than I had remembered.

In the problem paragraph that starts at the bottom of page 6, on
domain names that have been commandeered, I'd like it to say that
there is no agreement on how to decide that a name has been
comandeered, nor if or how to revisit a name to decide that it's been
uncomandeered.

(For that last, I'm thinking about .BELKIN, where the routers that
leak the name will eventually all fail, or .CORP where people may use
it less now that CAs don't sign certs any more.)

I'd also like a mention of DNSSEC.  DNSSEC is intended to provide a
signature chain from the root to any leaf, but there is no way to
chain to a SUTLD.  There's also no agreement what to do with DNSSEC
and existing SUTLDs, whether to have DNSSEC say they don't exist, or
to create some sort of unsigned pseudo-delegation, or something else.

R's,
John

---

From: Jeremy Rand <[email-masked]>
Date: Fri, 3 Feb 2017 15:34:41 +0000

> If not, can you suggest changes that would get your support for advancing it? (“Send text” if possible!)

Trivial spelling nit: Sec. 4.2.2 says "unilateral use by the TOR
project".  The correct spelling is "Tor" (only the "T" in "Tor" should
be capitalized.)  Also, according to
https://www.torproject.org/docs/trademark-faq.html.en, "The Tor Project"
is the correct spelling of the phrase (all 3 words should have the
initial letter capitalized).

Cheers,
-Jeremy

---

From: Suzanne Woolf <[email-masked]>
Date: Fri, 3 Feb 2017 12:43:42 -0500

Hi,

Some comments on the draft….no hats.

I’ve started at the beginning and covered through the beginning of Sec. 4; I’ll review the “existing practices" material separately.

It looks severely critical because it’s long, but most of the changes suggested are small, and I’ve tried hard to keep them in a clear context. In general, I’m mostly suggesting the authors tighten up the specifics and surface a few assumptions.

I think it’s definitely pointed in the right direction.

Thanks to the authors for their work.

Suzanne

======
draft-ietf-dnsop-sutld-ps-02
3 Feb 2017

Abstract

1. I think for purposes of this document, ICANN and SSAC are not "standards organizations", just "organizations". I realize it's a debatable point in casual use (is ICANN's documentation of its processes for changing the root zone "standards"?) but I don’t think it applies within the usual meaning of the term for the IETF and other recognized SDOs.

Introduction

2. I like that the name/resolution distinction is clearly called out here. I’m not sure the names=DNS assumption has been entirely banished throughout but it’s definitely heading in the right direction.

3. STYLE/GRAMMAR: "....defined policies for adding to the registry, and made some suggestions about how that policy might be implemented." This should be "....defined a policy..." or "....about how those policies might be implemented."

4. STYLE/GRAMMAR: This sentence is hard to parse: "In 
   support of the particular set of problems described here...."

OLD:
   "In support of the particular set of problems described here, the
   document also includes documentation of existing practice as it
   relates to the use of Domain Names, as well as a brief history of
   Domain Names, and finally to describe the set of problems that exist
   as reported by various IETF participants with experience in the
   various aspects of the problem."

NEW:
"In support of its analysis of the particular set of issues described here, the document also includes descriptions of existing practice as it relates to the use of domain names, a brief history of domain names, and some observations by various IETF participants who have experience with various aspects of the current situation."

Terminology

5. On defining "domain name," I think citing RFC 7719 and the domain-names draft might be helpful. If it were less ambiguous in practice this problem would be easier, but at least mentioning some contexts where domain names are used or some of the constraints of what can be in the strings might be helpful to readers who haven't already seen the challenges in such a definition.

6. The terms are all defined relative to something we don't actually have a term for, but might need one. If we're talking here about "special use" names, what's a "normal" or "ordinary" or "expected" use, and how is a "special use" different? You seem to be answering that question but only by implication.

Possibly add something like "The default or assumed use of a domain name is initialization and resolution within the Domain Name System, which includes a single global resolution scope and the Domain Name System protocol (RFC 1034/1035). Such names are expected to be unique within the global domain namespace. A name intended for use in the internet or its defining protocols, following the construction rules for domain names, but not global in scope or resolved by DNS wire protocol, could be considered a 'special use' name."

We don't have a formal, consensus definition anywhere, but RFC 7719 takes a credible shot at a lot of what we need here, so you might mostly be able to get away with citing it. 

Problems associated with Special-Use Domain Names

7. STYLE/GRAMMAR: The two sentences beginning "Solutions to these problems..." are hard to parse. This is partly because they're making a subtle point, but:

OLD:
   "Solutions to
   these problems are out of scope for this document.  Because of that,
   problems with solutions to these problems are also out of scope for
   this document, and will be covered in a separate document."

NEW:
   "Solutions to these problems, including their costs or tradeoffs, are out of scope
   for this document. They will be covered in a separate document."

8. I think para. 2 (bottom of page 3) and para. 3 (top of page 4) are a little confusing, even though I understand the rhetorical device of using the word "problem" 12 times in half a page. I wanted to see how you felt about that text before trying to rewrite it.

9. The text "There are several different types of names in the root of the Domain Namespace" assumes the root is important-- that it's the mathematical root of a tree-- without quite saying so. Citing RFC 7719, sec. 2 is probably helpful here.

10. STYLE/GRAMMAR: "names that may not be applied for as a TLD" -> "....applied for as TLDs"

11. STYLE/GRAMMAR: I wouldn't be surprised if the word "commandeer" made some readers uncomfortable; it's got an implication of illegitimacy.

12. "assign names from the pool of unused names" is a little imprecise, should probably specify slightly further:

OLD:
   "Both ICANN and the IETF have the authority and formal processes to
   assign names from the pool of unused names..."

NEW:
   "Both ICANN and the IETF have the authority and formal processes to
   make new assignments from the pool of unassigned domain names, and expect names they add to
   be unique within the global namespace."

13. The "lack of coordination" is only a problem given the expectation that names created under multiple set of processes will be unique within a shared scope. This can be assumed in the definition of “domain name” or it can be explicitly called out here, but the uniqueness constraint has to be explicit somewhere, because without it there’s (arguably) no problem.

14. You say: "The term "technical use" in RFC 2860 [RFC2860] is considered by
      some to be too inclusive."

Isn't the concern really that the term is ambiguous, so some people find it too inclusive and some people find it too limited? For instance, we've heard the view expressed that it wasn't intended to include names defined for non-DNS resolution mechanisms, so something like .onion or .local isn't covered; we've also seen it asserted that "technical use" by the IETF includes the ability to force a change to the DNS root zone by ICANN. (As a personal view, I don't support either extreme.)

15. You say "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."

It almost makes more sense to me to say the IETF and ICANN each have an ability to add names to the domain name space under conditions such that people will use them, but there's no shared view of what that means in terms of the shared global namespace. Specifically, there's no shared view of how to avoid collisions such that the uniqueness constraint that people expect of their domain names will be reliably honored.

AFAIK the IETF has never claimed anyone would stop using a particular string in a domain name slot just because the IETF told them not to. The IETF can't tell people how to write their code, it just has a process for defining what's interoperable so they can avoid problems with others if they want to.

16. Same comments on the text "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."

17. More generally, on the last two comments, the use of the word "authority" may need to be clarified here. It sounds obvious, but I think if it really were obvious we wouldn't need to think about this stuff quite so hard. If we assume RFC 2860 is not open for modification (one of our ground rules from early on) and it's not the WG's job to interpret it, we're left with the practical reality that ICANN has operational authority over the DNS root zone under its community's processes, the IETF has operational authority over the SUDN registry under its processes (RFC 6761).

18. "Commandeer" again has some questionable connotations. Still not sure of a better word, but the .onion RFC might provide one. 

19. I'd add to the list of possible reasons for putting a name into use without following any external process: "Names are expected to be resolved only within the local scope for a protocol or network, or by some non-DNS protocol, and designers don't realize or don't care that modern systems and applications may nonetheless try to resolve domain names with no context signaling in the global DNS." Handwaving about authority aside, the real concern in these cases is interoperability; no one would care if such names didn't tend to leak, but leaking is an interoperability problem.

20. I don't like the text "These queries may constitute an operational problem for operators of root zone authoritative name servers." They're not. But the document is supposed to be a list of problems people have identified without judgment as to their validity, so I won't object to including it. :-) However, the possibility of inadvertent information leakage (a privacy consideration) is also a real one to many people, and perhaps that should be added.

21. The text "If there were no process for assigning names for technical use
      through the IETF, there is a concern that protocols that require
      such names would not be able to get them." seems a little incomplete to me.

I would add something like "This view is usually justified by the observation that the IETF has never asserted control or authority over what protocols are 'allowed' on the internet, and that the principle of 'permissionless innovation' suggests there should be a way for people to include new uses of domain names in new protocols and applications." After all, we don't ask people to prove their application is "good" before we "let" them use TCP for it, even though we're the SDO for TCP. (I'm not personally sure this is a good analogy, but I've heard it. There are plenty of protocol parameter registries for which the policy is "just ask" or FCFS or expert review, so I think this is really a question about registry policy.)

22. You say "In cases where the IETF has made assignments through the RFC 6761 process, technical mistakes have been made," but I admit I'm having trouble identifying an example of an addition to the registry that included such technical mistakes. This text almost sounds like it meant "In cases where the IETF has *not* made assignments through the RFC 6761 process...."

23. You say "In principle, the RFC 6761 process could be used to document the existence of Domain Names that are not safe to assign..." and go on to talk about draft-chapin. This para. mentions root servers again, so my comment above (add the privacy consideration) applies here too.

24. The next para, which begins "There are several Domain Name TLDs that have been commandeered without due process for a variety of purposes [SDO-ICANN-COLL]. The status of these names need to be clarified...." puzzles me. Could you clarify why it's not redundant with the previous case? You cite the same draft for both, but I think you're trying to make different points ("unsafe to assign" vs. "commandeered"-- are they the same thing? Has anyone brought up different risks associated with them?)

25. The para that begins "No mechanism exists for adding a name to the registry...." is talking about two different problems (IETF is responsible, no precedence for assignment). It might be clearer if you separate them.

26. There's also a third point that there's no precedence for resolution, either; there's no mechanism in the registry for specifying which protocol is expected for resolution, so no precedence between the functional default (DNS) and others. SO for instance, the registry won't tell people that the string ".onion" when it appears in their networks in domain name contexts, is supposed to be resolved by an entirely different protocol. This may be a problem with the registry structure rather than its existence or its contents, and it may not be the only one (early versions of draft-adpkja-dnsop-special-names-problem had some discussion of the registry itself IIRC).

27. The text "No process exists for checking documents to make sure they don't accidentally assign names (e.g.  RFC 7788)." could be taken to mean either that the IETF has no such process (and it's true, we don't) or that no one else does either (which is also true). Within the IETF, this breaks the standards process; on the wider scale, it risks collision between the same string being assigned informally to multiple, potentially colliding uses (the folks who wanted to use .home in homenets, and the folks already using .home for something else), with no certainty they won't collide and no rule for determining which use, if either, is an error.

28. The text “It is generally assumed that protocols that need a special-use name need a human-readable special-use name. This assumption may not be warranted in all cases.” doesn’t go far enough. People assume both that they need a human-readable name, and that they need a single label name (“TLD”). Both assumptions, especially together, create a perception that there’s a limited number of useful domain names in the world, with corresponding tendencies to treat the underlying resource as scarce. Domain names aren’t scarce; domain names that meet some of the implicit assumptions people make about them might well be.

---

From: Warren Kumari <[email-masked]>
Date: Sat, 4 Feb 2017 18:08:21 -0500

> initial letter capitalized).

Thank you very much -- Ralph added this (and Suzanne's below) to the
issue tracker. I did the easier part of addressing the nits and
closing the nitty issues. We've published a version to GitHub with
some of the nits addressed, and we will work on addressing more of the
substantive comments.

W

>
> Cheers,
> -Jeremy
>
>
> _______________________________________________
> DNSOP mailing list
> [email-masked]
> 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

---

From: Russ Housley <[email-masked]>
Date: Mon, 6 Feb 2017 14:21:46 -0500

> https://datatracker.ietf.org/doc/draft-ietf-dnsop-sutld-ps/

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

---

From: Ralph Droms <[email-masked]>
Date: Mon, 6 Feb 2017 16:04:05 -0500

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 <[email-masked]> wrote:
> 
>> 
> I think that theSection 3  bullet that references https://www.ietf.org/mail-archive/web/dnsop/current/msg14887.html <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.
> 
> [TP] = https://www.torproject.org <https://www.torproject.org/>
> 
> In Section 4.1.3:
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/dnsop <https://www.ietf.org/mailman/listinfo/dnsop>

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Wed, 8 Feb 2017 10:15:36 +0100

On Thu, Feb 02, 2017 at 06:04:05PM -0500,
 Suzanne Woolf <[email-masked]> wrote 

> "Special-Use Names Problem Statement"

I've read draft-ietf-dnsop-sutld-ps-02

I'm not convinced that there really is a "problem" with special-use
domain names and I would like to see some sort of applicability
statement saying (I send text...) "The issues listed here should not
be interpreted as indicating that special-use domain names should not
be reserved and used. While we may see one day a RFC 6761bis, in the
mean time, the process it describes should continue to be open and
available."

Biggest problem with the draft: it fails to mention the only real
technical problem with RFC 6761, the lack of a formal language for the
registry, thus preventing the programmers of resolving software to
compile automatically the code for the various cases.

I send text: after the paragraph "When a special-use Domain Name is
added to the special-use Domain Names registry, not all software that
processes such names will understand the special use of that name.", add:

  o This problem is made more difficult by the fact that there is no
  formal language for the registry. The list of SUDN with their
  specific requirments is not machine-readable. As a result, software
  developers who write resolving code have to translate the registry
  by hand into their code, a process which is painful, brittle, and
  unlikely to be repeated often (thus making software obsolete with
  respect to the registry).

Now, the details:

> Both ICANN and the IETF have the authority and formal processes to
> coordination process exists.

As I said several times, this is not true
<https://www.ietf.org/liaison/managers.html> Was this mechanism used
once for special-use domain names? What was the result?

> Organizations do in fact sometimes commandeer subsets of the
> namespace. Reasons a third party might do this include:

There are others:

* Intended use is covered by gTLD process, don't recognize ICANN's
right to block these TLD

* Intended use is covered by some IETF process, but the process is too
long, too bureaucratice and too incertain [before you jump on this
one, remember IETF never replied to requests to reserve names like
.bit or .zkey]

> the fact of its unilateral use by the TOR project without following
> the RFC 6761 process

This is ridiculous, .onion was used since 2004
<https://www.usenix.org/legacy/events/sec04/tech/dingledine.html> and
RFC 6761 was published in 2013.

---

From: Ted Lemon <[email-masked]>
Date: Wed, 8 Feb 2017 09:59:26 -0500

I think you have read the draft as if it were about "the problems with special-use names."   This is not the intended reading.   It is intended to be read as "the set of problems that motivated RFC 6761, plus the set of problems that would motivate an update to RFC 6761."

Solutions are out of scope.   It would be helpful if you could read the document again assuming the motivation I just described, and tell me where you think it deviates from that motivation: that is, whether you just mis-read it, and now that I point it out, it's obvious, or whether you think the document doesn't actually do what it sets out to do.

It would be ideal if you could avoid using phrases like "the only problem with RFC 6761."   What you mean, of course, is "the only problem I see with RFC 6761."   Other people see other problems; the point of the document is to list all of those problems, not for everybody to agree that those problems need to be solved.

> On Feb 8, 2017, at 4:15 AM, Stephane Bortzmeyer <[email-masked]> wrote:
>

---

From: "John Levine" <[email-masked]>
Date: 8 Feb 2017 15:11:01 -0000

>compile automatically the code for the various cases.

Considering the vastly different ways that software handles .local and
.onion and example.com and 10.in-addr.arpa, and that next thing to
come along (.homenet?) will likely be different from any of the
existing ones, this strikes me as akin to asking for a pony.

If you just want a list of the names so your recursive resolver can
stub them out, we already have that, of course.

R's,
John

---

From: Suzanne Woolf <[email-masked]>
Date: Wed, 8 Feb 2017 11:06:11 -0500

Hi Stephane,

Thanks for the review, it’s helpful.

> compile automatically the code for the various cases.

If you have a specific suggestion on how to improve the registry, please consider posting an internet-draft. 

The roadmap for DNSOP on special use names has for some time included the expectation that a problem statement would precede solutions, but that problem statement is in WGLC after extensive development, and we’ve returned the alt-tld draft to active status as well. 

We didn’t encourage proposed changes until we had some level of agreement on what problem(s) we might be attempting to solve. However, it seems we’ve now gotten that far.

thanks,
Suzanne

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Wed, 8 Feb 2017 17:27:18 +0100

On Wed, Feb 08, 2017 at 03:11:01PM -0000,
 John Levine <[email-masked]> wrote 
 a message of 16 lines which said:

> Considering the vastly different ways that software handles .local
> and .onion and example.com and 10.in-addr.arpa, and that next thing
> to come along (.homenet?) will likely be different from any of the

Some people in the discussion wanted ICANN to do something. This is
akin to asking for an unicorn (at least, ponies do exist).

> stub them out, we already have that, of course.

URL, please, with the expected behavior of the resolver when queried
for the domain.

---

From: "John R Levine" <[email-masked]>
Date: 8 Feb 2017 11:40:16 -0500

> akin to asking for an unicorn (at least, ponies do exist).

I wouldn't disagree.

> URL, please, with the expected behavior of the resolver when queried

It's the IANA list of special use domains:

http://www.iana.org/assignments/special-use-domain-names/special-use-domain-names.xml 
also available as CSV for the traditionally inclined.

As I said, you might want to have your resolver stub these out to prevent 
leakage if it doesn't know how to handle them.  I use unbound, where it's 
easy to turn them into "local-zone <name> always_nxdomain" which won't 
make applications very happy, but at least they won't leak.

Regards,
John Levine, [email-masked], Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Thu, 9 Feb 2017 17:36:39 +0100

On Wed, Feb 08, 2017 at 11:40:16AM -0500,
 John R Levine <[email-masked]> wrote 

>http://www.iana.org/assignments/special-use-domain-names/special-use-domain-names.xml

It is not complete. For instance, {in-addr,ip6}.arpa domains for the
documentation networks (e.g. 2.0.192.IN-ADDR.ARPA) are not present
(but they are in the other registry,
<https://www.iana.org/assignments/locally-served-dns-zones/locally-served-dns-zones.xml>)

Also, unfortunately, the SU registry it lists the domains, not the
expected behavior (example: .onion requires a NXDOMAIN, .localhost a
reply for A/AAAA queries). So, you still need to read all the RFCs.

---

From: "John R Levine" <[email-masked]>
Date: 9 Feb 2017 13:40:23 -0500

> <https://www.iana.org/assignments/locally-served-dns-zones/locally-served-dns-zones.xml>)

That's an interesting observation.  RFC 6761 imported the RFC 1918 zones 
from RFC 6303 section 4.1, but not the other zones from sections 4.2 
through 4.6.  Was that deliberate of an oversight?

Regards,

---

From: Ted Lemon <[email-masked]>
Date: Thu, 9 Feb 2017 15:34:25 -0500

On Feb 9, 2017, at 1:40 PM, John R Levine <[email-masked]> wrote:
> That's an interesting observation.  RFC 6761 imported the RFC 1918 zones from RFC 6303 section 4.1, but not the other zones from sections 4.2 through 4.6.  Was that deliberate of an oversight?

RFC 6761 doesn't actually reference RFC6303.   I suspect that this was indeed an oversight, although it can also be argued that there is no special need to list these zones in the special-use names registry.

But this inconsistency is certainly worthy of note.

---

From: Ralph Droms <[email-masked]>
Date: Tue, 14 Feb 2017 16:48:06 -0500

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 <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 <[email-masked]> wrote:
>

---

From: Avri Doria <[email-masked]>
Date: Fri, 17 Feb 2017 18:24:28 +0000

Hi,

Just rereading before the meeting.

Re:

> If there is an IETF process through which a name can be assigned at
> zero cost other than time, this process will be used as an alternative
> to purchasing the name through ICANN. 

perhaps just a small thing but it is not really a purchase but more like
a licensing (though am not postive that is the word either)

avri

---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus