Thanks Tim -
Note the changed subject line.
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.
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. 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, and AFAICT, none of these have ever ended up as
Standards Track. Or to put it more bluntly - humans are not protocol
elements that can be standardized. Finally, this purports to update
RFC7538 which is Informational.
Mike
On 7/10/2018 1:38 AM, Tim Wicinski wrote:
Michael
We talked it over and if there was a process fail, it's easier to fix
now then later. I already reached out to the AD who is stepping in for
Warren to hold off for now.
Let this be a Working Group Last Call on
draft-ietf-dnsop-rfc5011-security-considerations. This will go from
now until the end of the IETF next Friday.
The Current Intended Status is: Standards Track
We will be take comments on the changes now, and as well as during the
session on Wednesday.
Tim
On Mon, Jul 9, 2018 at 12:05 PM, Michael StJohns
<[email protected] <mailto:[email protected]>> wrote:
Tim/Suzanne -
Please cancel the request for publication until you complete the
WGLC for this document.
The last WGLC for the document was October of last year - it
failed on 28 October
https://www.ietf.org/mail-archive/web/dnsop/current/msg21225.html
<https://www.ietf.org/mail-archive/web/dnsop/current/msg21225.html>.
No WGLC has been made since then.
The consensus referenced in the shepherd's report was meeting
consensus - not mailing list consensus AFAICT. Specifically, I'd
like to see if Ed's removed his objections. I don't have a
problem with the WGLC being used to judge consensus - but that's
not what happened here.
Later, Mike
On 7/6/2018 9:08 PM, Michael StJohns wrote:
On 7/6/2018 8:13 PM, Tim Wicinski wrote:
Tim Wicinski has requested publication of
draft-ietf-dnsop-rfc5011-security-considerations-12 as
Proposed Standard on behalf of the DNSOP working group.
Please verify the document's state at
https://datatracker.ietf.org/doc/draft-ietf-dnsop-rfc5011-security-considerations/
<https://datatracker.ietf.org/doc/draft-ietf-dnsop-rfc5011-security-considerations/>
_______________________________________________
DNSOP mailing list
[email protected] <mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/dnsop
<https://www.ietf.org/mailman/listinfo/dnsop>
*sigh*
Point of order: Did I miss the final WGLC on this after this
last version was published? I can't actually find anything in
the DNSOP archives and I don't remember seeing the call. So
I'm suggesting that we've missed a required stage.
With respect to the shepher's writeup:
1) The first reference in the shepherd's write-up is wrong -
its pointing to a whole other set of discussions related to
Joe Abley's ideas.
2) The second reference isn't representative of the actual
discussion, but only shows the point at which I got worn down.
Please include a reference that actually shows the attempts to
try and resolve my issues.
3) This document should not be a Proposed Standard as it
documents nothing implementable (that is nothing implementable
in a computer), but is operational guidance for the
publication process.
4) Is it usual for the WG chair to write the shepherd's
report? Specifically, it seems a conflict of interest for
items (3) -(6).
5) The technical summary is misleading. This is not an update
to 5011, but guidance to the zone publisher who may have not
understood the implications of operational choices (e.g.
steady state single trust anchor vs 5011s recommendation of
multiple trust anchors). E.g. "RFC5011 DNSSEC Key Rollover
Strategy" isn't a document referenced by this document, and
that would be the document that would be in need of an update.
6) Same comment - it's not an update to the 5011 timers, but
to the understanding of the publishers of such zones that use
5011.
7) Please include references of the emails of the "root server
community" review - AFAICT, Ed Lewis was the only one to
comment on the list and the last comment was last year.
Mike
Mike
_______________________________________________
DNSOP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dnsop
