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.social
xplanation. 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
ce(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, two, were cas
an 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
articipate, 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
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@ietf.org
https
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
bbiw.net
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
Brandenburg
/browse/dnsop/?gbt=1=XYijqc1aIwHn_pOLZu0RusE9y0U
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
one.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
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
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/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.
already been noted on the dbound discussion that the draft raises issues
that might be of concern to the dnsop community.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman
and edit the report, if necessary.
Verified.
Drat. Good catch. Sigh.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
On 11/4/2018 7:08 PM, Ray Bellis wrote:
On 05/11/2018 09:56, Dave Crocker wrote:
So I immediately went to add it and then realized that doing this
cleanly will take an entry for each RR...
Why not this?
++--++
| RR Type | _NODE NAME
sure we want to do that?
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
to
show his actual name. The xml2rfc text rendering engine produces this
silliness and I'm inclined to class it as a bug in the engine.
If there is an established practice for working around that bug, to
produce the proper characters in html and an 'acceptable' alternative in
text,
I have new drafts ready and will submit them on when the submission
block is lifted.
Copies including diffs are at:
https://www.dropbox.com/sh/cwtztpjzauri3i3/AABbexI4p6sC50z-DEVh1tx9a?dl=0
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
--
Dave Crocker
Brandenburg
, but typically for avoidance of doubt authors specify precisely which
updates apply to which documents. This will also clear up the unused references
that idnits is pointing out
2) On 10/10/2018 11:32 AM, Dave Crocker wrote:
What is the downside of using the existing text, as compared against
the effort
drafts quickly, so the IESG could have them. (I still have to do that
audit.)
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
agrees on.
My limitation is spending the significant on a task that appears to be
entirely unnecessary.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
irect link to diffs.
I sent a pointer to the base datatracker page for the document. To get
to the diffs, from such a page, click on the 'History" tab (next to
Email expansions.) Then click "Submit".
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
On 10/12/2018 9:16 AM, Bob Harold wrote:
The "Updates" lists should be sorted, so changing 3921 to 6121 means the
whole list gets rearranged.
And some people think OCD is a problem. They are s wrong...
In other words, thanks. Will do.
d/
--
Dave Crocker
Brandenburg Inter
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.ietf.org
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
es: 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
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 InternetW
you insist...
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
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
or 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
Brandenburg InternetWorkin
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
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. target="Attrleaf">
t;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
DNSOP@iet
, 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't find documentation
sed 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 name. Thanks!
d
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
___
DNSO
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
for the
split)?
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
. 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
DNSOP@ietf.org
https
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
ion 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
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 qualifie
f: 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 informational reference (is this intentional?): RFC 3921
(Obsoleted by RFC
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
bbiw.net
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
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.ietf.or
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
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
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
___
DNSOP mailin
g' 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
Brandenburg InternetWorkin
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 wg discuss
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
xt? 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
___
DNSOP mailing list
DNSOP@ietf
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/
--
Dave Crocker
Brandenburg
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 InternetWorking
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
ighest' 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
he -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
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 some
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
/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
T
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
___
DNSOP mailing list
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 InternetWorkin
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?
'zone' is alm
mpasses 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 established, we should use it. But I'm not used
to seeing 'apex', t
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
https://www.ietf.org/mailman
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 InternetWorking
bbiw.net
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
hat 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 InternetWorkin
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 <dcroc...@bbiw.net>
A new versio
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 <dc
the 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
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 <dcroc...@bbiw.net>
A new version of I-D, draft-ietf-dnsop-attrleaf-
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 of current URI RRset
usage?
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
___
DNSOP mailing
RI 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
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 InternetWorking
bbiw.net
__
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: Fixing Specifications with _Underscored
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?
Add URI
URI
_tcp
URI
_udp
But this ignores handling names from enumservice.
Thoughts? Suggestion? Text?
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
__
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 InternetWorkin
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 InternetWorking
bbiw.net
___
DNSOP mailing list
DNSOP
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
___
DNSOP
rations 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 see anything in RFC 1035 that works for
that view, either.
d/
--
Dav
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
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
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
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
___
DNSOP mailing list
DNS
.
Thanks!
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
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'
restrictions. As such, the entire act
, but not with 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
a 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
Brandenburg Inter
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
bbiw.net
___
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
see in a useless registration entry and the
,
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.net
___
DNSOP mailing list
DNSOP
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 Crocker
Brandenburg
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
ore 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
practice'.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
1 - 100 of 153 matches
Mail list logo
