Greetings again. At yesterday's WG meeting, the chairs asked us to star the
process of making minor updates to RFC 8499. The following is a version that
basically matches RFC 8499, but indicates that it will obsolete 8499 when
published. We will publish a few versions with a small number of addi
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 Terminology
Authors : Paul Hoffman
Kazunori Fujiwara
File
Brian Dickson wrote:
>
> However, there's also another clever trick (for some value of $clever),
> which isn't iron-clad but could help:
>
> guidspace.arpa DNAME empty.as112.arpa
That's worse than leaving it unregistered :-) AS112 is OK for RFC 1918
reverse DNS because in that case the QNAMEs don
On Tue, Nov 17, 2020 at 1:46 PM Tony Finch wrote:
> Brian Dickson wrote:
>
> > One potential approach is to say (in the RFC) that one of the two-letter
> > reserved codes should avoid name collision by putting a
> collision-resistant
> > second-level label, below .zz and above the private use us
Brian Dickson wrote:
> One potential approach is to say (in the RFC) that one of the two-letter
> reserved codes should avoid name collision by putting a collision-resistant
> second-level label, below .zz and above the private use usage (and use that
> particular two-letter code in that manner e
Seems like a good idea to make this more consistent.
A correction for the first paragraph: change
DNSSEC is primarily described in [RFC4033], [RFC4034], and [RFC4035].
DNSSEC commonly uses two resource records beyond those defined in RFC
4034: DS [RFC3658] and NSEC3 [RFC5155].
to
DN
Hello.
I think the draft should also mention glue *addresses*, as that's
another closely related piece that often comes from the parent side (and
is also unavoidable to use in some situations). Even if that means not
really recommending anything about them, though I'd personally expect
these to b
Hello.
I didn't speak but I'd still like to indicate my support. Requiring
"Standards Action" just to allocate algorithm numbers seems quite an
overkill. I'd find it healthy to split that into an easier step, so
it's also clearly separable from endorsing or even requiring support for
those algor
