Hi!
Paul Hoffman wrote:
> Greetings. I posted the -01 about ten days ago, and have not heard
> anything since then. The chairs indicated that they wanted this
> fast-tracked, so I'll nudge here for more input, either on the WG
> mailing list on in the repo
> (https://github.com/paulehoffman/draft-
Paul Vixie wrote:
> On Thursday, 23 July 2020 18:34:07 UTC Evan Hunt wrote:
> >
> > I share the desire for perfection, but IMHO the transition from
> > "master" to "primary" and "slave" to "secondary" is far enough
> > under way and well enough understood at this point that I suspect
> > it woul
Olli Vanhoja wrote:
> On Wed, Jan 22, 2020 at 3:12 PM Martin Hoffmann
> wrote:
> > | Abstract:
> > |This memo describes a mechanism to publish information related to an
> > |entity identified through a domain name via the Domain Name System
> > |(DNS).
John Levine wrote:
> In article <20200122151155.65e52...@glaurung.nlnetlabs.nl> you write:
> >
> >for a project we’ve been working[0] we needed to discover the
> >location of documents describing certain entities. We decided to
> >pick domain names as the identifiers and then use the DNS for
> >pub
Dear DNSOP,
for a project we’ve been working[0] we needed to discover the location
of documents describing certain entities. We decided to pick domain
names as the identifiers and then use the DNS for publication of those
locations. It turned out there isn’t currently a mechanism to actually
do th
Paul Hoffman wrote:
> Do53 was invented as a way of saying "DNS format and transport as
> described in RFC 1034 and RFC 1035, with updates". If anyone has a
> better shorthand for that than "Do53", that's great. I believe a
> shorthand is needed, particularly for publications that are
> discussiong
Hi Stephen,
Stephen Morris wrote:
>
> Back in March, Martin Hoffman did a comprehensive review of the
> RFC2845bis draft and made a number of very good suggestions for
> improvements to its readability. I've edited the draft to take
> account of his comments, something that has had a significant
Paul Hoffman wrote:
> On May 13, 2019, at 11:06 AM, Ondřej Surý wrote:
> > I still would like to continue with this and I still think it’s a
> > no brainer
>
> It is far from a no-brainer. The implementation of this document will
> leave RFC-compliant systems in an unknown state.
>
> A far ea
Peter J. Philipp wrote:
>
> I'm in contact with the original RFC 2845 authors for clarifications
> on what is meant in section 4.4 for the meaning of "Prior MAC
> (running)". In the bis draft this is in section 6.4 and seems
> unchanged. I'm having a hard time understanding this as an
> implement
Paul Hoffman wrote:
> Greetings again. As y'all have seen over the past few weeks, the
> discussion of where DNS resolution should happen and over what
> transports has caused some people to use conflicting terms. As a
> possible solution to the terminology problems, I am proposing a few
> abbrevi
Hi,
the following is a review of draft-ieft-dnsop-rfc2845bis-03. As an
implementer, let me say how much I appreciate this being a full revision on
RFC 2845 instead of just an update for the issues discovered. I strongly
believe that keeping the full specification in a single place by writing
revis
Hi,
when looking over draft-ietf-dnsop-rfc2845bis I was hoping that it
would relax the mandatory requirement for HMAC-MD5, but no such luck.
Given that most protocols have either made MD5 optional or banned it
outright, some modern crypto libraries have decided to drop it from
their supported alg
Tony Finch wrote:
>
> Note that limiting the overall length of the name isn't enough,
> because a pointer can loop without making the name longer.
You are, of course, right.
Kind regards,
Martin
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.o
bert hubert wrote:
> On Wed, Oct 24, 2018 at 05:01:53AM -0400, Viktor Dukhovni wrote:
> > And yet, here and there I see mention of having to take care to
> > avoid "loops", but loops are impossible in a monotone strictly
> > decreasing sequence.
>
> Yes. This is one of the best ways of preventin
Paul Vixie wrote:
> Suzanne Woolf wrote:
> >
> > Here's the definition that the authors would like to add to the
> > document:
> >
> >
> > Class:
> > A class "identifies a protocol family or instance of a protocol"
> > (Quoted from [RFC1034], Section 3.6). "The DNS tags all data
> > wit
Hi,
should probably do this more systematically, but I just
stumbled over another underscore label in the ACME draft:
draft-ietf-acme-acme defines _acme-challenge for TXT records.
The draft seems to be in Last Call right now, so it might
be an RFC before the registry is established.
Kind regard
bert hubert wrote:
>
> I've been looking at the amount of DNS out there, and I think we can
> do several things with them. I've also concluded that the mediocrity
> of DNS implementations outside of the well-known ones can not be
> fully blamed on "stupid programmers". The fact that we've offered
Dave Crocker wrote:
>
> On 3/26/2018 8:18 AM, Martin Hoffmann wrote:
> > Which also reminds me: The DANE RRtypes, ie., TLSA, SMIMEA, and
> > OPENPGPKEY all use underscore labels and are currently missing
> > from the initial table in section 3.1.
>
>
> The
John C Klensin wrote:
>
> From that point of view, namespaces are actually
> per-RRTYPE and the right way to design this document would be as
> a registry of "_"-introduced keywords, with subregistries for
> each RRTYPE with which those keywords can be used. Given the
> way the DNS works, at least
Ondřej Surý wrote:
>
> this is a first attempt to start reducing the load on DNS
> Implementors and actually remove the stuff from DNS that’s
> not used and not needed anymore.
You might want to consider also updating RFC 3597, either to
specifically remove those record types from being “well-kno
Warren Kumari wrote:
>
> Yes, you are right -- for all places where there is 'A' it should be
> 'A or '; how do people feel about something along the lines of:
>
> "Throughout this document, we are using A to refer to an Address
> record (either 'A' or '') " -- having "A or " scatter
Stephane Bortzmeyer wrote:
> On Tue, Dec 19, 2017 at 03:56:22AM +0100,
> Martin Hoffmann wrote
> a message of 38 lines which said:
>
> > > The current definition is restrictive: it mentions only name
> > > servers.
> > >
> > > IMHO, "in-
Stephane Bortzmeyer wrote:
> On Thu, Nov 30, 2017 at 01:36:00PM +0100,
> Martin Hoffmann wrote
> a message of 297 lines which said:
>
> > GLOBAL DNS -- FORMAT OF NAMES
> >
> > | Names in the common display format are normally written such that
> > the |
Stephane Bortzmeyer wrote:
> On Mon, Dec 04, 2017 at 10:27:32AM -0800,
> Paul Hoffman wrote
> a message of 28 lines which said:
>
> > - In-bailiwick
> > - Out-of-bailiwick
>
> The current definition is restrictive: it mentions only name servers.
>
> IMHO, "in-bailiwick" could be said for a
Hi,
the following is a review of draft-ietf-dnsop-terminology-bis-08. It
represents a reading of the document front-to-back as a sort of
whirlwind introduction to the depths of DNS and assumes that such a
reading is intended and there is a narrative. Even if that wasn’t the
original intention, the
25 matches
Mail list logo
