[speaking as an individual]
On 10/6/18 00:30, Adam Roach wrote:
I strongly support enumerating the concerns raised in the HRPC review
as part of this document.
Since this came up during today's REGEXT meeting, I wanted to clarify
something.
I made the above quoted statement assuming that no
On 10/05/2018 04:18 PM, Eliot Lear wrote:
<>
> He gave *an* example.
There were several examples mentioned earlier, all of which turned out
not be planning to implement 3rd party verification.
> You implied then that it was the only use case.
No other has been mentioned to date. So am curious
Peter,
I agree that the sentence "The data verified by the VSP MUST be stored by the
VSP along with the generated verification code to address any compliance
issues." should be changed. The proposal that I posted
(https://mailarchive.ietf.org/arch/msg/regext/UWdcY2q-9JkSlASV0UJcUGPJJyQ) to
th
[as an individual]
On 10/5/18 8:17 AM, Thomas Corte wrote:
Generally, technical standards are IMHO not the appropriate place for
fighting political or societal issues.
At the IETF 98 plenary in Chicago, David Clark said something on the
topic of human rights that's really resonated with me e
On Fri, Oct 05, 2018 at 04:16:04PM +0200, Niels ten Oever wrote:
> The difference between NAT and 3rd party verification is that there was
> a significant demand for the former, and not for the latter.
It seems to me that the WG is a place where a bunch of people who work
on registries and registr
On Fri, Oct 05, 2018 at 09:59:43AM -0400, Andrew Sullivan wrote:
> and I'm all in favour of that. What you are arguing, however, is in
> line with the way the IETF ended up doing the BEHAVE WG: we wouldn't
this case is probably more related to the discussion around RFC 2804.
> I think it would
On 05.10.18 14:08, Niels ten Oever wrote:
> We might disagree here. If there is one place in which this extension
> might be useful, I am not sure whether standardization is appropriate
> because there is only one (potential) implementation.
Again, not required (albeit desirable). RFC 2026 st
On 05.10.18 14:05, Niels ten Oever wrote:
> On 10/05/2018 01:55 PM, Eliot Lear wrote:
>> I take no position on the HR issues of this draft. However:
>>
>>
>>> If there is only one instance in which this MAY be useful, perhaps there
>>> is no need for standardization of this extension?
>>>
>> Not
On 10/05/2018 03:59 PM, Andrew Sullivan wrote:
> On Fri, Oct 05, 2018 at 03:24:08PM +0200, Niels ten Oever wrote:
>> We cannot simply wish political implications of our work away.
>
> Right, but I don't believe the HRPC work has suggested that things
> that have HR implications should _not be done
On Fri, Oct 05, 2018 at 03:24:08PM +0200, Niels ten Oever wrote:
> We cannot simply wish political implications of our work away.
Right, but I don't believe the HRPC work has suggested that things
that have HR implications should _not be done_. They should be noted,
and I'm all in favour of that.
On 10/05/2018 03:17 PM, Thomas Corte wrote:
> Hello,
>
> On 10/5/18 15:01, Niels ten Oever wrote:
>
>> If this would be a standard in response to a demand, that would be fine.
>> But I am rather afraid this is a standard that will create policy and
>> practice. Namely the practice of 3rd party id
Hello,
On 10/5/18 15:01, Niels ten Oever wrote:
> If this would be a standard in response to a demand, that would be fine.
> But I am rather afraid this is a standard that will create policy and
> practice. Namely the practice of 3rd party identity verification
> providers. Since there is legisla
On 10/05/2018 02:48 PM, Andrew Sullivan wrote:
> On Fri, Oct 05, 2018 at 02:08:38PM +0200, Niels ten Oever wrote:
>
>> We might disagree here. If there is one place in which this extension
>> might be useful, I am not sure whether standardization is appropriate
>> because there is only one (pot
On Fri, Oct 05, 2018 at 02:08:38PM +0200, Niels ten Oever wrote:
> We might disagree here. If there is one place in which this extension
> might be useful, I am not sure whether standardization is appropriate
> because there is only one (potential) implementation. That leads me to
> the question:
On 10/05/2018 01:55 PM, Eliot Lear wrote:
> I take no position on the HR issues of this draft. However:
>
>
>> If there is only one instance in which this MAY be useful, perhaps there
>> is no need for standardization of this extension?
>>
>
> Not the way we do business. We ask this question o
I take no position on the HR issues of this draft. However:
> If there is only one instance in which this MAY be useful, perhaps there
> is no need for standardization of this extension?
>
Not the way we do business. We ask this question on the front end of
the process, not the back end. That
Re: tagging discussion
I don't see content tagging as only negative. I could imagine such a
facility being used positively such as tagging some content as "child
friendly".
Which is why my interest in the topic is more in mechanism than
policy.
One would still have to trust the source of the t
> Il 3 ottobre 2018 alle 18.01 Erwin Lansing ha scritto:
>
>
> > On 3 Oct 2018, at 17.39, Ulrich Wisser < ulr...@wisser.se> wrote:
> >
> >
> > Denmark has plans to only allow registrations with a Danish electronic id.
>
>
> I’m sorry to barge in and distract from the real discussion here,
>
> On 3 Oct 2018, at 17.39, Ulrich Wisser wrote:
>
> Denmark has plans to only allow registrations with a Danish electronic id.
I’m sorry to barge in and distract from the real discussion here, but I cannot
let such a blatant inaccuracy stand. There are no such plans, neither have
there ever b
Hi,
I completely agree with Gurshabad assessment. But as others already pointed
out, it is an intended consequence of the extension.
In the context of domain registration, privacy cannot be expected. So my
question is rather, does this extension make the situation worse?
As you were asking for ex
> Il 3 ottobre 2018 alle 15.42 Niels ten Oever <
> li...@digitaldissidents.org mailto:li...@digitaldissidents.org > ha scritto:
>
>
> On Wed, Oct 03, 2018 at 01:14:10PM +, Gould, James wrote:
>
> > >
> > >
> > > The draft is intended for interoperabili
21 matches
Mail list logo
