All,
We are pleased to announce that the draft agenda for the IETF 120 DNSOP
WG sessions is now available. The sessions are scheduled as follows:
- Monday, July 22, 2024, from 15:30-17:00 PDT (22:30-00:00 UTC)
- Thursday, July 25, 2024, from 18:30-19:30 PDT (01:30-02:30 UTC, July
26, 2024)
On Thu, 11 Jul 2024, Tim Wicinski wrote:
The stanford.edu example is useful, only because they don't show up in
those alexa top-1000(000) lists.
Like I am sure many here have, I dumped the TXT records to the top 1000 and
while the majority use
the format "token=value", there are several that use
On Thu, Jul 11, 2024 at 3:36 PM John R Levine wrote:
> On Thu, 11 Jul 2024, Tim Wicinski wrote:
> >> A) Should verification records have a tag at the front of the data to
> >> identify the record type? There's plenty of prior art for this, e.g.,
> >> the 63 text records at stanford.edu. Or you mi
On Thu, 11 Jul 2024, Tim Wicinski wrote:
A) Should verification records have a tag at the front of the data to
identify the record type? There's plenty of prior art for this, e.g.,
the 63 text records at stanford.edu. Or you might say that a
sufficiently long random token in the interesting part
Duane
Thanks for these. I'm going to capture these for the authors (at least one
is currently on holiday).
On Tue, Jul 9, 2024 at 5:55 PM Wessels, Duane wrote:
> I read through draft-ietf-dnsop-domain-verification-techniques-05 and have
> a few minor comments / suggestions.
>
>
>
> > this may
One of the potential challenges for RFCs is references to works-in-progress or
other less-than-stable items (URIs).
Here is my thought: would updating those be something that could be handled by
errata rather than doing a -bis?
Brian
Sent from my iPhone
___
I'm going to try to answer a few of these John, as acting Document
Shepherd, herder of author kittens.
On Tue, Jul 9, 2024 at 5:23 PM John Levine wrote:
> It appears that Tim Wicinski said:
> >This is one of those DNSOP documents that may not be relevant to those who
> >implement DNS, or those
Reviewer: Barry Leiba
Review result: Ready
This has a significantly expanded scope from the -01 version that I reviewed a
while ago. I think it's solid, well written, and ready for last call.
___
DNSOP mailing list -- dnsop@ietf.org
To unsubscribe sen
Jim Reid writes:
> IMO documenting the trade-offs in response sizes could be a better
> option. ie if the response > X, it breaks foo; if it’s > Y it breaks
> bar.
I agree with the approach of limiting discussion of limits to
recommendations. I am not a fan of enforcing lower limits in the wire
> On 10. 7. 2024, at 15:36, Yorgos Thessalonikefs wrote:
>
> In general having limits in an RFC that people can point to goes a long way
> than developers trying to argue with users; for example on what a sensible
> length of a CNAME chain is.
I agree with this rationale, but I would rather f
On Thu, Jul 11, 2024 at 09:39:04AM +0200, Philip Homburg wrote:
> >Operations may be better served by a minimum expected level than a
> >maximum.
>
> This is a matter of wording.
>
> Yes, it is possible to specify a minimum level that is expected from, for
> example, a recursive resolver.
>
> Ho
>Operations may be better served by a minimum expected level than a
>maximum.
This is a matter of wording.
Yes, it is possible to specify a minimum level that is expected from, for
example, a recursive resolver.
However this is likely to become a maximum that a zone owner can rely on
to work on
Hi Philip
On Thu, Jul 11, 2024 at 08:50:57AM +0200, Philip Homburg wrote:
> > Even RFC 1034 says "Bound the amount of work", but explicitly
> > prescribed numbers in an RFC may end up being arbitrary.
> >
> > When there is a difference between something working well and not
> > working well, it m
On 7/10/24 20:08, Ben Schwartz wrote:
Why? Do we really care if a resolver limits the size of RRsets to 32 KB?
Yes. Unnecessary limits restrict our flexibility even if mainstream use cases
don’t exist today.
Absolutely agree.
Peter
___
DNSOP m
14 matches
Mail list logo
