On 7/10/2018 12:34 PM, Paul Hoffman wrote:
On 10 Jul 2018, at 11:35, Michael StJohns wrote:
And as you may have guessed I object to the publication of this
document on the basis of quality for all the reasons previously
stated. This version of the document is actually in worse shape than
the one that failed last call back in October.
Documents go to WG Last Call to determine consensus and fix errors;
this document appears to have done both, so there was no failure.
I'm not sure if you're word parsing or what here, but the result of the
WGLC was that the document still needed work and that there was no
consensus. Generally referred to as "failing to pass the WGLC".
Generally, passing means nits to be fixed, with a general consensus to
publish. That didn't happen - the "pass", so the opposite of "pass" is
"fail".
If you're saying that the document has both fixed the issues and gained
consensus - well, that's what this call is for. My opinion is that the
document still needs work, others may not agree. As for consensus,
AFAICT, there has been no on-the-list call from consensus since the
previous WG meeting that noted meeting consensus - and as we all know -
meeting consensus isn't sufficient to determine consensus.
I strongly object to the publication of this document as a Standards
Track document. The appropriate status - if published - is
Informational with or without a BCP tag on it.
There is no such thing as a "BCP tag". An RFC that is a BCP is treated
as a standard. See Section 5 of RFC 2026.
Mostly fair point - but while treated as a standard, a BCP is not a
standard in the meaning of Standards Track. So Informational or BCP,
not Proposed Standard. And given 7893, I'd say Informational.
The document does not provide any implementable protocol, and by that
I mean that the only protocol elements in this document must be
executed by humans. There is no on-the-wire elements, nor any process
that can be implemented by a DNS resolver or server. This is solely
and only an operational practices document,
True.
and AFAICT, none of these have ever ended up as Standards Track.
Not true. Plenty of WGs, including this one, put operational documents
on standards track.
Here are the RFCs that come up with "Standard Track" and "dnsop" as the
search terms. Which one is an "operational document"? I didn't have
time to search through the other pile of 8K plus RFCs, but did check
dnsext and found a dearth of operational documents as standards there.
AFAICT, all of these propose modifications to resolver or server behavior.
Number
<https://www.rfc-editor.org/search/rfc_search_detail.php?sortkey=Number&sorting=DESC&page=25&wg_acronym=dnsop&pubstatus[]=Standards%20Track&std_trk=Proposed%20Standard&pub_date_type=any>
Files Title Authors Date
<https://www.rfc-editor.org/search/rfc_search_detail.php?sortkey=Date&sorting=DESC&page=25&wg_acronym=dnsop&pubstatus[]=Standards%20Track&std_trk=Proposed%20Standard&pub_date_type=any>
More Info Status
RFC 7344 <http://www.rfc-editor.org/info/rfc7344> ASCII
<http://www.rfc-editor.org/rfc/rfc7344.txt>, PDF
<http://www.rfc-editor.org/pdfrfc/rfc7344.txt.pdf> Automating DNSSEC
Delegation Trust Maintenance W. Kumari, O. Gudmundsson, G. Barwood
September 2014 Updated by RFC 8078
<http://www.rfc-editor.org/info/rfc8078> Proposed Standard (changed
from Informational March 2017 <https://www.rfc-editor.org/info/rfc8078>)
RFC 7477 <http://www.rfc-editor.org/info/rfc7477> ASCII
<http://www.rfc-editor.org/rfc/rfc7477.txt>, PDF
<http://www.rfc-editor.org/pdfrfc/rfc7477.txt.pdf> Child-to-Parent
Synchronization in DNS W. Hardaker March 2015 Errata
<http://www.rfc-editor.org/errata/rfc7477> Proposed Standard
RFC 7686 <http://www.rfc-editor.org/info/rfc7686> ASCII
<http://www.rfc-editor.org/rfc/rfc7686.txt>, PDF
<http://www.rfc-editor.org/pdfrfc/rfc7686.txt.pdf> The ".onion"
Special-Use Domain Name J. Appelbaum, A. Muffett October 2015
Proposed Standard
RFC 7766 <http://www.rfc-editor.org/info/rfc7766> ASCII
<http://www.rfc-editor.org/rfc/rfc7766.txt>, PDF
<http://www.rfc-editor.org/pdfrfc/rfc7766.txt.pdf> DNS Transport over
TCP - Implementation Requirements J. Dickinson, S. Dickinson, R.
Bellis, A. Mankin, D. Wessels March 2016 Obsoletes RFC 5966
<http://www.rfc-editor.org/info/rfc5966>, Updates RFC 1035
<http://www.rfc-editor.org/info/rfc1035>, RFC 1123
<http://www.rfc-editor.org/info/rfc1123> Proposed Standard
RFC 7828 <http://www.rfc-editor.org/info/rfc7828> ASCII
<http://www.rfc-editor.org/rfc/rfc7828.txt>, PDF
<http://www.rfc-editor.org/pdfrfc/rfc7828.txt.pdf> The
edns-tcp-keepalive EDNS0 Option P. Wouters, J. Abley, S. Dickinson,
R. Bellis April 2016 Proposed Standard
RFC 7873 <http://www.rfc-editor.org/info/rfc7873> ASCII
<http://www.rfc-editor.org/rfc/rfc7873.txt>, PDF
<http://www.rfc-editor.org/pdfrfc/rfc7873.txt.pdf> Domain Name System
(DNS) Cookies D. Eastlake 3rd, M. Andrews May 2016 Proposed Standard
RFC 8020 <http://www.rfc-editor.org/info/rfc8020> ASCII
<http://www.rfc-editor.org/rfc/rfc8020.txt>, PDF
<http://www.rfc-editor.org/pdfrfc/rfc8020.txt.pdf> NXDOMAIN: There
Really Is Nothing Underneath S. Bortzmeyer, S. Huque November 2016
Updates RFC 1034 <http://www.rfc-editor.org/info/rfc1034>, RFC 2308
<http://www.rfc-editor.org/info/rfc2308> Proposed Standard
RFC 8078 <http://www.rfc-editor.org/info/rfc8078> ASCII
<http://www.rfc-editor.org/rfc/rfc8078.txt>, PDF
<http://www.rfc-editor.org/pdfrfc/rfc8078.txt.pdf> Managing DS
Records from the Parent via CDS/CDNSKEY O. Gudmundsson, P. Wouters
March 2017 Errata <http://www.rfc-editor.org/errata/rfc8078>, Updates
RFC 7344 <http://www.rfc-editor.org/info/rfc7344> Proposed Standard
RFC 8145 <http://www.rfc-editor.org/info/rfc8145> ASCII
<http://www.rfc-editor.org/rfc/rfc8145.txt>, PDF
<http://www.rfc-editor.org/pdfrfc/rfc8145.txt.pdf> Signaling Trust
Anchor Knowledge in DNS Security Extensions (DNSSEC) D. Wessels, W.
Kumari, P. Hoffman April 2017 Proposed Standard
RFC 8198 <http://www.rfc-editor.org/info/rfc8198> ASCII
<http://www.rfc-editor.org/rfc/rfc8198.txt>, PDF
<http://www.rfc-editor.org/pdfrfc/rfc8198.txt.pdf> Aggressive Use of
DNSSEC-Validated Cache K. Fujiwara, A. Kato, W. Kumari July 2017
Updates RFC 4035 <http://www.rfc-editor.org/info/rfc4035> Proposed
Standard
Or to put it more bluntly - humans are not protocol elements that
can be standardized.
True, but not relevant to the issue at hand.
And that's where you're wrong.
DNS is problematic because there are some humans in the loop - basically
on the database management and publication side. This is never so
obvious as when thinking about RFC5011. In that case, it was possible
to specify the behavior for the resolver based on the zone content, but
it was impossible to specify that a zone manager actually place the
content at a specific time and with a specific set of keys and
signatures. If you'll note, 5011 has normative (the resolver behavior)
and informative (suggested ways that a zone manager can publish data
that 5011 would find useful) sections for just this purpose.
In this case, this document is all about human behavior - NMI - no
machines involved. Protocol standards are about consistent, coherent
and repeatable behavior - terms rarely used with humans.
If this document had "here's the modifications to the protocol engine"
and "here's what people should do about it" you could publish this as a
standard, but the second section would be marked "Informative".
Finally, this purports to update RFC7538 which is Informational.
That's a good point. The WG draft that led to RFC 7538 was marked as
Informational for its entire lifetime, so the WG must have thought it
was OK to treat key rollover timing considerations as Informational.
*sigh* Sorry - RFC7583 - not 7538.
Mike
--Paul Hoffman
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
