On Sun, Sep 17, 2023 at 7:53 AM Tim Wicinski wrote:
>
>
> On Sun, Sep 17, 2023 at 5:01 AM Joe Abley wrote:
>
>> Hi Murray!
>>
>> Op 17 sep. 2023 om 08:07 heeft Murray Kucherawy via Datatracker <
>> nore...@ietf.org> het volgende geschreven:
>>
>> > I thought the IESG (though maybe not this parti
On Tue, Feb 7, 2023 at 2:02 AM Willem Toorop wrote:
> Op 28-12-2022 om 23:29 schreef Murray Kucherawy via Datatracker:
> > (1) It's expected (required?), with no actions for IANA, to expressly
> include a
> > section that says so. It's conspicuously missing here.
>
> We've added the section.
>
On Wed, Jan 4, 2023 at 8:50 AM Peter Thomassen wrote:
> Hi Éric,
>
> Thank you for your review!
>
> On 1/2/23 14:59, Éric Vyncke via Datatracker wrote:
> > --
> > COMMENT:
> > -
Howdy,
On Thu, Aug 25, 2022 at 8:08 AM wrote:
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
> This draft is a work item of the Domain Name System Operations WG of the
> IETF.
>
> Title : DNS Glue Requirements in Referral Responses
>
On Mon, May 9, 2022 at 3:12 PM Ben Schwartz wrote:
> Yes, that's covered in the description:
>
> The designated expert MUST ensure that the Format Reference is stable and
> publicly available, and that it specifies how to convert the
> SvcParamValue's presentation format to wire format. The Forma
On Fri, May 6, 2022 at 12:09 PM wrote:
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
> This draft is a work item of the Domain Name System Operations WG of the
> IETF.
>
> Title : Service binding and parameter specification via
> the DNS (DN
On Tue, Mar 22, 2022 at 9:10 AM Ray Bellis wrote:
> I am concerned that the set of Expert Reviewers necessary to handle SVCB
> needs to have both expert DNS experience *and* detailed knowledge of the
> SVCB model for this to work.
>
> I am not sure there's anybody who fits that criteria.
>
Speci
On Tue, Mar 22, 2022 at 8:48 AM Martin Thomson wrote:
> On Wed, Mar 23, 2022, at 02:45, Murray S. Kucherawy wrote:
> > On Mon, Mar 21, 2022 at 2:20 AM Ben Schwartz
> > wrote:
> >> [...] any individual I-D is considered a qualified specification as
> soon as it is
On Mon, Mar 21, 2022 at 2:20 AM Ben Schwartz wrote:
> [...] any individual I-D is considered a qualified specification as
> soon as it is uploaded to the Datatracker.
>
Do you have a reference that asserts this? An I-D that isn't published
will expire, which would appear to contradict "permanen
On Sun, Oct 3, 2021 at 9:39 AM Paul Hoffman wrote:
> > In Security Considerations, it says:
> >
> > Security decisions about
> > which algorithms are safe and not safe should be made by reading the
> > security literature, not by looking in IANA registries.
> >
> > Should this document requ
The title page (top left) says this updates RFC 3658, and that RFC is
mentioned in the Introduction and listed in the References section, but
this document doesn't explain what in that document is being updated.
-MSK
On Wed, Aug 4, 2021 at 8:29 AM Tim Wicinski wrote:
>
> All
>
> This starts a W
On Tue, Apr 6, 2021 at 2:41 PM John Levine wrote:
> In this application, no, because it's not doing a strict tree walk:
>
> _dmarc.newjersey.sales.bigcorp.wtf
> _dmarc.sales.bigcorp.wtf
> _dmarc.bigcorp.wtf
>
> The _dmarc tag means that none of the names is an ancestor of any of
> the others. It
On Tue, Apr 6, 2021 at 12:56 PM Brian Dickson
wrote:
> I think this is another point in favor of doing QNAME minimization.
> RFC7816 (technically experimental, but recommended.)
>
> It kind of makes the query order moot; the resolver looks up the shorter
> name first even while resolving the long
On Tue, Apr 6, 2021 at 11:48 AM Shumon Huque wrote:
> Without DNSSEC, there is no current way to provide an indication about the
> longest ancestor of the name that did exist. With DNSSEC, the NSEC or NSEC3
> records in the response can do this (as well as providing cryptographic
> proof of this
I'm wondering something about tree walks, which John Levine asked about in
November, as it's a topic of interest to the evolution of DMARC.
I've read RFC 8020 which says an NXDOMAIN cached for "foo.example" also
covers later queries for "bar.foo.example". Makes sense.
Can this be used (or maybe
On Sat, Sep 12, 2020 at 3:09 PM Elwyn Davies via Datatracker <
nore...@ietf.org> wrote:
> Reviewer: Elwyn Davies
> Review result: Ready with Nits
>
> I am the assigned Gen-ART reviewer for this draft. The General Area
> Review Team (Gen-ART) reviews all IETF documents being processed
> by the IESG
On Wed, Jul 18, 2018 at 12:50 PM, Dave Crocker wrote:
>
>
>> I imagine myself as a SECDIR reviewer, and believe this would be the
>> first section I would read for any document to which I'm assigned.
>> Discovering there a sentence that basically says "None" would get my back
>> up ("We'll see ab
On Wed, Jul 18, 2018 at 12:33 PM, Dave Crocker wrote:
> On 7/18/2018 8:37 AM, Murray S. Kucherawy wrote:
>
>> Section 3.2 replaces text in Section 4.1 of something, but I don't know
>> what; the prior paragraph refers to multiple other documents. I suggest:
>> (a)
On Wed, Jul 18, 2018 at 12:21 PM, Dave Crocker wrote:
> Folks,
>
> I'm responding to Murray's impressive proofreading details offlist, but
> there are some points he raises that might need wg discussion:
Aw shucks.
> COMMENT:
>>
>> The text specifically calls for a stable reference. Do we hav
I've reviewed this document and it also looks like it's pretty much ready.
My suggestions here are also pretty minor:
As the other document, this one uses MUST without the RFC2119 boilerplate.
Section 3.2 replaces text in Section 4.1 of something, but I don't know
what; the prior paragraph refers
I've reviewed this document and I think it's in pretty good shape, and is
just about ready to be sent up for publication. I have some editorial
comments that are mostly minor in nature, as follows:
Section 1.1:
OLD:
The scoping feature is particularly useful when generalized resource
reco
On Sat, Nov 14, 2015 at 8:14 PM, John Levine wrote:
> >I would sign up as chair if there is enough interest to resurrect this.
>
> I brought it up, I'm willing to work on it.
>
Likewise. Also willing to help DISPATCH it via another route if DNSOP
doesn't take it up. :-)
-MSK
_
Colleagues,
Below is a proposed charter for a working group we're calling DBOUND, which
is seeking to solve the problem of finding a way to identify
administrative/organizational boundaries in the domain namespace. We'd
like to get some feedback from outside the team of people that's been
working
On Thu, Jul 17, 2014 at 10:39 AM, John C Klensin wrote:
> (d) It seems to me that the cases this proposal addresses are
> special enough that a dedicated Extended Status Code would be in
> order. Instead, the document specifies the highly generic 5.1.2
> (even those the RFC 3463 definition of X.
> -Original Message-
> From: dnsop-boun...@ietf.org [mailto:dnsop-boun...@ietf.org] On Behalf Of
> Warren Kumari
> Sent: Monday, April 16, 2012 11:55 PM
> To: Livingood, Jason
> Cc: Joe Abley; Nick Weaver; Tony Finch; dnsop; Paul Vixie; Evan Hunt
> Subject: Re: [DNSOP] on "Negative Trust A
25 matches
Mail list logo
