Hi Job, While I do agree with you that having implementations early on is a very desirable requirement, though I would disagree with making it a hard requirement (see the case of aggressive negative caching and how it unfolded as an example), for any new idea brought to the IETF I would like to point out a couple of things here:
- there is an established way for drafts to progress to RFCs and within the RFC levels. The progression from proposed to full Standard absolutely requires implementations (plural) - the issue is not specific to any give wg, it is an IETF-wide issue and so the right place for discussion of improving this aspect of standards development is the IETF list rather any specific wg list - in the specific case in the subject, there is funding available to support final implementation of this idea on three code bases. This won’t be released until we are past a successful last-call (because that’s how it works) and so stalling this specific draft on behalf of a way more general idea and discussion is actually having the opposite effect of what the discussion’s goals are. It is delaying final implementation. Just my 2 cents Joao > On 8 May 2018, at 10:49, Job Snijders <j...@ntt.net> wrote: > > On Tue, May 08, 2018 at 11:05:50AM +1000, Mark Andrews wrote: >>>> We have also taken the implementation comments posted to the WG >>>> mailing list and collected them in a new section titled >>>> "Implementation Experience” in the light of Suzanne’s request >>>> >>>> So we would like to pass this draft back to the WG Chairs at this >>>> point for your review for potential submission as an RFC. >>> >>> 1/ While this is a step in the right direction, I'm not yet entirely >>> impressed by the 'Implementation Experience' section. Is it somehow >>> hard to write an implementation report that describes which >>> implementations comply with the BCP 14 / RFC 8174 terms used in >>> draft-ietf-dnsop-kskroll-sentinel? Are the authors experiencing some >>> blocker in this regard? >> >> Is it a implementation report or a compliance report? > > Well, the current section on the implementations isn't much of either, > it is very sparse. This working group should try to raise the bar for > RFC publication, not explore what the bare minimum is. > > I've used this example before: what I was hoping for is reports that > allude to the BCP14 terms and implementation's compliance similar to > what is done here: > https://trac.ietf.org/trac/idr/wiki/draft-ietf-idr-large-community%20implementations > Overviews like these are easy to consume for humans, and are derived > from extensive tests like the one you showed below. > > I'd like to note that describing people's intention to implement in a > section called 'Implementation experience' of course doesn't add much > value. :-) > >> To actually do a full compliance report for this draft it would >> require including a complete DNSSEC compliance report and in turn a >> complete STD 13 compliance report to meet this “MUST”. >> >> DNSSEC-Validating resolvers that implement this mechanism MUST >> perform validation of responses in accordance with the DNSSEC >> response validation specification [RFC4035]. >> >> A exhaustive compliance report would run to a couple of thousand tests >> without doing a DNSSEC compliance report due to the combinatorial >> nature of this draft. >> >> You would need validate as secure zone, a validate as bogus zone, a >> validate as insecure w/ signatures, a validate as insecure w/o >> signatures. You then for all of these need zones with and without A >> and AAAA records at the test names where without includes both NODATA >> and NXDOMAIN. You then need to multiply that by servers configured to >> validate and those configured not to validate. Then you need to >> multiply this by having the functionality enabled or disabled. You >> then need to do a test for each of the conditions in the list of >> conditions that must be met for the modified responses to be returned. >> You also need to do that where the label looked up after a CNAME and a >> DNAME. >> >> We skipped some of these tests when we built our system tests by I >> believe we hit enough of them to be happy that the code is operating >> correctly. > > Yes, I think you are touching upon the core of the issue. Discussing > _how_ to test a specification is exactly the type of discussion to be > held in this working group. > > Its commonly accepted that even seemingly simple specifications may be > stringing together a number of complex features. Extensive testing and > demonstrations of such testing are a necessity to be able to claim > 'running code and rough consensus'. > >> S:rootkeysentinel:Mon May 7 17:55:35 UTC 2018 >> T:rootkeysentinel:1:A >> A:rootkeysentinel:System test rootkeysentinel >> [snip] > > Thanks for sharing this! > > So, the current status is that there is no longer zero, but now a single > implementation of draft-ietf-dnsop-kskroll-sentinel-12? > I see progress, but not last call material. > > Kind regards, > > Job > > _______________________________________________ > 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
