Subject: [regext] draft-ietf-eppext-keyrelay unreasonably stuck on IPR?

From: Job Snijders <[email-masked]>
Date: Tue, 8 Nov 2016 15:47:42 +0100

Dear IETF,

Since the EPPEXT Working Group has been concluded and evolved into
regext, I'm reaching out to the bigger group about a document that
somehow is stuck.

The keyrelay specification describes how one can change the DNS operator
of a domain while keeping the DNSSEC chain of trust intact. Obviously
this beats the current "not-the-best" practise of going insecure,
transferring and then securing the domain again.

Background info on secure domain transfers:

    http://www.internetsociety.org/deploy360/blog/2013/09/how-to-securely-transfer-a-dnssec-signed-domain-between-dns-operators-sidns-epp-keyrelay/
    https://www.sidnlabs.nl/downloads/wp_2013_EPP-keyrelay_v1.en.pdf

Draft-ietf-eppext-keyrelay can't progress due to a DISCUSS from Stephen
Farrell. Farrel raised because the IPR situation is not succinctly
clear: https://datatracker.ietf.org/doc/draft-ietf-eppext-keyrelay/ballot/

>From the IPR details here listed at
https://datatracker.ietf.org/ipr/2393/ I quote:

    """Licensing Declaration to be Provided Later (implies a willingness
    to commit to the provisions of a), b), or c) above to all
    implementers; otherwise, the next option 'Unwilling to Commit to the
    Provisions of a), b), or c) Above'. - must be selected)"""

The IPR statement was submitted on July 21, 2014.  I am not sure what
the capitalisation of the words "Provided Later" signifies - but surely
the purpose of this process is not to stall and leave a document in
limbo forever. I appreciate that IPR related work can take time, but
this long? A convenient counter is provided here: https://rikribbers.nl/keyrelay/

I've asked the keyrelay authors what attempts have been undertaken to
resolve the situation, and according to them attempts to communicate
with the (presumably a legal department) contact persons listed at
https://datatracker.ietf.org/ipr/2393/ have gone unanswered, and the
IETF participant whose belief triggered the disclosure has not been able
to progress the issue either. A promise such as "soon" is appreciated,
but not sufficient: https://mailarchive.ietf.org/arch/msg/regext/SbwMA57ebzMjKwaphz6AZzliMM0

For those that wonder what the impact of stonewalling this document is:
the SIDN (the .nl registry) has put their current deployment on hold.
The SIDN had implemented keyrelay in their Shared Registry System to
verify if a domain transfer can be done while keeping the DNSSEC chain
of trust intact. However registrars are waiting for keyrelay to be
published as a real standard, in absence of that:
secure->insecure->transfer->secure.

Should you wonder why the Dutch are growing impatient... The Dutch
registry is globally a leader in terms of DNSSEC deployment. With over
2.5 million DNSSEC secured domain registrations, the ability to securely
transfer is critical! There are ~ 22,000 .nl-domainname transfers per
month.

Adoption of secure transfers should have been in place before DNSSEC
validating resolvers became the norm.

Aside from the 'keyrelay'-specific concerns I described above, I worry
that IPR disclosures can be used as an obstructionist attack vector to
indefinitely stall a document's publication. File a patent, file a
disclosure, never provide licensing information! That doesn't seem right.

Kind regards,

Job

---

From: S Moonesamy <[email-masked]>
Date: Tue, 08 Nov 2016 10:40:59 -0800

Hi Job,
>regext, I'm reaching out to the bigger group about a document that

Did the authors or Working Group address the second part of the DISCUSS?

Regards,
S. Moonesamy

P.S. There may have been a communication breakdown as the draft 
started in EPPEXT which no longer exists.  There was also some 
personnel changes along the way.

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Tue, 8 Nov 2016 19:40:19 +0000

(Removing the IETF list)

> -----Original Message-----
> From: Job Snijders [mailto:[email-masked]]
> Sent: Tuesday, November 08, 2016 9:48 AM
> To: [email-masked]; [email-masked]; Livesay, Paul; Hollenbeck, Scott;
> [email-masked]
> Subject: draft-ietf-eppext-keyrelay unreasonably stuck on IPR?
> 
> Dear IETF,
> 
>     http://www.internetsociety.org/deploy360/blog/2013/09/how-to-
> securely-transfer-a-dnssec-signed-domain-between-dns-operators-sidns-
> epp-keyrelay/
> but not sufficient:
> https://mailarchive.ietf.org/arch/msg/regext/SbwMA57ebzMjKwaphz6AZzliMM
> 0

This is the latest information I (I am the IETF participant whose belief triggered the disclosure) have as of right now: the patent has not been issued, and so Verisign does not know which, if any, claims will be allowed. The disclosure will be updated when the application process has been completed by the patent office.

Scott

---

From: Rik Ribbers <[email-masked]>
Date: Tue, 8 Nov 2016 19:53:01 +0000

Yes, this was addressed during the IESG review last december and resulted in the latest version. The only thing blocking is the IPR-disclosure

Gr,
Rik

On 8 Nov 2016, at 19:40, S Moonesamy <[email-masked]<mailto:[email-masked]>> wrote:

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 8 Nov 2016 19:57:57 +0000

> Did the authors or Working Group address the second part of the DISCUSS?

I believe they did. It's so long ago though I forget;-)

As to the meat of this, my discuss says "the DISCUSS is to ask
did I miss stuff and if not how can WG participants have
rationally considered an IPR declaration if the licensing
information will only arrive "later" after the document is
approved to become an RFC?"

As Job says, the reaction from the folks who declared IPR was
that they needed a bit of time to check internally. And it
seems that they gave that response again again some months
later.

I also chatted with Job about this a while back and indicated
that I'd be willing to clear (though not happy to clear) if the
response from the WG (via the chairs or AD) were something like
"the WG has consensus to live with the crap situation, seems
like it's not improving and we don't have anyone saying it out
be blocking."  I don't think I ever did hear that back from anyone
though. Had I, I would have cleared the discuss. (And apologies
if I missed a statement to that effect.)

S.

> 
> Regards,
> S. Moonesamy
> 
> P.S. There may have been a communication breakdown as the draft started
> in EPPEXT which no longer exists.  There was also some personnel changes
> along the way.
>

---

From: S Moonesamy <[email-masked]>
Date: Tue, 08 Nov 2016 12:01:14 -0800

Hi Rik, Stephen,

[ietf@ removed from Cc]

At 11:53 08-11-2016, Rik Ribbers wrote:
>Yes, this was addressed during the IESG review last december and 
>resulted in the latest version. The only thing blocking is the IPR-disclosure

Thank you for confirming that.

>approved to become an RFC?"

[snip]

>if I missed a statement to that effect.)

Thanks.  I gather that the above is clear enough for the Working 
Group to address the DISCUSS.

Regards,
S. Moonesamy

---

From: Job Snijders <[email-masked]>
Date: Wed, 9 Nov 2016 10:35:24 +0100

On Tue, Nov 08, 2016 at 07:40:19PM +0000, Hollenbeck, Scott wrote:
> >     """Licensing Declaration to be Provided Later (implies a
> >     willingness to commit to the provisions of a), b), or c) above
> >     to all implementers; otherwise, the next option 'Unwilling to
> >     Commit to the Provisions of a), b), or c) Above'. - must be
> >     selected)"""
> > 
> > limbo forever. 
> > A promise such as "soon" is appreciated, but not sufficient:
> This is the latest information I (I am the IETF participant whose
> belief triggered the disclosure) have as of right now: the patent has
> not been issued, and so Verisign does not know which, if any, claims
> will be allowed. The disclosure will be updated when the application
> process has been completed by the patent office.

Dear Scott,

There can be any number of years between filing and issuance, there is
no assurance that USPTO will be able to progress the application in the
immediate or distant future.

How does the Internet community benefit from not having a standardized
way to securely transfer domainnames?

I have to ask: is VeriSign purposefully obstructing the publication of
the draft-ietf-eppext-keyrelay document?

Because Verisign still has the option to provide a more detailed
Licensing Declaration ahead of the issuance, covering whatever claims
(if any) will be allowed.

Why has Versign choosen not to provide a Licensing Declaration such as
option A ('no license'), B ('Free RAND'), C ('RAND') or E ('NOPE')?

In failing to provide clarity to the internet engineering community,
Verisign is arguably obstructing much needed internet security
mechanisms. 

Regards,

Job

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Wed, 9 Nov 2016 12:19:44 +0000

> Sent: Wednesday, November 09, 2016 4:35 AM
> To: Hollenbeck, Scott; Stephen Farrell
> Cc: [email-masked]; Livesay, Paul; draft-ietf-eppext-
> [email-masked]
> Subject: Re: draft-ietf-eppext-keyrelay unreasonably stuck on IPR?
> 

No, not at all. Document publication was held up by a single IESG evaluation discussion point that could have been cleared *at any time* if members of the WG responded to the two points raised by Stephen. It might help to read Stephen's ballot position (https://datatracker.ietf.org/doc/draft-ietf-eppext-keyrelay/ballot/). Point 1:

"Note: If I am explicitly told that this was considered and participants were ok with the declaration even as-is, then I'll clear."

This never happened. Point 2:

"I think you need to be clear about which of these cases is actually being supported and about the overall sequence of events needed. (If you tell me that you really want to do whatever is in draft-koch, then that's fine but then this draft is probably premature and draft-koch would need to be a normative ref.)"

This never happened, either. Failure to address these two points is what held up the document, not the disclosure that I as an IETF participant was required to make.

> Verisign is arguably obstructing much needed internet security

In my last note I explained why the decision was made to not update the disclosure: we do not know if the patent will be granted, and we do not know which, if any, of the claims will be allowed. We cannot provide a definitive licensing declaration for something that remains unknown.

Scott

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Wed, 9 Nov 2016 13:20:37 +0000

> From: Antoin Verschuren [mailto:[email-masked]]
> Sent: Wednesday, November 09, 2016 8:05 AM
> To: Hollenbeck, Scott
> Cc: Job Snijders; Stephen Farrell; draft-ietf-eppext-
> [email-masked]; Livesay, Paul; [email-masked]
> Subject: Re: [regext] draft-ietf-eppext-keyrelay unreasonably stuck on
> IPR?
> 
> Op 9 nov. 2016, om 13:19 heeft Hollenbeck, Scott
> <[email-masked]> het volgende geschreven:
> 
> > "I think you need to be clear about which of these cases is actually
> being supported and about the overall sequence of events needed. (If
> you tell me that you really want to do whatever is in draft-koch, then
> that's fine but then this draft is probably premature and draft-koch
> would need to be a normative ref.)"
> >
> > This never happened, either. Failure to address these two points is
> what held up the document, not the disclosure that I as an IETF
> participant was required to make.
> 
> I need to correct you on this one Scott.
> Issue 2 was resolved in the latest version of the draft (12), as
> communicated by Rik:
> https://mailarchive.ietf.org/arch/msg/regext/Y_6WuONMXiQolqfguUcfdgA6uD
> s
> 
> The authors chose to adjust text in stead of reviving draft-koch and
> make it a normative reference, even though the authors of draft-koch
> are happy to revive the draft and ask for adoption by the DNSOPS WG.
> 
> The reason for this is that draft-koch is harassed by the same IPR, and
> the cause why adoption by the DNSOPS WG never happened.
> It's been in that state for so long now, that copies of the secure
> transfer concept start to appear in new drafts targeted for DNSOPS like
> https://datatracker.ietf.org/doc/draft-pounsett-transferring-automated-
> dnssec-zones/ which are then also targeted by the IPR because
> participants don't remember anymore.

OK, thanks, good to know. The discuss should have been updated to note that change.

Scott

---

From: Jelte Jansen <[email-masked]>
Date: Wed, 9 Nov 2016 14:33:59 +0100

> This never happened. Point 2:

seems to me the participants weren't (and aren't), then.

> In my last note I explained why the decision was made to not update the disclosure: we do not know if the patent will be granted, and we do not know which, if any, of the claims will be allowed. We…

So Verisign cannot make a statement because the patent application
status is unclear, but the WG is expected to make a statement despite
the IPR claims/licensing terms being unclear?

A statement like 'if claims X and Y are allowed, we shall require
licensing' or 'we shall go full FRAND' doesn't seem that much to ask
for. Less so than the WG saying 'terms provided later are ok'.

Jelte

---

From: Job Snijders <[email-masked]>
Date: Wed, 9 Nov 2016 14:41:14 +0100

On Wed, Nov 09, 2016 at 12:19:44PM +0000, Hollenbeck, Scott wrote:
> In my last note I explained why the decision was made to not update
> the disclosure: we do not know if the patent will be granted, and we
> do not know which, if any, of the claims will be allowed. We cannot
> provide a definitive licensing declaration for something that remains
> unknown.

No. Verisign has submitted a patent and is fully aware what the contents
of that submission are. Verisign is also in a position to decide what
the licensing will look like depending on the possible outcomes for the
USPTO process.

Verisign chooses not to do so, and thus frustrates the process.

Kind regards,

Job

---

From: Antoin Verschuren <[email-masked]>
Date: Wed, 9 Nov 2016 19:47:49 +0100

[Personal statement: Chair hat off]

Just so that everyone has the same information regarding the IPR we are discussing, the patent application and it’s EPO process can be found here:
https://register.epo.org/ipfwretrieve?apn=US.201113078643.A&lng=en

The patent application has been officially rejected by the patent office twice now in the past 5 years due to prior art.
This is without me as the original inventor of the secure dns-operator change method submitting any personal prior art that stems back to 2008 when I first thought of the idea during a DNSSEC workshop for operations staff while working for SIDN.
I have discussed this method in an IETF, DNS-OARC, CENTR and ICANN context with fellow IETFers including Verisign staff, and gave presentations about it, which led to the prior art before the first version of draft-koch-dnsop-dnssec-operator-change was published by the IETF in March 2011 and the Verisign patent application a month later.
This and the fact that I’m a co-author of both draft-ietf-eppext-keyrelay and draft-koch-dnsop-dnssec-operator-change is why my co-chair Jim is leading the process on draft-ietf-eppext-keyrelay and I attempt to state no personal opinions in this process or judgement of the opinions of others in this process.

[/Chair hat off]

Like most of you, I am no patent expert or lawyer.
Verisign is following the IETF IPR process as defined by the IETF, and it has every right to do so.
So please don’t blame Verisign or Scott personally.
The Patent office procedures are what they are, and we cannot change them or speed them up either.
Verisign can do the latter, but is not obliged to do so by any IETF rule, only by willingness.

That being said, we as a working group need to decide what we want to do.

I agree with Job that it is unfortunate that the IETF IPR process allows a pending patent application that has no licensing terms yet to stall the IETF process.
If this needs to change, I think we need to discuss this in a broader IETF context, but I think it will be very hard, if it is even possible legally to mandate licensing terms on IPR statements submitted to the IETF.

If we think Verisign has breached the IETF Note Well by patenting solutions after they were discussed during IETF meetings, that discussion also needs a broader IETF context than this working group. This will also mean a long legal battle which few individual IETF participants would be able to afford, and would require broader IETF consulting and guidance from the IESG.

So as a working group, we basically have only 2 options left:
1. We could kindly convince Verisign with arguments that stallment of this IPR claim is negatively impacting Internet security like Job has done, and ask them to withdraw or quickly proceed with their application. In this case, if Verisign is not willing to state licensing terms beforehand, we are still dependent on the Patent office procedures and timelines, and we will just have to wait for that.
2. We could jointly state that we took notice of the IPR claim, and that no matter what the licensing terms or outcome of the application is, we would like to standardize the solution in our Internet draft since it is the only best solution.

I would be hesitant to choose for option 2 on the argument that many believe the application will be rejected by the patent office in the end as there is sufficient prior art, since I am not a Lawyer, nor do I have the funds to pay for one in the small chance the patent office will make the wrong decision in approving the application to get it off their plate.
If we choose for option 2, we need to state why we think the patent application or it’s licensing terms don’t matter to us.

Jim has asked for this before, with little to no response to call consensus to have this draft proceed, so I would like to ask you again to state your opinion on this mailinglist so Jim can summarize them in a response to the IESG.

- --
Antoin Verschuren

Tweevoren 6, 5672 SB Nuenen, NL
M: +31 6 37682392

---

From: Rik Ribbers <[email-masked]>
Date: Thu, 10 Nov 2016 07:44:14 +0000

First of all thanks Antoin for your excellent reply.  lots of +1 in there.

On 9 Nov 2016, at 19:47, Antoin Verschuren <[email-masked]<mailto:[email-masked]>> wrote:

We all know what is going to happen now… we have been waiting for a response for almost a year now and nothing happens in the WG. So the document is not only stalled on a IPR-disclosure without licensing details but also on a WG that is not willing to discuss this.

So I propose an option 3: Describe the situation to the IESG and from this (https://mailarchive.ietf.org/arch/msg/regext/wHlAx8OrF_r5DiSWhr8LuMk860g_) mail conversation Stephen will (unhappy with the crappy situation) clears his DISCUSS. At least this gets the document of the plate from the WG and takes the discussion to the IESG where the document and the IPR disclosure can be discussed in a broader context then just keyrelay and the REGEXT WG.

Gr,
Rik

---

From: Marc Groeneweg <[email-masked]>
Date: Thu, 10 Nov 2016 08:01:42 +0000

+1 I agree. It seems there is a rough consensus formed by the overwhelming silence within this WG regarding this keyrelay draft. Let’s move on!

From: regext <[email-masked]> on behalf of Rik Ribbers <[email-masked]>
Date: Thursday, 10 November 2016 at 08:44
To: Antoin Verschuren <[email-masked]>
Cc: Job Snijders <[email-masked]>, "[email-masked]" <[email-masked]>, Scott Hollenbeck <[email-masked]>, "Livesay, Paul" <[email-masked]>, "[email-masked]" <[email-masked]>, Stephen Farrell <[email-masked]>
Subject: Re: [regext] draft-ietf-eppext-keyrelay unreasonably stuck on IPR?

Gr,
Rik

---

From: Job Snijders <[email-masked]>
Date: Thu, 10 Nov 2016 11:33:04 +0100

Dear Working Group,

TL;DR: the working group should move forward and disregard Verisign's IPR claim.

On Wed, Nov 09, 2016 at 07:47:49PM +0100, Antoin Verschuren wrote:
> Just so that everyone has the same information regarding the IPR we
> are discussing, the patent application and it’s EPO process can be
> found here: https://register.epo.org/ipfwretrieve?apn=US.201113078643.A&lng=en
> 
> The patent application has been officially rejected by the patent
> office twice now in the past 5 years due to prior art.
> [ snip ]
> 
> 1. We could kindly convince Verisign with arguments that stallment of
> this IPR claim is negatively impacting Internet security like Job has
> done, and ask them to withdraw or quickly proceed with their
> application. (snip)
>
> 2. We could jointly state that we took notice of the IPR claim, and
> that no matter what the licensing terms or outcome of the application
> is, we would like to standardize the solution in our Internet draft
> since it is the only best solution.
> 
> If we choose for option 2, we need to state why we think the patent
> application or it’s licensing terms don’t matter to us.

Given that Verisign demonstrated an unwillingness to amend their License
Declaration, I'd like to support option 2.

I have a few supporting notes to share regarding option 2:

    1) Any draft or any mechanism that defines howto securely
transfer a domainname without breaking the DNSSEC chain of trust, will
inevitably be contaminated by Verisigns IPR disclosure for WO2012135492:
be it EPP, RDAP, koch-dnsop-dnssec-operator-change, Fax or anything we
can come up with. Enough is enough. We need this tool and variants of
this tool. One US company should not be handed the power to obstruct at
the expense of the global community. Tossing 'keyrelay' in the bin and
starting over won't prevent Verisign from doing the exact same thing, so
we might as well move this one forward.

    2) Verisign's motivation for their unforthcoming attitude is
irrelevant. Whether Verisign believe they can employ patent applications
as a strategic device to delay drafts or whether it is mere organisational
incompetence doesn't matter, the outcome is the same. Antoin is right
that this anti-social behaviour needs to be addressed in a broader
context, 'keyrelay' delay will serve as an excellent example of
collateral damage due to poorly choosen IPR License Declarations.

    3) Verisign's patent application and licensing terms for the rights
they might be able to claim (if any), are likely to be confined to a
narrow geographic, while on the other hand, the IETF standards serve a
global audience. An RFC that is contested in one region can still be
perfectly fine and usable in another region.

    4) The legal ramifications and lawsuits will be handled outside of
IETF anyway. Given point (1), the working group cannot improve upon the
presented work in any meaningful way, which means that we'll have to
accept the IPR claim as it is and deal with the fallout through normal
pathways. From the looks of it, the USPTO, EPO and possible other venues
will be working on this item for the years to come, regardless of what
choice the IETF makes in this context.

    5) Based on Antoin's write-up, I have good reason to believe prior
art exists and the patent application will be shredded after careful
scrutinization, just as EPO demonstrated by rejecting the patent twice
already.

In addition to the above, I encourage people to discuss and reevaluate
their collaborations with Verisign at a later date.

Kind regards,

Job

---

From: Miek Gieben <[email-masked]>
Date: Thu, 10 Nov 2016 10:37:46 +0000

[ Quoting <[email-masked]> in "Re: [regext] draft-ietf-eppext-keyr..." ]
>TL;DR: the working group should move forward and disregard Verisign's IPR claim.

+1 from me on this.

---

From: Rik Ribbers <[email-masked]>
Date: Thu, 10 Nov 2016 10:38:50 +0000

+1

I encourage every member of this working group to state their opinion.

On 10 Nov 2016, at 11:33, Job Snijders <[email-masked]<mailto:[email-masked]>> wrote:

---

From: Alexey Melnikov <[email-masked]>
Date: Thu, 10 Nov 2016 10:42:37 +0000

Hi,

On Thu, Nov 10, 2016, at 07:44 AM, Rik Ribbers wrote:
>> On 9 Nov 2016, at 19:47, Antoin Verschuren <[email-masked]> wrote:
>>
>> Jim has asked for this before, with little to no response to call
>> consensus to have this draft proceed, so I would like to ask you
>> again to state your opinion on this mailinglist so Jim can summarize
>> them in a response to the IESG.
> We all know what is going to happen now… we have been waiting for a
> response for almost a year now and nothing happens in the WG. So the
> document is not only stalled on a IPR-disclosure without licensing
> details but also on a WG that is not willing to discuss this.
>
> So I propose an option 3: Describe the situation to the IESG and from
> this
> (https://mailarchive.ietf.org/arch/msg/regext/wHlAx8OrF_r5DiSWhr8LuMk860g_)
> mail conversation Stephen will (unhappy with the crappy situation)
> clears his DISCUSS. At least this gets the document of the plate from
> the WG and takes the discussion to the IESG where the document and the
> IPR disclosure can be discussed in a broader context then just
> keyrelay and the REGEXT WG.

The main problem with this option is that IESG still needs feedback from
the WG about what outcome the WG prefers. IESG is unlikely to make a
decision to "just publish" on its own.

Alexey (not speaking for the whole IESG, but just my gut feeling).

---

From: Marc Groeneweg <[email-masked]>
Date: Thu, 10 Nov 2016 10:43:40 +0000

+1 Please move forward.

From: regext <[email-masked]> on behalf of Rik Ribbers <[email-masked]>
Date: Thursday, 10 November 2016 at 11:38
To: Job Snijders <[email-masked]>
Cc: "Livesay, Paul" <[email-masked]>, Antoin Verschuren <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, Stephen Farrell <[email-masked]>
Subject: Re: [regext] draft-ietf-eppext-keyrelay unreasonably stuck on IPR?

+1

---

From: "Marco Davids (IETF IMAP)" <[email-masked]>
Date: Thu, 10 Nov 2016 13:23:36 +0100

On 10/11/2016 11:33, Job Snijders wrote:

> Given that Verisign demonstrated an unwillingness to amend their
> License Declaration, I'd like to support option 2.

+1

--
Marco

---

From: bert hubert <[email-masked]>
Date: Thu, 10 Nov 2016 22:44:26 +0100

> I have a few supporting notes to share regarding option 2:

So do I, but I'd like to add a few things.

> inevitably be contaminated by Verisigns IPR disclosure for WO2012135492:

+1 - this point effectively means that there is no alternative to going
ahead.

> collateral damage due to poorly choosen IPR License Declarations.

I agree change is needed, but we need this standard. If in fact you want to
make the best show of how bad things are, we should not proceed and drop the
standardisation and wail loudly.

> perfectly fine and usable in another region.

I'd put this differently. While the US may not be able to benefit from this
standard, at least let pure non-American entities enjoy it. In practice this
'narrow demographic' impacts most of the domain industry: anyone with a US
entitity - because that is the (practical) reach of IPR lawsuits.

But let's indeed do this for the rest of the world.

> scrutinization, just as EPO demonstrated by rejecting the patent twice

+1 - this is a followup really to '3'. We might be doing the standard for a
post-invalidated USA, plus the rest of the world.

> their collaborations with Verisign at a later date.

I think we treat them way too kindly. They receive hundreds of millions for
maintaining COM and NET. 

	Bert

---

From: Jaap Akkerhuis <[email-masked]>
Date: Mon, 28 Nov 2016 16:21:43 +0100

> >TL;DR: the working group should move forward and disregard Verisign's IPR claim.

Given all the argments I've seen on this list, going ahead seems to be
the only way out of this stalemate.

	jaap

---

From: Ulrich Wisser <[email-masked]>
Date: Mon, 28 Nov 2016 20:16:35 +0000

I believe the majority in the room in Seoul preferred to go forward.
(I certainly indicated my support of moving forward.)
Our area director seemed to have the same impression.
So if there isn't an outcry on the list, that's what we're doing, right?

/Ulrich

Jaap Akkerhuis <[email-masked]> schrieb am Mo., 28. Nov. 2016 um
16:21 Uhr:

> _______________________________________________
> regext mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/regext
>
-- 
Ulrich Wisser
[email-masked]