On Wed, Dec 21, 2016 at 10:05:03PM +0100,
Jaap Akkerhuis wrote
a message of 16 lines which said:
> As part of the IDNA discussion there is an RFC (or parts of it)
> pointing out how uesless classes are. I seem to remember it was
> from the IAB and one of the authors was Klensin.
I was not ab
Moin!
On 21 Dec 2016, at 15:36, william manning wrote:
> the complaints about operator participation in the IETF go back decades.
> no news there.
So you don't want operator participation in the IETF?
> in fact, there are operator driven fora for just such activities, DNS-OARC
> comes to mind.
D
Stephane Bortzmeyer writes:
> On Wed, Dec 21, 2016 at 10:05:03PM +0100, Jaap Akkerhuis
> wrote a message of 16 lines which said:
>
> > As part of the IDNA discussion there is an RFC (or parts of it) >
> pointing out how uesless classes are. I seem to remember it was >
> from the IAB and
On 2016-12-21 21:44, Nolan Berry wrote:
> Hello,
>
>
> I will keep my feedback short and to the point. We have implemented RPZ
> across our resolvers and it has been a fantastic tool to stop botnet
> C&Cs and outbound DDoS attacks. I just wanted to say it has been an
> extremely valuable tool
Stephane Bortzmeyer wrote:
>
> No, blocking a communication is harsh but is not a lie. Returning HTTP
> code 451 (RFC 7725) is not a lie, the HTTP server clearly says "this
> is censored".
>
> In the case of the DNS, in the absence of a rcode equivalent to 451,
> modifying the answers of the autho
>Even shorter, RPZ might be a good tool, but definitely not something
>that the IETF should promote in any way without a big enough warning
>sign that there are dragons lying around.
Assuming we published such a warning, can you tell us whose behavior
that warning might change, how the behavior wo
> From: Tony Finch
> Stephane Bortzmeyer wrote:
> >
> > No, blocking a communication is harsh but is not a lie. Returning HTTP
> > code 451 (RFC 7725) is not a lie, the HTTP server clearly says "this
> > is censored".
> >
> > In the case of the DNS, in the absence of a rcode equivalent to 451,
>
On Dec 22, 2016, at 10:32 AM, John Levine wrote:
> I have to say I'm baffled at arguments that boil down to "someone
> might do something bad with this, so we'll pretend it doesn't exist."
> By that standard, we wouldn't have published DNS, TCP, or IP.
Indeed, SMTP is frequently used by scam arti
On Thu, 22 Dec 2016, Vernon Schryver wrote:
SERVFAIL signaling DNSSEC validation failure is the equivalent to an
HTTP 4yz failure status. Neither is a full and open disclosure to end
users that censorship has occurred, because in both cases end users
only understand that the internet is broken.
>> Protocol signalling can help, but it is a relatively trivial matter
>> compared to how the blocking technology is explained to the people who are
>> affected by it.
>
>I don't agree. While my Aunt Mildred might understand the instructions
>of a walled garden the next time she infects her comput
Sorry for the delayed response. I've been unusually busy for these
several weeks...
At Sat, 3 Dec 2016 12:44:47 -0500,
Olafur Gudmundsson wrote:
> > I've read the 03 version of the document. I do *not* think this is
> > ready for publication since I still believe we should not abuse HINFO
> >
> From: Paul Wouters
> Some of us were not advocating for such text, although some text is surely
> appropriate for the Security Considerations or Privacy Considerations
> sections.
I don't understand. Do you think more text needed? If so, please
provide samples.
> Instead, I advoc
12 matches
Mail list logo
