Re: [DNSOP] [Ext] Re: meeting agenda?

[Alain Durand]

Is there an agenda ready? Meeting is next week and I’d like to make travel 
arrangement depending on the agenda for 2nd session.

Alain

> On Mar 9, 2018, at 6:08 PM, 神明達哉  wrote:
> 
> Thanks, I'm looking forward to seeing it:-)
> 
>> On Fri, Mar 9, 2018 at 11:05 AM, Tim Wicinski  wrote:
>> 
>> Hi
>> 
>> I have one and was waiting for Suzanne to land in Puerto Rico and we can
>> confirm but you should see that soon enough.
>> 
>> thanks!
>> tim
>> 
>> 
>>> On 3/9/18 14:03, 神明達哉 wrote:
>>> 
>>> dnsop meeting agenda hasn't yet been uploaded on
>>> https://datatracker.ietf.org/meeting/agenda.html
>>> 
>>> Is there at least an unofficial meeting agenda so we can have more
>>> specific idea of what will be discussed?
>>> 
>>> Thanks.
>>> 
>>> --
>>> JINMEI, Tatuya
>>> 
>>> ___
>>> 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

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

Re: [DNSOP] In a vacuum, nobody can hear you scream, was On the call for adoption on Special Use Names

[Alain Durand]

> On Oct 7, 2016, at 6:51 AM, John Levine  wrote:
> 
> f someone creates popular software leaking requests for
> .PICKLE, we can grouse all we want but since we're not the Network
> Police, there's not much we can do about it.

There is not much that can be done after the fact, I agree. However, there is 
something that can be done before: provide a safe place in the DNS tree where 
people can exist without colliding with the rest of the tree. We can't prevent 
people from ignoring it and keep using whatever name they want, but at least we 
would have provided a way to play nice. In that spirit, efforts like .alt and 
friends are a step in the right direction.

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

Re: [DNSOP] On the call for adoption on Special Use Names (Please! Pretty please, with a cherry on top?!)

[Alain Durand]

On Sep 29, 2016, at 8:37 PM, Warren Kumari 
mailto:war...@kumari.net>> wrote:

On Thursday, September 29, 2016, Ted Lemon 
mailto:mel...@fugue.com>> wrote:

So, if anyone is still wondering why we need a /good/ problem statement, this 
discussion is why.  You are both taking past reach other because you are 
looking at only the part of the problem you care about.


... and why we need a Special Use Names problem statement, and not just a 
RFC6761 problem statement. This problem is bigger than just 6761...

We will have to agree to disagree. RFC6761 is the document that created this 
issue. Focusing on what is wrong running its process should be, IMHO, the first 
step. It is like: first, admit we have a problem.

Alain, speaking solely on my own behalf.
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] I-D Action: draft-ietf-dnsop-alt-tld-05.txt

[Alain Durand]

> On Sep 27, 2016, at 2:38 PM, Jim Reid  wrote:
> 
> They both come up short as problem statements IMO. I’m struggling to find 
> words to succinctly describe what problem the WG is expected to solve - sorry 
> about that -- since it appears to be a layer 9+ matter. Both drafts seem to 
> be concerned with treating (some of?) the symptoms rather than the root 
> cause(s). Excuse the pun.

Jim,

When we tried to frame this as L9 issues, the overwhelming wg feedback was: 
keep it technical. So we did, and now people realize there is an elephant in 
the room.
We don’t appear to converge here, and maybe we can’t. See the email Ed Lewis 
sent a few days ago...

Alain.



smime.p7s
Description: S/MIME cryptographic signature
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] More on Special Use Domain Registry

[Alain Durand]

> On Sep 23, 2016, at 8:15 AM, Edward Lewis  wrote:
> 
> If it seems that there is limited discussion during this two-week period and 
> the consensus is that this is not a topic for the WG, I think that it is 
> understandable.  Although many in DNSOP WG have expertise for this, the 
> roster of other work represents "time better spent" means that this work 
> could be pushed off the table.  However, the discussion ought to be resumed 
> somewhere else.  I think that the Special Use Domain Name registry is needed 
> but as it is currently defined, inadequate.

I  tend to agree with you. Let’s see what conclusion the chairs will draw from 
these 2 weeks of discussion…

Alain.




smime.p7s
Description: S/MIME cryptographic signature
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] On the call for adoption on Special Use Names (Please! Pretty please, with a cherry on top?!)

[Alain Durand]

> On Sep 21, 2016, at 8:31 PM, George Michaelson  wrote:
> 
> On the other hand, the longer documents goes further in recognizing
> name processes are really inherently tied to ICANN process more than
> technical merit arguments. This pleases me, because I feel drawn to
> the view the problems are best expressed as "this is done by somebody
> else, in another equity process"

This is an interesting observation, as one of the comments we have received 
many times about the first revisions of draft-adpkja was that the references to 
ICANN were not helping. We even took heat for mentioning 2860...

I guess this reflects on the multitude of diverging opinions on the subject.

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

Re: [DNSOP] moving forward on special use names

[Alain Durand]

> On Sep 20, 2016, at 7:46 AM, Suzanne Woolf  wrote:
> 
> The “toxic waste” names are a “use case” in the sense that people keep asking 
> about. The identified need for a default namespace in the homenet protocols 
> represents another use case.


There are many use cases for reserving names under 6761 or an updated version 
of it. We saw that last year: people have an unlimited imagination on how to 
use such special names… good or bad, this is not the question.

It could be tempting for the problem statement to list all of those use cases. 
Actually, if 6761 did not exist, that might even have been the right thing to 
do. But this is not where we are now.

Where we are is that the iETF ran into a number of issues running both the 
process and the registry described in RFC6761. Draft-adpkja is attempting to 
list those issues, first by looking at process issues (section 3), then issues 
related to the operation of the registry (section 4), and, at last, looking at 
issues related to the strings under consideration themselves (section 4). The 
perspective taken by the authors is that these set of issues are real. Each of 
them need to, and can be, addressed. Hence a problem statement that focuses 
narrowly on something that can be fixed as opposed to boiling the ocean listing 
issues that, if the discussion from the last 18 months is any guidance, the 
working group may never reach consensus on.

Alain, strictly speaking on my own behalf, not my employer’s.




smime.p7s
Description: S/MIME cryptographic signature
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] moving forward on special use names

[Alain Durand]

> On Sep 17, 2016, at 4:08 PM, Ted Lemon  wrote:
> 
> Alain, here's an example, from the abstract:
> 
>When an end-user triggers resolution of a name on a system that
>supports multiple, different protocols or resolution mechanisms, it
>is desirable that the protocol used is unambiguous, and that requests
>intended for one protocol are not inadvertently answered using
>another protocol.
> 
> This is a solution described in terms of a problem, not a problem statement.

Seriously? I don’t see any solution being described here. Plus, this is an 
abstract, not the meat of the document.



> This problem pervades the document.   You haven't stepped back and wiped the 
> slate clean and tried to explain the problem that we have--you've just 
> described the problem with 6761.   You've retrofitted some of what's 
> described in the tldr document, so that the document as it is now is in a 
> sense more comprehensive, but it's still structured on the basis of the set 
> of assumptions you started with, so that it tends to drive in a particular 
> direction, rather than trying to neutrally describe the problems.
> 
> If you look at the tldr document, you will see that the set of problems that 
> are stated there imply _contradictory_ solutions.   This is because that's 
> the problem we face: there is no easy solution to this problem, and we need 
> to consider the tradeoffs.   If I were to read your document without 
> considering the larger problem space, the solution it implies would be very 
> clear.   That's not the case for the tldr document.   There is no one clear 
> solution implied by the tldr document.   That was a deliberate choice.   We, 
> as a working group, need to think about the tradeoffs, and not just go in a 
> particular direction.

On October 8th, 2016, the chairs asked the design team to work on a 6761 
problem statement, Here is the text from Susanne:

""Efforts by the IETF to administer the Special Use Names registry under the 
provisions of RFC 6761 have proven to be controversial, consume large amounts 
of time and attention, and lead to outcomes that are confusing, unsatisfying, 
or both to operators and implementers. As a first stage towards implementing 
the guidance of the IESG on this subject 
(http://www.ietf.org/blog/2015/09/onion/ 
, and IESG comments during the 
discussion of the draft at 
http://datatracker.ietf.org/doc/draft-ietf-dnsop-onion-tld/ballot/ 
), the DT 
is asked to produce a brief internet-draft for Yokohama, outlining the issues. 
It's expected to be structured as a problem statement to the extent practical, 
as we've come to the preliminary conclusion that one of the challenges in 
applying RFC 6761 is that it's unclear on what problem it's intended to solve 
and what criteria to consider.”

It is pretty clear to me that the problem statement was to be limited to 
RFC6761, which we executed on.
You are perfectly free to believe we were wrong in our understanding of the 
chair’s directions, or that, the chairs were wrong in their direction.

The working group now need to decide if they’d rather like a limited and 
concise description of issues surrounding 6761 or if they rather like a 
discussion of the larger issues surrounding special names in general.

Now, I will pause and give space to other working group participants to express 
their opinion.

Alain.




smime.p7s
Description: S/MIME cryptographic signature
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] moving forward on special use names

[Alain Durand]

> On Sep 17, 2016, at 11:38 AM, Ted Lemon  wrote:
> 
> 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.

Ted,

You have repeated that claim many times. I have asked you last meeting, and 
will ask you again, to point out exactly where do you think the current adpkja 
document goes into solution space.

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

Re: [DNSOP] moving forward on special use names

[Alain Durand]

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.



smime.p7s
Description: S/MIME cryptographic signature
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] moving forward on special use names

[Alain Durand]

> On Sep 12, 2016, at 6:43 PM, Warren Kumari  wrote:
> 
> Please, I know many are tired of this topic, but it really is important, so 
> please participate and send in your views.

+1
I also would like to strongly recommend people read the latest version of each 
documents. They both have evolved significantly over time.

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

[DNSOP] New Version Notification for draft-adpkja-dnsop-special-names-problem-06.txt

[Alain Durand]

Dear wg,

We published today a new version of draft-adpkja-dnsop-special-names-problem. 
The draft has been simplified even further in an attempt to make it more 
readable.
Also, the abstract clarifies that this document is a problem statement about 
issues around RFC6761 and not a problem statement around the larger set of 
issues of special use names.

See new abstract:

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.

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

   RFC 6761 introduced a framework by which a particular domain name
   could be acknowledged as being special.  Various challenges have
   become apparent with this application of the guidance provided in RFC
   6761.  This document focuses solely on documenting the specific
   challenges created by RFC 6761 in the form of a problem statement in
   order to facilitate further discussions of potential solutions.  In
   particular, it refrains from proposing or promoting any solution.
   Also, the current document does not focus on other general issues
   related to the use of special use domain names.


URL:
https://www.ietf.org/internet-drafts/draft-adpkja-dnsop-special-names-problem-06.txt


Alain, on behalf of the other authors.

smime.p7s
Description: S/MIME cryptographic signature
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Adopting draft-adpkja-dnsop-special-names-problem as the problem statement for special-use domain names (6761bis)

[Alain Durand]

I’ve updated draft-adpkja-dnsop-special-names-problem to include the two 
missing points raised yesterday by Paul. The new draft is available at:
https://tools.ietf.org/id/draft-adpkja-dnsop-special-names-problem-05.txt

Alain




> On Jun 28, 2016, at 5:27 PM, Alain Durand  wrote:
> 
> Paul,
> 
> 
>> On Jun 28, 2016, at 5:00 PM, Paul Hoffman  wrote:
>> 
>> The other document that this WG has considered, draft-tldr-sutld-ps, has not 
>> been updated to be less wordy and less historical. Having said that, there 
>> are a few bits from Section 4 of that document that I think should be added 
>> to Section 4 of draft-adpkja-dnsop-special-names-problem, namely the 
>> "warranted allocation" problem and the "experimental squatting" problem. I 
>> would like to see those added in the more-terse style of 
>> draft-adpkja-dnsop-special-names-problem. 
> 
> Thank you for your comments and for pointing out those two specific missing 
> elements in draft-adpkja-dnsop-special-names-problem.
> I will take a pass at summarizing thosee two points and post an updated draft.



smime.p7s
Description: S/MIME cryptographic signature
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Adopting draft-adpkja-dnsop-special-names-problem as the problem statement for special-use domain names (6761bis)

[Alain Durand]

Paul,


> On Jun 28, 2016, at 5:00 PM, Paul Hoffman  wrote:
> 
> The other document that this WG has considered, draft-tldr-sutld-ps, has not 
> been updated to be less wordy and less historical. Having said that, there 
> are a few bits from Section 4 of that document that I think should be added 
> to Section 4 of draft-adpkja-dnsop-special-names-problem, namely the 
> "warranted allocation" problem and the "experimental squatting" problem. I 
> would like to see those added in the more-terse style of 
> draft-adpkja-dnsop-special-names-problem. 

Thank you for your comments and for pointing out those two specific missing 
elements in draft-adpkja-dnsop-special-names-problem.
I will take a pass at summarizing thosee two points and post an updated draft.

Alain.

smime.p7s
Description: S/MIME cryptographic signature
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

[DNSOP] New version: draft-adpkja-dnsop-special-names-problem-04.txt

[Alain Durand]

Dear wg,

I’ve updated the 6761 problem statement draft. It is now available at 
https://www.ietf.org/id/draft-adpkja-dnsop-special-names-problem-04.txt 


Changes from the previous version (-03):
- fixed some broken english constructions
- added Frogans as counter example of dot separated namespace
- added references for Dona and Frogans
- clarify that current ICANN gTLD round is closed but not completed
- change tense/mode to conditional about the next round of ICANN gTLD

I’d like to thank the several reviewers of the previous version that sent me 
comments and suggested fix.

Alain.

smime.p7s
Description: S/MIME cryptographic signature
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Working Group Last Call draft-ietf-dnsop-isp-ip6rdns

[Alain Durand]

Section 2.5. "Dynamically Generate PTR When Queried ('On the Fly')" was 
originally written years ago. Some recent announcement from DNS vendors 
generating and signing DNS records on the fly seem to be an existence proof 
that this would actually work and the scalability concerns, certainly valid a 
few years ago, may not be that critical now.

Alain, speaking on my own behalf.



> On Apr 25, 2016, at 4:51 PM, Tim Wicinski  wrote:
> 
> This starts a Working Group Last Call  for draft-ietf-dnsop-isp-ip6rdns
> 
> Current versions of the draft is available here:
> 
> https://datatracker.ietf.org/doc/draft-ietf-dnsop-isp-ip6rdns/
> 
> Please review the draft and offer relevant comments. Also, if someone feels 
> the document is *not* ready for publication, please speak out with your 
> reasons.
> 
> There was a large amount of feedback on the draft prior to it being adopted, 
> and we feel the author addressed all the outstanding issues.
> Please let us know if this is not the case.
> 
> This starts a two week Working Group Last Call process, and ends on
> 9 May 2016.
> 
> thanks
> 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] [rfc-edi...@rfc-editor.org: RFC 7788 on Home Networking Control Protocol]

[Alain Durand]

> On Apr 25, 2016, at 3:31 AM, Stephane Bortzmeyer  wrote:
> 
> On Sun, Apr 24, 2016 at 08:18:35AM +0200,
> Patrik Fältström  wrote 
> a message of 36 lines which said:
> 
>> Either .HOME should not have been mentioned, or it should be added
>> to the registry.
> 
> I fully agree it should have used the RFC 6761 framework. Unfortunately,
> it is closed de facto  So,
> the Homenet people really had no choice.

Of course they had choices. Now, I’m a bit concerned justifications like the 
one above could set a dangerous precedent.
I’m perfectly willing to accept there was no malice in that particular case, 
and it was a “process failure”.
We all make mistake, as individuals or as organizations. That’s human nature. 
The real question is, how do we deal with those mistakes?

Alain, speaking solely as myself, not on behalf of my employers, past, present 
or future.




smime.p7s
Description: S/MIME cryptographic signature
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Alternative Special-Use TLD problem statement draft

[Alain Durand]

> On Apr 7, 2016, at 11:17 AM, Stephane Bortzmeyer  wrote:
> 
> draft-adpkja-dnsop-special-names-problem is full of FUD about how
> ICANN could be pissed off by a decision of the IETF to add 

Stephane,

That is certainly your right to read it that way, but it is not what the 
authors are saying, or at least not what they intended to say.
What draft-adpkja-dnsop-special-names-problem is doing is explaining that all 
names are subject to socio-economic pressures,
and ICANN has had to develop a complex process to evaluate those pressures and 
deal with them. That process may not be perfect, but it exists. 
ETF has no such process in place.

Alain, speaking only for myself.




smime.p7s
Description: S/MIME cryptographic signature
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Formal syntax in the Special-Use domain registry (Was: Alternative Special-Use TLD problem statement draft

[Alain Durand]

On 4/7/16, 8:13 AM, "DNSOP on behalf of Stephane Bortzmeyer"
 wrote:

>It is funny that draft-adpkja-dnsop-special-names-problem spends a lot
>of time in political rants and seldom mentions this very practical
>limit of RFC 6761.

That was mentioned in the -00 version. The point was brought up in
Yokohama, but there was little discussion about it.
It somehow got lost when we shuffled things around to create the -01 and
-02.

Alain.


smime.p7s
Description: S/MIME cryptographic signature
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Alternative Special-Use TLD problem statement draft

[Alain Durand]

From:  DNSOP  on behalf of Ted Lemon

Date:  Wednesday, April 6, 2016 at 2:53 PM
To:  Paul Hoffman 
Cc:  "dnsop@ietf.org" , Ted Lemon 
Subject:  Re: [DNSOP] Alternative Special-Use TLD problem statement draft

So to answer a slightly different question than the one you asked, what I am
proposing is that the working group adopt the tldr document, likely with
changes, rather than adopting the adpkja document, which I think would take
much more work to get into shape.   The entire reason that I started the
tldr document is that I felt that the adpkja document not only didn't
accurately describe the problem, but contained much more text describing
some authors' beliefs about what the solutions should be than text
describing what the problem is.   I also felt that the scope of the adpkja
document was too narrow--it mostly talks about problems with 6761, without
really talking about the greater context of those problems.


‹> Ted,

The recent discussions on the wg mailing list have articulated the tussle
between, on one side the desire for the IETF to foster innovation in the
naming area, and, on the other side, the ability (or not) of the IETF, as an
organization, to deal with the socio-economic aspect such as IPR, etcŠ tied
to those ³special names². The argument being that there is nothing
fundamental that differentiate the strings associated with "special names"
from those associated with regular DNS TLDs, and, as such both are
potentially subject to those pressures.

Reading section 4.2 and 4.3 of draft-tldr-sutld-ps-00, it would appear you
are in the camp that does believe those ³special names² are immune those
socio-economic pressures and/or the IETF can deal with this. Do I get this
right?
If that is the case, then, it is not that one document is better than the
other, there is a  fundamental difference between the perspectives of the
authors.

It should follow that this is a non technical issue that is much larger than
DNSop wg.  As such, the DNSop wg might want to refrain from adopting one or
the other document until the IETF, as a community, under the leadership of
the IAB, comes to an agreement on that fundamental question. After all, the
interpretation of RFC2860 (ICANN/IETF MoU) is the prerogative of the IAB.

Alain, long time IETF participant, speaking solely as myself.




smime.p7s
Description: S/MIME cryptographic signature
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Alain Durand]

> On Mar 29, 2016, at 3:50 PM, Paul Hoffman  wrote:
> 
>> On 29 Mar 2016, at 8:25, Philip Homburg wrote:
>> 
>> One option would be to have a process that essentially says:
>> - The IETF decides whether the proposal is technically sound or not
>> - There is a .alt domain with a registry. Protocols can go there first come,
>>  first served, as long as there is consensus that the proposal is technically
>>  sound.
>> - Any another name, requires approval from ICANN, however the IETF will 
>> inform
>>  ICANN about consensus on the technical quality of the proposal.
>> 
>> This way ICANN can create policy on the name part of special names and the
>> IETF can focus on the technical part of those proposals.
> 
> This process would possibly work for the IETF, but how would it work for the 
> developer of the technical protocol? They would not know what name to use in 
> practice until after the IETF consensus call was finished. However, it is 
> clear that many people in the community consider part of the technical review 
> process the question of are there any/many users for the name. In order to 
> get some, they need to start using a TLD (not .alt) name knowing that, if 
> they get rejected, they have to change the name in all deployed instances. 
> Technically, that's feasible; operationally, it is not.

This should be the opposite: start with a name with little perceived value, 
under .ALT or anything already existing, and then if you are successful apply 
for something of higher perceived value and change name in deployed code.
Seems like regular business model to me.

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

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

[Alain Durand]

> On Mar 28, 2016, at 10:05 PM, Andrew Sullivan  wrote:
> 
> On Mon, Mar 28, 2016 at 10:32:41PM +0000, Alain Durand wrote:
> 
>> My perspective is that, at the end of the day, a name is a name is a
>> name.
> 
> Your argument is now circular.  You cannot use a premise that no names
> are special as a premise to draw your conclusion that no names are
> special.


I’m sorry my point remains unclear. Let me try again:

All strings, regardless of the intend to be placed on the 6761 registry or in 
the DNS root zone, are potentially subjects to IPR & socio-economic issues.

There is nothing circular here. Do you agree or not with that statement?

Alain.

smime.p7s
Description: S/MIME cryptographic signature
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Alain Durand]

I'm sorry if my point was not clear. My perspective is that, at the end of the 
day, a name is a name is a name. Being on the 6761 registry or in the DNS root 
zone is fundamentally irrelevant when it comes to IPR and other related 
socio-political issues. The same concerns apply.

Alain, speaking solely for myself.

> On Mar 28, 2016, at 5:54 PM, Ralph Droms  wrote:
> 
> 
>> 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
> 

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

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

[Alain Durand]

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...

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

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

[Alain Durand]

Sent from my iPhone
> On Mar 28, 2016, at 1:31 PM, Suzanne Woolf  wrote:
> 
> As a practical focus: sometime ago, DNSOP adopted and then parked 
> https://datatracker.ietf.org/doc/draft-ietf-dnsop-alt-tld/. This draft 
> proposes a special use names registry entry that would be expected to 
> function as the rightmost label in names intended for resolution outside of 
> the DNS protocol: something of a meta-protocol switch.

Such a solution as the clear benefit to get the IETF out of the name evaluation 
quagmire. The more I look into it, the more I'm drawn to a solution that would 
look like this: apply 6761 one last time to create .alt (or ._ or whatever) and 
*then* close the registry.

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

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

[Alain Durand]

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.
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.


Alain, speaking for myself.



smime.p7s
Description: S/MIME cryptographic signature
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Alain Durand]

> On Mar 25, 2016, at 1:48 PM, Ralph Droms  wrote:
> 
>>> 
>>> 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.


Let me speak here solely as a long time (20+ year) IETF participant that has 
been through successes and failures of this organization.
IMHO, a "more well-defined decision process" would not help, as I would argue 
that the IETF (and the IESG as well) is ill-equipped
to wade in the political/economic/social space tied to policies evaluating 
which names are OK to reserve and which ones are not.
My applies to any names, being “special" or not.

RFC2860 section 4.3 recognized this inadequacy very clearly:
"Two particular assigned spaces present policy issues in addition to the 
technical considerations specified by the IETF:
the assignment of domain names, and the assignment of IP address blocks. These 
policy issues are outside the scope of this MOU.”

At the end of the day, this is the key issue in 6761.

Alain.





smime.p7s
Description: S/MIME cryptographic signature
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Alain Durand]

Dear wg,

draft-adpkja-dnsop-special-names-problem-01 has been posted today. It is
available at:

https://www.ietf.org/internet-drafts/draft-adpkja-dnsop-special-names-proble
m-01.txt



It is an individual submission, not a working group item. It reflects the
discussions the initial 3 authors have had so far. Also, Warren Kumari
provided lots of input and generously contributed significant amount of
text. In the tradition of IETF recognizing contributions, we have added
Warren to the author list.



The authors know that the subject addressed in this document is
controversial. We hope it will help clarify the discussion. In many places,
we know different opinion exits. We have tried to reflect the existence of
those opposition views to the best of our possibilities.



We would like to see discussion of those views in the mailing list to help
us prepare the next version of this draft with the goal to ask the working
group to adopt it.



Best,



Alain, on behalf of the document authors.








smime.p7s
Description: S/MIME cryptographic signature
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Questions about draft-adpkja-dnsop-special-names-problem-00

[Alain Durand]

Stephane,

The following paragraph in section 2 was an attempt at capturing your point:

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

Alain.


> On Nov 4, 2015, at 7:52 AM, Stephane Bortzmeyer  wrote:
> 
> On Wed, Nov 04, 2015 at 12:20:27PM +0900,
> Stephane Bortzmeyer  wrote 
> a message of 73 lines which said:
> 
>> draft-adpkja-dnsop-special-names-problem-00 raises several issues,
> 
> And I forgot one of the most important ones, but I remembered it
> during a discussion over sashimi this evening (the sashimi were good,
> thanks).
> 
> The entire section 2, about "switches" is questionable because using
> .bit or .onion is not only to change the *resolution* protocol but
> also (and specially) to change the *registration* process.
> 
> These are two different systems. Of course, they have some links (the
> fact that domain names are organized into a tree is used by the DNS
> protocol for fast resolution) but not identical. The current version
> of the draft says "any TLD registered in IANA-maintained root-zone
> (use DNS)" which is not quite exact. Names registered in the
> RFC2826-root are often looked up through the DNS but not always (some
> people use local hosts file or LDAP to do it). And, more important,
> some TLDs outside of the RFC2826-root do not always indicate a
> switch. This is the case of .bit (if you already know Namecoin, you
> can skip the next paragraph).
> 
> Namecoin uses a blockchain to store registered names. That way, you
> can have meaningful names without a registry. Because few clients
> speak the Namecoin API, most of the times, name resolution is done
> through the DNS: you set up a local authoritative name server to
> export data from the blockchain into a .bit zone that you load.
> 
> This example clearly shows that the TLD is not a "protocol
> switch". That's because Namecoin is intended to address perceived
> problems with the registration system, not with the DNS.
> 
> 
> 
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop



smime.p7s
Description: S/MIME cryptographic signature
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] New Version Notification for draft-jjmb-sunset4-dns-forwarding-ipv4aas-00.txt

[Alain Durand]

> On Nov 3, 2015, at 7:01 PM, Tony Finch  wrote:
> 
> Alain Durand  wrote:
>> 
>> In the particular case of the communication between the CPE and the ISP
>> DNS recursive resolver, the two parties are within the same administrative
>> authority. Thus, the need to make a BCP is much lower. This can be seen
>> as simply an implementation issue.
> 
> But there needs to be a specification for interop between the CPE and the
> ISP's network, so the ISP knows which suppliers they can buy equipment from.

Exactly. This is specified in each of the various IPv4aas docs, as I pointed 
out earlier, along with the other things the CPE and the device on the ISP side 
must agree to do, such as packet format, address/port syntax, etc...

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

Re: [DNSOP] New Version Notification for draft-jjmb-sunset4-dns-forwarding-ipv4aas-00.txt

[Alain Durand]

> On Nov 3, 2015, at 3:41 AM, Ebersman, Paul  
> wrote:
> 
> 
> On 03Nov, 2015, at 5:31 PM, Alain Durand  wrote:
> 
>> In the particular case of the communication between the CPE and the ISP
>> DNS recursive resolver, the two parties are within the same administrative
>> authority. Thus, the need to make a BCP is much lower. This can be seen
>> as simply an implementation issue. In other words, there are other
>> solutions that could be used, for example a translation of the DNS packets
>> from IPv4 to IPv6. Such a translation may or may not be optimal, but it
>> would work and, more importantly, would not break the DNS resolution and
>> would have no impact on the stability of the DNS system as a whole.
> 
> Putting in a second DNS server that does nothing but forward everything just 
> to
> translate v4 to v6 does indeed have an impact on stability if you try to do it
> at large scale. It impacts infrastructure costs, performance and potentlally 
> confuses
> geo-ip/cdn. It also adds complexity in debugging.

I was talking about doing the translation in the CPE. But, the larger point is, 
this was just an example of something else that could be done, although, I 
agree, sub-optimally.
What draft-jjmb-sunset4-dns-forwarding-ipv4aas-00.txt proposes is reasonable, 
no objections. However, as far as I know, this is already being documented by 
the various IPv4aas solutions.

Alain.

smime.p7s
Description: S/MIME cryptographic signature
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] New Version Notification for draft-jjmb-sunset4-dns-forwarding-ipv4aas-00.txt

[Alain Durand]

I thought about it and re-read what we wrote in 3901.

3901 talks about servers that need to deal with other parties: recursive
resolvers and zone servers. It provides guidelines for the stability of
entire DNS system.

In the particular case of the communication between the CPE and the ISP
DNS recursive resolver, the two parties are within the same administrative
 authority. Thus, the need to make a BCP is much lower. This can be seen
as simply an implementation issue. In other words, there are other
solutions that could be used, for example a translation of the DNS packets
from IPv4 to IPv6. Such a translation may or may not be optimal, but it
would work and, more importantly, would not break the DNS resolution and
would have no impact on the stability of the DNS system as a whole.

As such, I¹m not convinced we should re-open 3901 for this purpose.

Alain.



On 11/3/15, 12:37 AM, "DNSOP on behalf of Mark Andrews"
 wrote:

>
>Also perhaps we should be looking at RFC3901bis.  Alain, Johan are you
>interested?
>
>Mark
>
>In message <20151103052757.daf2d3bbb...@rock.dv.isc.org>, Mark Andrews
>writes:
>> 
>> The simplest way to force this is for the ISP to only supply IPv6
>> recursive recursive servers to the CPE where 464XLAT / MAP* / DS-Lite
>> is in use.  Also if a DUID is presented over DHCPv4 (RFC 4361) don't
>> return nameservers.  The CPE device should be getting nameservers
>> via RA/DHCPv6 in this case.
>> 
>> The CPE at this point can only advertise it's own addresses IPv4
>> address or manually configured addresses.
>> 
>> Iterative servers should prefer IPv6.
>> 
>> 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
>-- 
>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


smime.p7s
Description: S/MIME cryptographic signature
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Draft -domain-names-01

[Alain Durand]

Ed's document is not about DNS but about names. That is actually the whole 
point. So, IMHO, it should not be redirected to a wg that needs better 
understanding of DNS but to a wg that needs better understanding of names...

I could also argue that this argument also applies to the discussion on  issues 
around 6761. There is little DNS specific there, let alone DNS operational...

Alain

On Nov 3, 2015, at 4:40 PM, Tim WIcinski 
mailto:tjw.i...@gmail.com>> wrote:


I spoke to Ed this morning during breakfast, and we discussed his draft.  I do 
like this as a well written read through the history of namespace and domains, 
but I feel (and I think Ed even would agree) this is not so much a DNSOP 
document, but something that should be in an area where they need a better 
understanding of DNS (*cough* appsawg *cough*).

How does the working group think of this?

thanks
tim

On 10/30/15 8:23 PM, Edward Lewis wrote:

A while back I floated a draft across this mail list and got (what I
think) is sufficient (perhaps not the right word) feedback from the WG.  I
updated the document and resubmitted.  FWIW, this is the document link:
https://tools.ietf.org/html/draft-lewis-domain-names-01

I'm not even asking for comment on the list (but you can if you want).
When I rev'd the document, I didn't mention it on this list (until now).

What I'm asking for is - when in Yokohama, if you have an interest in this
I'm willing to discuss.

The issue in the document is both internal to DNS and external to DNS, I'm
looking for broader input (such as applications area topics).

Ed




___
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] New Version Notification for draft-jjmb-sunset4-dns-forwarding-ipv4aas-00.txt

[Alain Durand]

John,

Such recommendation can be found in various IPv4aas documents. See RFC6333
section 5.5 [DS-lite] , RFC7596 section 5.1 [lw4over6] and RFC7597 section
10 [MAP]. Curious, what is the rationale to spell this out in a separate
document?

Alain



On 11/2/15, 11:30 PM, "DNSOP on behalf of Brzozowski, John"

wrote:

>Cross posting with dnsop and sunsets per email exchanges/conversations
>with both sets of chairs.
>
>John
>
>-Original Message-
>From: John Jason Brzozowski 
>Date: Monday, November 2, 2015 at 17:21
>To: "suns...@ietf.org" 
>Cc: Fred Baker , "suzworldw...@gmail.com"
>, "tjw.i...@gmail.com" , Joel
>Jaeggli , Paul Ebersman
>, Brian Haberman
>, "terry.mander...@icann.org"
>, Wesley George ,
>Marc Blanchet 
>Subject: New Version Notification for
>draft-jjmb-sunset4-dns-forwarding-ipv4aas-00.txt
>
>>sunset4,
>>
>>Please see the following I-D that was submitted earlier today.  We would
>>appreciate your feedback and comments.  I had some offline email with the
>>dnsop and v6ops chairs and ADs (they are copied instead of cross posting
>>for now).  The guidance I received was to post this here to sunset4.
>>
>>Thanks,
>>
>>John
>>+1-484-962-0060
>>
>>
>>
>>
>>-Original Message-
>>From: "internet-dra...@ietf.org" 
>>Date: Monday, November 2, 2015 at 16:48
>>To: Paul Ebersman , John Jason
>>Brzozowski
>>
>>Subject: New Version Notification for
>>draft-jjmb-sunset4-dns-forwarding-ipv4aas-00.txt
>>
>>>
>>>A new version of I-D, draft-jjmb-sunset4-dns-forwarding-ipv4aas-00.txt
>>>has been successfully submitted by John Jason Brzozowski and posted to
>>>the
>>>IETF repository.
>>>
>>>Name:draft-jjmb-sunset4-dns-forwarding-ipv4aas
>>>Revision:00
>>>Title:   DNS Forwarding and IPv4aaS
>>>Document date:   2015-11-02
>>>Group:   Individual Submission
>>>Pages:   7
>>>URL:
>>>https://www.ietf.org/internet-drafts/draft-jjmb-sunset4-dns-forwarding-i
>>>p
>>>v
>>>4aas-00.txt
>>>Status: 
>>>https://datatracker.ietf.org/doc/draft-jjmb-sunset4-dns-forwarding-ipv4a
>>>a
>>>s
>>>/
>>>Htmlized:   
>>>https://tools.ietf.org/html/draft-jjmb-sunset4-dns-forwarding-ipv4aas-00
>>>
>>>
>>>Abstract:
>>>   The depletion of IPv4 coupled with the wide spread deployment of IPv6
>>>   for broadband globally is creating an environment where service
>>>   providers can seriously begin to consider alternate uses and
>>>   applications for native IPv6 connectivity.  Pervasive, reliable
>>>   support for IPv6 across many access technologies suggests that one
>>>   critical use for native IPv6 is the carry legacy IPv4 communications.
>>>   Today this is referred to as IPv4 as a Service (IPv4aaS).  IPv4aaS
>>>   can leverage a variety of transports ranging from Mapping of Address
>>>   and Ports (MAP) to Generic Route Encapsulation (GRE) along with other
>>>   viable protocols.  Most every use case for IPv4aaS includes the use
>>>   of CG-NAT, however, this is not strictly required.  The purpose of
>>>   this document is to hone in on DNS specific behavior that must be
>>>   taken into consideration as the deployment of IPv4aaS advances
>>>   globally.
>>>
>>>
>>>
>>>
>>>
>>>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.
>>>
>>>The IETF Secretariat
>>>
>>>
>>
>
>___
>DNSOP mailing list
>DNSOP@ietf.org
>https://www.ietf.org/mailman/listinfo/dnsop


smime.p7s
Description: S/MIME cryptographic signature
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Thoughts on the top level name space

[Alain Durand]

On 7/7/15, 8:28 PM, "DNSOP on behalf of hellekin"  wrote:

>In my opinion, what we need is already there, and is called RFC6761.
>Now I'm all ears for what needs to be done to enhance RFC6761 process.

Here is a short list:

- RFC6761 does not say anything wrt to coordination between IETF and ICANN
on this topic.
- RFC6761 talks about names, not TLDs. i.e. It could be use to reserve a
name under any existing TLD.
- RFC6761 does not say much about how to evaluate the merits of proposals.
That made the discussion
  on the current crop of candidates difficult.

I¹m sure there are more issues. It would be great to discuss this in
Prague.

Alain


smime.p7s
Description: S/MIME cryptographic signature
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Thoughts on the top level name space

[Alain Durand]

Putting the focus on this part of Steve¹s original email for now:

On 7/5/15, 7:26 AM, "DNSOP on behalf of Steve Crocker"
 wrote:

>
>o ICANN speaks indistinctly about subset 5.
>
>o Does the IETF have a process for moving a name from subset 2 to subset
>4?

Ideally, I would argue we may not need such a process. Beside
experimentation with strings like xx-Š, subset 2 should be empty or, at
least, not ground for consideration to move to subset 4. So, beside
grand-fathering a few strings, what is needed is a process that is less
ambiguous and simpler to evaluate than RFC6761 to reserve strings in
subset 4. Maybe something along the lines of IETF validates the technical
merits of the proposal and ICANN validates the suggested nameŠ That leads
us to the next point:

>o A process for coordination between the IETF and ICANN regarding subsets
>2, 4 and 5 would be helpful.


RFC6761 does not say anything about such a coordination process. We have
now learned a lot going through this round of 6761 candidates, so it is
time to work on 6761bis, with, among other things, this coordination
between ICANN and IETF on the agenda.

Alain.


smime.p7s
Description: S/MIME cryptographic signature
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Interim Meeting on Special Names and RFC 6761

[Alain Durand]

On 4/30/15, 11:23 AM, "Warren Kumari"  wrote:

>The RIPE staff has been very nice and made a room available at RIPE-70
>:
>
> Meerman I/II for ~30 people on Tuesday 12 May 18:00- 20:00 Amsterdam
>
> Jaap


Very cool. Do we need to sign up?

Alain.


smime.p7s
Description: S/MIME cryptographic signature
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] draft-howard-isp-ip6rdns-07.txt

[Alain Durand]

Commenting on an old draft I had worked/started with Lee on many years
agoŠ!

1) The intro should make it clear that this document DOES NOT recommend
any solutions, it just describe the trade-offs. In fact, none of the
solutions are really good.

2) there should be a longer discussion of hosts using privacy extensions
RFC4941.
What is the intended behavior here? Do those hosts need/want a reverse DNS
entry? There is some text in section 2.3.1 but, IMHO, there should be a
whole section toward the beginning of the document discussing this.

3) There is another solution, that is do nothing, i.e. Do NOT populate the
reverse tree.
   Probably ISPs on that path would like to see an update to RFC1033 &
RFC1912 to
   explicitly say that the PTR record requirement is relaxed in IPv6 (and
maybe
   in IPv4 as well?)

The mere fact that this draft is still here many years after the effort
was started should tell us somethingŠ It would appear as if the world is
on path 3) above.


Alain.





On 3/31/15, 9:46 AM, "Lee Howard"  wrote:

>There's been no discussion since this revision.
>The Chairs have asked for a couple of reviews. I've asked a couple of
>folks, but haven't had any response.
>
>Looking for a few folks to do a close read. Send notes to the list, and
>I'll make necessary revisions. If it's baked, I think there's consensus.
>
>Thanks,
>
>Lee
>
>On 2/15/15, 11:56 AM, "Lee Howard"  wrote:
>
>>Per discussion, I have added the four use cases discussed at a previous
>>meeting.  
>>The "Recommendations" section is now "Considerations and
>>Recommendations."
>>The guidance from the WG was that ISPs should be advised of how PTRs are
>>used, so they can decide how important it is to populate them. I left in
>>the recommendations from before, since an ISP might decide it's
>>important.
>>
>>I think the references to other ongoing work are up to date, but let me
>>know if I've missed anything, please.
>>
>>We had pretty strong support the last time we discussed aloud
>>(spontaneous
>>applause).  Is this document ripe for publication?
>>
>>
>>Thanks,
>>Lee
>>
>>On 2/15/15 11:46 AM, "internet-dra...@ietf.org"
>>
>>wrote:
>>
>>>
>>>A new version of I-D, draft-howard-isp-ip6rdns-07.txt
>>>has been successfully submitted by Lee Howard and posted to the
>>>IETF repository.
>>>
>>>Name:draft-howard-isp-ip6rdns
>>>Revision:07
>>>Title:   Reverse DNS in IPv6 for Internet Service Providers
>>>Document date:   2015-02-16
>>>Group:   Individual Submission
>>>Pages:   14
>>>URL:
>>>http://www.ietf.org/internet-drafts/draft-howard-isp-ip6rdns-07.txt
>>>Status: 
>>>https://datatracker.ietf.org/doc/draft-howard-isp-ip6rdns/
>>>Htmlized:   http://tools.ietf.org/html/draft-howard-isp-ip6rdns-07
>>>Diff:   
>>>http://www.ietf.org/rfcdiff?url2=draft-howard-isp-ip6rdns-07
>>>
>>>Abstract:
>>>   In IPv4, Internet Service Providers (ISPs) commonly provide IN-
>>>   ADDR.ARPA information for their customers by prepopulating the zone
>>>   with one PTR record for every available address.  This practice does
>>>   not scale in IPv6.  This document analyzes different approaches and
>>>   considerations for ISPs in managing the ip6.arpa zone for IPv6
>>>   address space assigned to many customers.
>>>
>>>
>>>
>>>
>>>
>>>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.
>>>
>>>The IETF Secretariat
>>>
>>
>>
>>___
>>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


smime.p7s
Description: S/MIME cryptographic signature
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop