Re: [DNSOP] Working Group Last Call for for draft-ietf-dnsop-rfc5011-security-considerations-12; was Publication has been requested for draft-ietf-dnsop-rfc5011-security-considerations-12

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