e truly correct one.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
/arch/browse/dnsop/?gbt=1&index=XYijqc1aIwHn_pOLZu0RusE9y0U
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
s for deciding what
reference to use.
So, for example, why is this latest reference correct this time, when it
was judged incorrect, the last time is was used for the entry?
That makes it impossible to know whether this latest change really is
correct. This time.
d/
--
Dave Crocker
Brande
On 8/8/2022 3:57 PM, John R. Levine wrote:
I don't recall that anyone judged it incorrect. I think we just made
a clerical error.
absent a recollection -- or documentation -- the proffered assessment
lacks a basis.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbi
RFC numbers listed.
Absent a clear understanding of why this 'new' one was deemed wrong
then, but correct now, making the change now is rather whimsical.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
___
DNSOP mailing list
DNSOP
thor of a relevant document
participate, the IETF specification process is not supposed to be so
fragile that it is required.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
impact to the IANA
registry:https://www.iana.org/assignments/dns-parameters/dns-parameters.xhtml#underscored-globally-scoped-dns-node-names
_iax does not appear in RFC6118, while RFC6315 defines it. So this
seems to be correctly identifying an error in RFC8552.
d/
--
Dave Crocker
Brandenburg
useful reference(s). Not sure this line needs to be removed.
Note that this also has an impact to the IANA registry:
https://www.iana.org/assignments/dns-parameters/dns-parameters.xhtml#underscored-globally-scoped-dns-node-names
---
My proposed resolution: Same as above.
I think that these
planation. I think it is
also correct.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
mast:@dcrocker@mastodon.social
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
On 1/22/2024 6:44 PM, Amanda Baber via RT wrote:
I'm just writing to note that we put this fix in place last week, after a note
from Warren:
https://www.iana.org/assignments/dns-parameters
dandy. thanks!
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
mast:@dcrocker@mastodon.s
On 12/3/2021 12:35 AM, RFC Errata System wrote:
This erratum is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected.
Verified. It is, indeed, a typo.
It should be Service4 and not Service 4.
On 12/6/2021 12:46 AM, RFC Errata System wrote:
This erratum is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected.
verified.
d/
--
Dave Crocker
Brandenburg Inte
On 12/7/2021 12:41 AM, RFC Errata System wrote:
This erratum is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected.
Verified.
d/
--
Dave Crocker
Brandenburg Inte
scope) underscore names.
2. Create a separate document that specifies modifications to the
SRV and URI documents, rationalizing the use of underscore names,
through the mechanism defined in -attrleaf-.
Thoughts?
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
___
emantic with another.
So I'll take the liberty of rephrasing what you describe as:
Obsolete the existing inheritance registrations and create
explicit registrations for the currently-inherited names in use.
d/
--
Dave Crocker
Brandenburg
c.org/DNSSEC_History_Project
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
Htmlized: https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-attrleaf
Diff: https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-attrleaf-03
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
On 3/20/2018 12:41 AM, tjw ietf wrote:
However, we need to go find those App Area folks (hence cc'ing Murray here)
and run this past them.
tim, good idea. query has been sent to the art mailing list.
('app' area, per se, was retired, and folded with rai.)
d/
--
Dave Croc
ps. I thought the URI RR had no current actual use (or at least very
little.)
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
r we deal
with its naming rules.
Or, here too, we change the URI spec.
d/
--
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
, which
pertains to ensuring that new behaviors use the new model.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
'existing practice'.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
isting specs that use _underscore naming
will know that their document needs to use the new registry
it would be helpful.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
On 3/21/2018 11:17 AM, Dave Crocker wrote:
Much of the discussion of the current topic -- previously and now -- has
tended to stray from the pragmatics, whereas that is the only thinking
driving my concerns and suggestions. In particular, some people seem to
have a mystical -- or equally
On 3/21/2018 12:08 PM, Alexey Melnikov wrote:
Possibly related to this question: what is the relationship of this draft to
RFC 6335?
Can separate registries be 'related'? Anyhow, I think these aren't.
Perhaps you could ask a more detailed question?
d/
--
Dave Croc
me text specific to the DKIM document's domain naming scheme,
to indicate how future second-level names should be assigned. Since
ADSP is historic, specifying modification to it doesn't make sense to
modify it.
Thoughts?
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.ne
requirement out?
I'm a minimalist in terms of the role of a registry. To the extent
possible, I think that it only has to do registration with
accountability. There are cases where more stringent requirements make
sense, but I don't see this as one of them: there not any danger I can
ere for most of the entries was
mechanically redundant with information in other fields for the entry.
Control: I've added overall text in a bulleted list before the
table, that handles the 'authority' issue for each entry.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbi
ea what you are referring to. Better still, my guess is that you are
reacting to one or more messages from me before the one I sent that said
'Level set'.
Take a look, at the latest draft. If you have concerns with it, please
point to specific text in it.
d/
--
Dave Crocker
Br
h the proposed global registry (for now.)
Yes?
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
Please cite the specific text in that RFC you are referencing.
and, if there were a prohibition, RFC 6055 would have been
largely unnecessary.
Overall, it appears that your claim is that the underscore naming
convention is predicated on an erroneous interpretation of 'hostname'
res
.
Thanks!
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
akes its use
reserved.
All of this has to do with name /assignment/, but makes no changes on
name /resolution/. Name resolution remains blissfully unaware of any
rules about name assignment or 'meaning'.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
_
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.
Added TLSA to the next version of the draft.
d/
--
Dave Crocker
Brandenburg
On 3/28/2018 5:49 AM, Martin Hoffmann wrote:
draft-ietf-acme-acme defines _acme-challenge for TXT records.
Thanks. Added to the next version.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
___
DNSOP mailing list
DNSOP@ietf.org
https
that one.
Thoughts?
d/
ps. Another round of hearty thanks to Ray Bellis for his offlist
interactions with me on this, though of course he gets none of the blame
for my getting any of this wrong...
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
stinct,
subordinate name space./
An RR type owns a name space? I don't understand what that means or how
it is correct.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
name space tree names a set of information, and
query operations are attempts to extract specific types of
information from a particular set.
which is not language that lends itself towards saying that an RR type
has its own namespace. I don't se
sure don't seem to work in practice.
The current version is:
https://datatracker.ietf.org/doc/draft-ietf-dnsop-attrleaf/
Please suggest specific text to use and where to put it.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
___
confusion around what other DNS RFC's call a "namespace".
Oh. Alas, I'm still not seeing how this is helpful pedagogy for the
average reader. Let's suspend this until the next version and see how
the doc sits with folks.
d/
--
Dave Crocker
Brandenburg Internet
re of the query. It is an artifact of the DNS name."
from it, to the Intro will help a bit.
2. I think the latest round of discussion and change arguably implements
your view, albeit within a single actual registry.
d/
--
Dave Crocker
Brandenburg Inte
URI
_tcp
URI
_udp
But this ignores handling names from enumservice.
Thoughts? Suggestion? Text?
d/
--
Dave Crocker
Brandenburg InternetWorking
bbi
On 3/31/2018 9:08 AM, John R. Levine wrote:
On Fri, 30 Mar 2018, Dave Crocker wrote:
but I can't figure exactly how, nor how to resolve drawing the global
value from two independent namespaces...
But this ignores handling names from enumservice.
Thoughts? Suggestion? Text?
Ad
topic.
Thanks.
d/
Forwarded Message
A new version of I-D, draft-ietf-dnsop-attrleaf-fix-00.txt
has been successfully submitted by Dave Crocker and posted to the
IETF repository.
Name: draft-ietf-dnsop-attrleaf-fix
Revision: 00
Title: DNS Attrleaf Changes:
ent to make me think it will have a number by
then. As such, it merely needs to get added to the 'updates' set.
And as such, it means that you responded to the third question.
So yeah, try harder.
Oh, and thanks for the quick attention!
d/
--
Dave Crocker
Brandenburg InternetWo
24 type names. It happens that none of them collide with other top
level names but since they only apply to URI it wouldn't matter if
they did.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
ional entries
when they will get used.
This is what we've done for Proto, so why not the same approach for
enumservice?
I suppose that's OK. Do we have any idea of what the handful of URIs in
the wild actually use?
I don't.
Does anybody in the working group know the details o
Ready for Last Call?
d/
Forwarded Message
Subject: New Version Notification for draft-ietf-dnsop-attrleaf-08.txt
Date: Tue, 22 May 2018 10:12:06 -0700
From: internet-dra...@ietf.org
To: Dave Crocker
A new version of I-D, draft-ietf-dnsop-attrleaf-08.txt
has been
on-line Internet-Drafts
directories.
This draft is a work item of the Domain Name System Operations WG of the
IETF.
Title : DNS Attrleaf Changes: Fixing Specifications
with _Underscored Node Name Use
Author : Dave Crocker
Filename: draft-ietf
Sorry. Meant to include the links from the announcement, especially for
diffs.
d/
Forwarded Message
Subject: New Version Notification for draft-ietf-dnsop-attrleaf-fix-01.txt
Date: Tue, 22 May 2018 10:14:34 -0700
From: internet-dra...@ietf.org
To: Dave Crocker
A new
e Attrleaf draft is drawn from the template used in the 'fix'
document.
d/
Forwarded Message
Subject: New Version Notification for draft-ietf-dnsop-attrleaf-09.txt
Date: Tue, 22 May 2018 12:05:11 -0700
From: internet-dra...@ietf.org
To: Dave Crocker
A new version of I
s for
naming that branch define the context for interpreting the RRset. That
is, rather than:
domain-name.example
/
RRset
the arrangement is:
_branch.domain-name.example
/
RRset
d/
--
Dave Crocker
Brandenburg
e to suggest text to add and its location in
-attrleaf, John?
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
On 6/25/2018 12:22 PM, John R Levine wrote:
I'm feeling lazy. Care to suggest text to add and its location in
-attrleaf, John?
See below.
thanks!
absent objections, I'll add it to the post-WGLC version.
d/
--
Dave Crocker
Brandenburg InternetWorkin
the body of the
document, solely to get rid of the 'unused' list during processing, but
decided that merely invites divergent copies...
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
___
DNSOP mailing list
DNSOP@ietf.org
htt
almost certainly not the term to apply here. While it
encompasses a sub-tree, its boundary is not explicit in a domain name.
The DNS is a hierarchy. I would have though 'top of a sub-branch' was
therefore clear, concise and accurate. Again, if there is other
phrasing that is more
On 7/6/2018 8:39 AM, Dave Crocker wrote:
Editorial: 'that is they are the "top" of a DNS branch, under a
"parent" domain name.' I assume that "top" is used instead of "apex"
because the sentence does not always refer to the top of a zone?
&#x
On 7/6/2018 9:35 AM, John Levine wrote:
Translator's note: change this to "left most" when translated
to Arabic or Hebrew.
in rtl contexts, domain names are shown with the root at the left???
d/
--
Dave Crocker
Brandenburg InternetW
ht-most) _underscored name MUST
be entered into this registry.
Does this cause anyone intolerable heart-burn? If it does, please at
least explain but preferably offer something better.
Thanks.
d/
--
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
bustness'.)
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
On 7/9/2018 2:35 PM, Dick Franks wrote:
On 9 July 2018 at 19:48, Dave Crocker <mailto:d...@dcrocker.net>> wrote:
>8
Does this cause anyone intolerable heart-burn? If it does, please
at least explain but preferably offer something better.
I do not suffer from intolerabl
On 6/28/2018 12:02 PM, Paul Hoffman wrote:
On 28 Jun 2018, at 7:19, Dave Crocker wrote:
On 6/27/2018 3:01 PM, Paul Hoffman wrote:
Due to its nature, the document is a bit difficult to read, but I
don't have any suggestion about how to make it better.
Could you at least provide
t' was needed as clarification.)
The -fix document doesn't stand alone, so it merely continues the
convention and does not re-explain it.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
re/most general"
Except that that has no obvious semantic merit, whereas 'highest' is
directly motivated by referring to position in a hierarchy.
otherwise: "closer/closest to the root"
Why?
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
redecessor drafts:
https://www.dropbox.com/sh/iex14dfnieq5dfq/AAAsedMLheGdBh6qbwm7tpcAa?dl=0
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
On 7/12/2018 8:29 PM, John Levine wrote:
The text in the new section on wildcards is
mildly fractured, looks like a cut and paste error.
I don't see it, unless you are referring to the removed underscore
characters, which was intentional.
d/
--
Dave Crocker
Brandenburg InternetWo
On 7/13/2018 9:16 AM, Tim Wicinski wrote:
which means either we're both correct or we're both incorrect.
for the latter possibility, not just both incorrect, but both incorrect
in the same way...
that's probably a variant of 'great minds think alike'...
d/
--
planatory -- rather than
specification/normative bit of text? Mumble.
If no one minds, I would rather make it Section 1.4, just after the
sub-section tht describes the construct. I think it actually works well
there.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
ost
cases, it represented conformance to form but had no substance. However
in the current case, I believe it exactly summarizes the issue for these
documents.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
On 7/18/2018 9:28 AM, Murray S. Kucherawy wrote:
On Wed, Jul 18, 2018 at 12:21 PM, Dave Crocker <mailto:d...@dcrocker.net>> wrote:
Folks,
I'm responding to Murray's impressive proofreading details offlist,
but there are some points he raises that might need
not 'wrong' to have the dot
there, given the nature of this registration activity and therefore the
context that the examples are going to get used in.
But certainly things need to be consistent and that one isn't.
Thanks for catching it, Bob.
d/
--
Dave Crocker
B
are quite
indirect. Could references to relevant IANA registries be added?
Since RFC 7553 is the place that says that the enumservice names turn
into _node names, I think that's the right reference.
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
___
have been citing.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
atching' but it's in
the specification document, not the operational code.)
Thoughts?
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
On 7/25/2018 10:59 AM, Bob Harold wrote:
Dot "." has special meaning in DNS, so I would prefer:
_ta-*
Not regex, but a common wildcard usage.
wfm.
anyone else care to chime in?
d/
--
Dave Crocker
Brandenburg InternetWorkin
On 7/25/2018 10:59 AM, Bob Harold wrote:
Dot "." has special meaning in DNS, so I would prefer:
_ta-*
Not regex, but a common wildcard usage.
wfm.
anyone else care to chime in?
d/
--
Dave Crocker
Brandenburg InternetWorkin
itted by Dave Crocker and posted to the
IETF repository.
Name: draft-ietf-dnsop-attrleaf
Revision: 13
Title: DNS Scoped Data Through "Underscore" Naming of Attribute Leaves
Document date: 2018-08-21
Group: dnsop
Pages: 12
URL: https://www.ie
On 8/21/2018 11:10 AM, Bob Harold wrote:
Minor typo:
"Specifiction" -> "Specification"
that might have been a freudian slip. that, and the spelling corrector
must not have looked into xml attributes. sigh.
thanks!
d/
--
Dave Crocker
Brandenburg I
On 8/21/2018 11:15 AM, John Levine wrote:
It looks fine except that section 6.1 on wildcards vs. underscores is
gone. Was that deliberate? I don't recall anyone complainging about
it.
Moved to Section 1.4.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbi
t apparently IDNits does not look there.
** Downref: Normative reference to an Informational RFC: RFC 7553
That document is a specification. This document modifies it. No matter
it's standards track status, it is a normative reference to this document.
-- Obsolete informatio
On 9/24/2018 6:16 AM, Dave Crocker wrote:
+ Those registered by IANA in the "Service Name and Transport
Protocol Port Number Registry [RFC6335]"
Move the end quote after Registry.
ok. Good catch.
Interesting. Just discovered that this probably qualifies as a b
Henrik,
Thanks for the quick followup...
On 9/26/2018 1:08 PM, Henrik Levkowetz wrote:
I think xml2rfc does the right thing. The quotes are provided by
you, the author, not the processor, and you've enclosed the element
completely in the quotes:
yeah, sorry. played with the combinatorials
nization effort: it's certain to fail at some point. So instead
we eliminated the requirement.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
about having to factor in the URI details
pretty much blew me by the fact of it's using /two/ tables and how it
used them.
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
them. But I'll clear my own discuss
now, as it seems that we've reached a difference of opinions regarding
harm rather than demonstrable harm.
Thanks!
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
___
DNSOP mailing list
r the
split)?
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
On 10/10/2018 8:43 AM, "Mirja Kühlewind (IETF)" wrote:
However re-consider the appropriate intended status for this doc!
I assume that is still something that the IESG resolves, independent of
whatever is on the draft.
d/
--
Dave Crocker
Brandenburg InternetWorkin
entry into the underscore table for each new name in
enumservice. Rather there is a need to make an entry in the underscore
table for every URI use of a new underscore entry.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
___
other enumservice-based URI entries in the current table refer to
RFC 6118
- RFC 7533 is mentioned elsewhere in the document as the reason
enumservices
appear in the table.
Hmmm. I like your last bullet, as a way of choosing between citing
definition of the RR vs definition of the
: Wed, 26 Sep 2018 13:29:07 -0700
From: Dave Crocker
To: draft-ietf-dnsop-attrleaf-...@ietf.org
G'day.
Just for completeness...
Absent direction to the contrary, I'm making no changes concerning the
following items (with the ones that have produced changes elided):
(BTW, I can'
"DNS nodes names" doesn't quite scan for me. "DNS node names"
perhaps?
Section 4.2: s/simply/simplify/?
Section 5: s/in the of/in the/?
done.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
___
DNSOP mailing list
ext to a commentary form:
Note that a public specification, which defines use of an RRset
and calls for the use of an underscore-prefixed domain name, its global
underscored name -- the one closest to the root -- is required to be
entered into this registry, if it is not already registered.
Alissa,
On 10/10/2018 2:48 PM, Alissa Cooper wrote:
On Oct 10, 2018, at 2:32 PM, Dave Crocker wrote:
On 10/10/2018 10:52 AM, Alissa Cooper wrote:
I think this document needs to state explicitly which updates apply to which
existing RFCs. That is, I would expect to see in sections 2.1, 2.2
so just for clarify, in the examples above, only _service[1-4] and
_authority would need to be registered?
Yes. (And I've added a sentence noting that point, for clarity. Thanks.)
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
--
Dave Crocker
Brande
and use barriers.
which is one heck of a lot of "resource record types" in the same, short
paragraph.
grrr...
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
if you insist...
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
ly no real risk incurred by this, noting that the
semantics of SHOULD translates into "you really must do this, unless you
are very knowledgeable and careful about why you aren't doing it right now.)
d/
--
Dave Crocker
Brandenburg Inte
Attrleaf Changes: Fixing Specifications with Underscored Node
Name Use
https://datatracker.ietf.org/doc/draft-ietf-dnsop-attrleaf-fix/
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
On 10/10/2018 10:50 PM, Adam Roach wrote:
Just to make sure you catch them in your audit, the following entries
are still missing from the table:
Thanks, Adam!
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
___
DNSOP mailing list
DNSOP
t the specification detail to be sure to satisfy it.
The issue was rendered moot by the removal of the normative language
from that draft.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
___
DNSOP mailing list
DNSOP@ietf.org
https://www.iet
1 - 100 of 164 matches
Mail list logo
