Dear all, For what it's worth - all my concerns have been addressed. I believe the document to be in good shape now and would support a progression through WG LC. I appreciate the effort the authors have put into making this an exemplary specification!
Kind regards, Job On Mon, Jun 11, 2018 at 7:30 PM, Warren Kumari <war...@kumari.net> wrote: > Dear WG (and chairs), > > Firstly, thank you to everyone who supported this, those who provided > comments (especially pull requests!) and implementers. > > We have made a number of improvements to the documents based upon your > comments - the diff can be seen here: > https://www.ietf.org/rfcdiff?url1=draft-ietf-dnsop-kskroll-sentinel-10&url2=draft-ietf-dnsop-kskroll-sentinel-14 > > Possibly more helpful is the GitHub list of Pull Requests: > https://github.com/APNIC-Labs/draft-kskroll-sentinel/pulls?q=is%3Apr+is%3Aclosed > > We've added an implementation section - I know that there were more "client" > side (the Javascript or similar automated tests); I'd been keeping a note > with a list, but seem to have misplaced it. > > BIND and Unbound now support this; AFAIK, Knot supports the older name. > > > I *think* that we've managed to address the comments, but if we happened to > miss yours, please let us know. > > From my read of the WGs views, these, being *labels*, are not *Special Use > Domain Names*, and so don't need to be added to the SUDN registry. > > The authors would like to thank the WG again, and ask that WGLC be resumed. > > W > > > On Tue, Apr 24, 2018 at 9:02 AM Ondřej Surý <ond...@isc.org> wrote: >> >> And the MR was peer-review and merged into BIND master branch with intent >> to backport the feature into older release branches. >> >> I don’t think it’s a useful or helpful to change the rules for existing >> adopted work. We need to have a discussion on the mechanisms that would >> allow implementors to know when to start the implementation of existing >> draft. From implementors point, it makes little sense to start implementing >> before the protocol change is almost fully baked (aka WGLC and further), >> because until then the protocol might change considerably. >> >> So, if we require implementation report further down the road, it needs to >> be more clearly defined than people suddenly shouting “this is not ready” >> when WGLC starts. And while the attempt to implement something is certainly >> useful to get valuable feedback, it also imposes some costs (with undefined >> limit) on implementors (especially the open source implementors) and it sort >> of discards the whole “Proposed Standard” -> “Internet Standard” >> classification at global IETF level. >> >> I get that we probably need something more lightweight than “Internet >> Standard” at the WG level, but this needs to be discussed and consensus >> reached. >> >> ISC gave our feedback during the implementation and here are some nits >> from me (re-reading the document again): >> >> ~~~ >> >> Section "2. Protocol Walkthrough Example" will be made into Appendix at >> publication time, so just reminder here that you also need to change the >> references like "(see the logic below)” when you move the section - perhaps >> add direct reference to the other section this refers to? >> >> ~~~ >> >> The table in 3.2 says: >> >> "Key Tag is trusted” and “Key Tag is not trusted” - it seems little bit >> confusing to me; I think that “Key is trusted” and “Key is not trusted”; or >> some change similar to this needs to be made: >> >> “First, the resolver determines if the Key Tag is trusted by comparing >> numerical value of <key-tag> >> to any of the Key Tags of an active root zone KSK which is >> currently trusted…" >> >> in paragraph just before the table you mix “Key Tag” and “keytag” and >> there’s also <key-tag>… >> >> My understanding of the text and the proposed fix: >> >> […] >> >> First, the resolver determines if the numerical value of <key-tag> is >> equal to any of the Key Tags of an active root zone KSK which is >> currently trusted by the local resolver and is stored in its store of >> trusted keys. If a match is found the <key-tag> is trusted. An active >> root zone KSK is one which could currently be used for >> validation (that is, a key that is not in either the AddPend or >> Revoked state as described in [RFC5011]). >> >> Second, the resolver alters the response being sent to the original >> query based on both the left-most label and the presence of a key >> with given Key Tag in the trust anchor store. Two labels and two >> possible states of the <key-tag> generate four possible combinations >> summarized in the table: >> >> Label | <key-tag> is trusted | <key-tag> is not trusted >> ------------------------------------------------------------------ >> is-ta | return original answer | return SERVFAIL >> not-ta | return SERVFAIL | return original answer >> >> […] >> >> ~~~ >> >> o A query name that is signed with a DNSSEC signature that cannot be >> validated (such as if the corresponding RRset is not signed with a >> valid RRSIG record). >> >> This is called “Bogus” by RFC 4033 Section 5 -> maybe a reference? >> >> ~~~ >> >> In Section: 7. Privacy Considerations >> >> s/mechansim/mechanism/ >> >> ~~~ >> >> That is all folks. >> >> Cheers, >> Ondrej >> -- >> Ondřej Surý >> ond...@isc.org >> >> > On 7 Apr 2018, at 08:27, Evan Hunt <e...@isc.org> wrote: >> > >> > On Fri, Apr 06, 2018 at 10:09:50PM -0400, Warren Kumari wrote: >> >> I think I heard that ISC was considering adding support, but was >> >> planning on waiting till RFC / some sort of LC. >> > >> > Yes. The work in progress is available here: >> > https://gitlab.isc.org/isc-projects/bind9/merge_requests/123 >> > >> > -- >> > Evan Hunt -- e...@isc.org >> > Internet Systems Consortium, Inc. >> > >> > _______________________________________________ >> > DNSOP mailing list >> > DNSOP@ietf.org >> > https://www.ietf.org/mailman/listinfo/dnsop >> > > > -- > I don't think the execution is relevant when it was obviously a bad idea in > the first place. > This is like putting rabid weasels in your pants, and later expressing > regret at having chosen those particular rabid weasels and that pair of > pants. > ---maf > > _______________________________________________ > 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
