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
ct 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
___
be clear, obviously I'll add whatever text the wg 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
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
, 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 e
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
s produce appropriate text in html, 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 a
ot so 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
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
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
sable, but it's
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://
On 11/13/2015 10:58 PM, Ray Bellis wrote:
> Dave Crocker previously did some work on an I-D for a (portless) service
> type registry - I recall he and I discussed it back at the Orlando IETF.
>
> It would be good to see that resurrected.
Done.
This will be the third or fourth
rly there's _report._dmarc which seems to be a one-off.
For got that. Thought it was indepedent. ADSP is now removed from the
draft.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
names, but the term "tar baby" isn't sufficient to impart
how intractable that became.
So in DNS terms, that's the 'highest' underscore name. Anything below
them is scoped to be invisible to the public concern.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.
On 12/11/2015 10:46 AM, Bob Harold wrote:
Looks useful. A few concerns:
_adsp. has trailing dot, none of the others do.
pgpkeys missing leading _
_im listed twice, but with different rfc's - should at least put the
entries next to each other
Bob, Good catches. Thanks! (Turns out that _pres
g _Service instances into this global _Underscore
registry than to create an SRV-specific _undrscore registry.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
e community view is that it would require an RFC or the like.
d/
--
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
s the only way to ensure that name collisions
are avoided.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
On 3/1/2016 8:46 AM, Ray Bellis wrote:
I'd suggest that perhaps the keywords from the protocol registry (or a
canonical representation thereof, for those that don't match LDH) should
actually be reserved ?
yeah, that makes sense.
d/
--
Dave Crocker
Brandenburg InternetWorkin
I'll forward John's note, to record it, and then finally send a
response to his note... sigh. /really/ sorry.
d/
Forwarded Message
Subject: Re: [apps-discuss] Draft of interest in DNSOP:
draft-ietf-dnsop-attrleaf
Date: Wed, 3 Aug 2016 15:20:04 -0700
From: Dave Cr
John's note...
Forwarded Message
Subject: Re: [apps-discuss] Draft of interest in DNSOP:
draft-ietf-dnsop-attrleaf
Date: 4 Aug 2016 01:58:40 -
From: John Levine
To: apps-disc...@ietf.org
CC: dcroc...@bbiw.net
As for the second-level underscore names, I propose that the
roto names, then the current draft need do no more than include a
reminder to consult that registry. Yes?
d/
ps. Hmmm. Isn't this draft supposed to be discussed in dnsop and not apps?
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
__
s -- collisions.
I see this as a fundamental problem with the URI spec, for the reason
cited. I also think the current spec should be careful not to promote
that problem.
Suggestions?
d/
--
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
_
Folks (including Patrik)...
Hi.
Checking on where group views are, now that some exchanges have happened
and time has passed...
On 8/3/2016 8:48 PM, Dave Crocker wrote:
And now, my response to John's note...
On 8/3/2016 6:58 PM, John Levine wrote:
The services, on the other hand,
le I consider the former to be a distraction.
Simply put, specifying a smal task that requires humans to perform
perfectly at random, very (very) infrequent times, is a plan designed to
fail.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
_
ne is that this goes beyond the normal working scope of
those folk and imposing this kind of requirement on them is therefore
unreasonable, absent someone (else) doing the work to bring the
requirement down to a level that /is/ reasonable to ask of them.
d/
--
Dave Crocker
Brande
sment of the real-world uptake of the
URI RR?
Really, the burden of trying to have on-going coordination for the URI
RR, between two different registries is worth finding a way to avoid.
The problem is that I am not sure what to suggest that will work for URI
usage.
Suggestions?
Suggesti
r a single
registry has duplicate entries.
The advocate gets to pursue the questions. Thank you for offering...
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
On 3/5/2017 4:46 PM, Dave Crocker wrote:
On reviewing the discussion history, I see some items for the list
that I believe weren't resolved...
For those more interested in linguistic issues, as well as protocol
details, there is a 'comment' in Introduction of the _Attrleaf draf
IETF eschew running code?
d/
--
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/12/2017 4:23 PM, Paul Wouters wrote:
I do not want to adopt it unmodified
as informational RFC for running existing code.
You do not want the IETF to document existing practice?
Really?
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
... /after/ documenting /existing/ practice.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
On 3/13/2017 8:07 AM, Paul Hoffman wrote:
On 13 Mar 2017, at 7:44, Dave Crocker wrote:
On 3/13/2017 4:11 AM, Paul Wouters wrote:
The draft breaks DNSSEC.
...
I have proposed a method that would not change the RPZ response for a
non-DNSSEC client, but would add data for DNSSEC capable clients
On 3/13/2017 7:58 AM, Paul Wouters wrote:
On Mar 13, 2017, at 15:44, Dave Crocker wrote:
On 3/13/2017 4:11 AM, Paul Wouters wrote:
The draft breaks DNSSEC.
...
I have proposed a method that would not change the RPZ response for a
non-DNSSEC client, but would add data for DNSSEC capable
ht by going through the working group process and developing
a working group consensus about the document seem pretty
limited in that context.
13 Mar 2017 09:12:08 -0700
https://www.ietf.org/mail-archive/web/dnsop/current/msg19545.html
d/
--
Dave Crocker
Brandenburg InternetWorking
bbi
latter usually second-hand.
Fear of the hypothetical is an excuse for paralysis. And it's always
applied inconsistently.
Also it's premise is that the actual content of the document doesn't
matter very much, since a it means that the presence of caveats will
have no effect.
d/
On 3/27/2017 2:11 PM, Ondřej Surý wrote:
The draft is missing TLSA records (RFC 6698).
Thanks!
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
this spec now needs to cover.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
complaints that would be needed to reverse this many years
and such widespread use of the convention.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
ng forward.
As John suggests, I think this is independent of the attrleaf task and
doesn't affect it.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
(and DS) ought to have done, as
described up-thread.
If there were an Information RFC providing such guidance, I could
imagine a helpful reference to it being provided in a document like
attrleaf...
d/
--
Dave Crocker
Brandenburg InternetWorking
bbi
to expert review?
That's the intent of the text: Reliable access to a specification
attached to the registration, but no requirement for much quality
control on the spec...
anyway 5226 obsoleted 2434 so I'd probably cite that.
ack. tnx.
d/
--
Dave Crocker
Brandenburg Inter
is likely to
ensue, or is at least a possibility. These might even be labeled
'downsides' or 'upsides' if the authors want to get frisky.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
P will create a special SPF record that customers
can include with their record, such as _spf.example.com.
So we have extensive, established practice, though one could wish for a
(much) better specification.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
Rob carefully qualified his directive, to be contingent upon the absence of wg
consensus to the contrary. This is a time-honored wg management method for
making progress.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
___
DNSOP m
ve nothing to do with the
particular topic -- and therefore no biases about it -- and I like seeing wg
chairs try to make progress, albeit in a well-documented manner, such as Rob
has done.
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
___
DNSOP mailing list
DNSOP@ietf.org
https://www1.ietf.org/mailman/listinfo/dnsop
I have nothing to do with the
particular topic -- and therefore no biases about it -- and I like seeing wg
chairs try to make progress, albeit in a well-documented manner, such as Rob
has done.
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
___
DNSOP mailing list
DNSOP@ietf.org
https://www1.ietf.org/mailman/listinfo/dnsop
when dealing with
"multipart" MIME messages (i.e. documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
Below is the data which will enable a MIME compliant mail reader
implementation t
Folks,
From what I've seen, there have not been any postings on this wg topic.
Nonetheless since we are in the midst of IETF week, I'd like to ask whether
anyone has interest in talking about this sometime during the week.
d/
Dave Crocker wrote:
> This is revised base
drove the current document's design was to reduce the number
of tables. However your concern that it causes two columns of the table to
interact is correct and I certainly agree that it has its downsides.
Do others have some thoughts on this?
d/
--
Dave Crocker
Brandenburg Inter
ome discussion about it.
Please see:
<http://www1.ietf.org/mail-archive/web/dnsop/current/msg05593.html>.
Andrew Sullivan commented, but no one else did.
I'll again ask for discussion about the proposal, to see if we can rework it
to an acceptable state.
Thanks.
d/
-
o whatever is being put forward has
failed to gain traction and failed to be worth worrying about.
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
template.html>
and send it to me.
Thanks.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
quired appears
to be an interesting challenge for the paper.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
Folks,
Resurrecting a DNSOP work item from a number of years ago, I have drafted a new
proposal for a registry to handle "underscore" domain names.
The current draft contains enough detail to make clear how things would work,
but the initial list of registrations is not complete and well migh
FYI.
Extensive enhancement to the registry table.
d/
Original Message
Subject: I-D Action:draft-crocker-dns-attrleaf-05.txt
Date: Tue, 12 Apr 2011 19:45:02 -0700
From: internet-dra...@ietf.org
Reply-To: internet-dra...@ietf.org
To: i-d-annou...@ietf.org
A New Internet-Draft
attrleaf-05.txt
Date: Wed, 13 Apr 2011 13:58:56 -0700
From: Dave CROCKER
Reply-To: dcroc...@bbiw.net
Organization: Brandenburg InternetWorking
To: dnsop@ietf.org
FYI.
Extensive enhancement to the registry table.
d/
Original Message
Subject: I-D Action:draft-crocker-dns-attrl
k.
I would like to receive an explicit decision from this working group about
whether it will take the task on or won't.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
with their usability.
And the draft offers no data that runs contrary to the IAB paper's
concerns or the other concerns that have been raised in various public
discussions.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
___
DNSOP mailing list
nents likely to have problems, and its emphasis
is with /reaching/ the TLD RRs, not with publishing them. In fact,
SWIW, the word 'publish' does not occur in their report.
Yet your draft solely focuses on publishing.
--
Dave Crocker
Brande
asual claim of "IETF consensus" is simply false.
Technical:
The use of underscore-based naming variations has provided an
easy, efficient and safe means of eliminating TXT usage ambiguity. By
way of examples, note the SRV record and DKIM, but there are others.
d/
--
Dave Croc
t true, as well as the claim of consensus about
not being able to do anything being wrong.
But even at the simple fact level, are you under the impression that SRV
uses TXT?
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
___
DNSOP mailing
ce is decidedly not
> available at this domain.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
not receive mail. Hence, at
submission time, the receiving server can reject such messages.
> (e) The issues identified above aside, the explanation in the
> second paragraph of Security COnsiderations (Section 5) is
> unsatisfying. If a domain is configured so that some sending
101 - 164 of 164 matches
Mail list logo
