Folks,
We have a new draft and we'd like to ask the WG to adopt it:
*
https://datatracker.ietf.org/doc/draft-moura-dnsop-authoritative-recommendations/
This is an informational draft that presents recommendations for
authoritative DNS operators, based on research works we have been
On Mon, Nov 19, 2018 at 07:15:34PM +0530, Mukund Sivaraman wrote:
> Hi Stephen, Francis
>
> On Mon, Nov 19, 2018 at 04:56:50AM -0800, internet-dra...@ietf.org wrote:
> >
> > A New Internet-Draft is available from the on-line Internet-Drafts
> > directories.
> > This draft is a work item of the
Petr Špaček writes:
> On 13. 11. 18 7:03, Paul Wouters wrote:
>> On Mon, 12 Nov 2018, Ladislav Lhotka wrote:
>>> we would like to ask the working group to adopt the following I-D as a
>>> WG item:
>>>
>>> https://tools.ietf.org/html/draft-lhotka-dnsop-iana-class-type-yang-00
>>
>> I'll leave
> On Nov 29, 2018, at 08:49, Ted Lemon wrote:
> but I'd definitely be happier if the use case were more constrained
How could the use case be more constrained without breaking functionality?
> and the implementation advice were clearer.
What is unclear ? Do you have suggested improvement
> On Nov 29, 2018, at 09:20, Mark Andrews wrote:
>
> You can also just publish DS records for both DNSKEY RRsets with the caveat
> that
> both RRsets have to have all algorithms as is published in the combined DS
> RRset.
True. But than you are publishing non-public internal network details
> On 29 Nov 2018, at 11:47 am, Paul Wouters wrote:
>
> On Nov 29, 2018, at 04:53, Warren Kumari wrote:
>
>>
>> helps mitigate this -- as Tero says above, the user would have to jump
>> through many stupid hoops in order to make themselves vulnerable.
>
> That’s what we came up with when
On 28/11/2018 14:45, Alexey Melnikov wrote:
> On Wed, Nov 28, 2018, at 1:38 PM, Sara Dickinson wrote:
>> Paul is correct in that the _intention_ of including these fields is
>> just to provide informational meta data about the capturing process. I
>> would suggest we change the first sentence of
A new Request for Comments is now available in online RFC libraries.
RFC 8501
Title: Reverse DNS in IPv6 for
Internet Service Providers
Author: L. Howard
Status: Informational
Stream: IETF
Date:
Hi -
Do you have any authoritative server operators that have signed on to these
recommendations other than the authors? if not, I’d suggest deferring this
as a WG document pending some buy in from a few ops that are using these
recommendations and can provide some real world context. E.g. how
Tony Finch writes:
> Joe Abley wrote:
> >
> > It seems to me that the intended use-case is access to corporate-like
> > network environments where intranet.corporate-like.com might exist on
> > the inside but not on the outside.
>
> More likely cases like corporate-like.local or
> From: Paul Hoffman
> Subject: Re: [DNSOP] [Ext] Alexey Melnikov's Discuss on
> draft-ietf-dnsop-dns-capture-format-08: (with DISCUSS and COMMENT)
> Date: 27 November 2018 at 14:59:51 GMT
> To: Alexey Melnikov
> Cc: dnsop , The IESG
>
> On Nov 27, 2018, at 3:05 AM, Alexey Melnikov wrote:
On Tue, 27 Nov 2018, Petr Špaček wrote:
MB 7 a mailbox domain name (EXPERIMENTAL) [RFC1035] MG
8 a mail group member (EXPERIMENTAL) [RFC1035] MR 9 a
mail rename domain name (EXPERIMENTAL) [RFC1035]
Is there any *technical* use for this field? Do we need it
On Wed, Nov 28, 2018, at 1:38 PM, Sara Dickinson wrote:
>
>> *From: *Paul Hoffman
>> *Subject: **Re: [DNSOP] [Ext] Alexey Melnikov's Discuss on
>> draft-ietf-dnsop-dns-capture-format-
>> 08: (with DISCUSS and COMMENT)*>> *Date: *27 November 2018 at 14:59:51 GMT
>> *To: *Alexey Melnikov
>> *Cc:
Hi,
Please find an updated version of the DNSSEC validator requirements document.
The document reflect discussions we had in the Montreal and Bangkok meeting.
In particular we describe the DNSSEC trust model. We suppose that is an
important piece DNSSEC resolver operators needs to understand.
moura> We have a new draft and we'd like to ask the WG to adopt it:
moura>
[[https://datatracker..ietf.org/doc/draft-moura-dnsop-authoritative-recommendations/]]
msj> Do you have any authoritative server operators that have signed on
msj> to these recommendations other than the
So, thank you everyone for commenting / the feedback...
I've been mulling this over, and, while I really don't like it, I think
that the:
"IKE clients willing to accept INTERNAL_DNSSEC_TA attributes MUST use
a whitelist of one or more domains that can be updated out of band.
IKE clients with an
Hey Giovane,
On 28 Nov 2018, at 04:55, Giovane Moura wrote:
> We have a new draft and we'd like to ask the WG to adopt it:
>
> https://datatracker.ietf.org/doc/draft-moura-dnsop-authoritative-recommendations/
>
> This is an informational draft that presents recommendations for
> authoritative
Hello Giovane,
On Wed, Nov 28, 2018 at 12:56 PM Giovane Moura wrote:
> This is an informational draft that presents recommendations for
> authoritative DNS operators, based on research works we have been
> conducting over the last few years.
Thank you for sharing this!
A few suggestions:
> 5.
In article
you write:
>-=-=-=-=-=-
>Do you have any authoritative server operators that have signed on to these
>recommendations other than the authors?
I run authoritative servers for about 500 small domains, but I suspect
I am not the operator you are looking for.
Perhaps a next step would
On Nov 29, 2018, at 04:53, Warren Kumari wrote:
>
>
> helps mitigate this -- as Tero says above, the user would have to jump
> through many stupid hoops in order to make themselves vulnerable.
That’s what we came up with when we talked to ekr.
> If think that if the text around "that can be
20 matches
Mail list logo
