On 7/18/2018 9:28 AM, Murray S. Kucherawy wrote:
On Wed, Jul 18, 2018 at 12:21 PM, Dave Crocker <d...@dcrocker.net
<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 discussion:
Aw shucks.
COMMENT:
The text specifically calls for a stable reference. Do we have
guidance about what constitutes such a thing? I believe IANA has
its own guidelines to that end; are they available to the
Designated Expert?
I'm inclined to let IANA raise this if they see and issue and then
let them drive the resolution of this point.
Yeah, I don't have the right answer either, but I'm concerned that we're
asking the DE to make a decision with guidelines she doesn't have (or
worse, come up with some that are not consistent with what IANA usually
does).
Section 6:
COMMENT:
I have doubts that SECDIR would accept this one-sentence
comment. I suggest saying something more specific, like:
"This document establishes a registry, and encourages a slight
reorganization of attributes stored in the DNS. It establishes
no new security issues."
The first clause is redundant and makes sense to have here only
either if the readers of this section haven't read the rest of the
document, or if the clause is useful to what follows. I believe
neither applies here.
I imagine myself as a SECDIR reviewer, and believe this would be the
first section I would read for any document to which I'm assigned.
Discovering there a sentence that basically says "None" would get my
back up ("We'll see about that!").
More generally, I have had success with my proposed tactic in the past,
so I thought I'd suggest it here.
I've gotten decreasingly tolerant of using gambits in a specification
document, in order to maneuver through the process. I think the document
should say what it needs to to do its job and not have material that is
primarily for appeasement those in charge. Gambits add cruft, and often
mislead the reader into thinking there is substance when there isn't.
(I think I hit my limit when we appeased an AD for KIM and added the
requirement for the DKIM signature cover the From: field, thereby aiding
in community misunderstanding of what DKIM does.)
If the suggested change had any actual substance with respect to
security issues, that would be quite a different matter. But it doesn't.
Obviously if the wg would prefer different language, we'll use it...
I don't understand the 'encourages' statement but suspect I don't agree.
Reading the document, I got the impression that in your research you
discovered some underscore names that don't quite follow the proposed
placement. If my inference is wrong, then so is that clause.
sorry, but apparently something is getting in the way of my
understanding this issue. Now I'm confused about the 'placement'
reference.
Anyhow, the only problematic, existing specs, I think, are the SRV and
URI documents, because they create naming complexities that invite
problems. Especially the two-source approach that the URI spec has.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
