Re: [DNSOP] Mirja Kühlewind's No Objection on draft-ietf-dnsop-serve-stale-09: (with COMMENT)
On Tue, Dec 3, 2019 at 1:28 PM Mirja Kuehlewind wrote: > > Hi Dave, > > Just on this point: > > > On 2. Dec 2019, at 23:42, Dave Lawrence wrote: > > > >> 2) I find the Implementation Status section (8) actually quite > >> interesting for this document and maybe it should be considered to > >> keep it in the document for final publication. > > > > I personally am in favor of this, not just for this document but for > > all RFCs. RFC 6982 recommends that the section be removed, but I'd > > be happy to help evolve that recommendation. > > RFC6982 recommends this because usually it's more important to have this > information during the life-time of a draft (to understand the maturity of > the protocol) but then it might quickly get out-dated after publication. > However, we had also drafts were we retained the section for final > publication because e.g. the whole draft was based on one specific > implementation. I think that is also the case here and there is nothing in > RFC6982 that permits keeping this information in the draft (if it seen as > still useful in future). Note: Author hat only. I'm not 100% sure, but I suspect you meant: "I think that is also the case here and there is nothing in RFC6982 that **prevents** keeping this ..."? I'm personally in favor of keeping the information - even if it ends up out of date, it still seems useful to me. W > > Mirja > > -- 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
Re: [DNSOP] Mirja Kühlewind's No Objection on draft-ietf-dnsop-serve-stale-09: (with COMMENT)
Dave Lawrence writes: > We had a lot of back-and-forth in the working group about > normative language in this document, and but for the Standards Action > section. Huh, I clearly had a slipping brain clutch in the middle of that sentence when it came to the final phrase. I think I had intended to finish the sentence something like "... determined it was best to not use normative keywords." Apologies for my failure to proofread before sending. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Mirja Kühlewind's No Objection on draft-ietf-dnsop-serve-stale-09: (with COMMENT)
Hi Dave, Just on this point: > On 2. Dec 2019, at 23:42, Dave Lawrence wrote: > >> 2) I find the Implementation Status section (8) actually quite >> interesting for this document and maybe it should be considered to >> keep it in the document for final publication. > > I personally am in favor of this, not just for this document but for > all RFCs. RFC 6982 recommends that the section be removed, but I'd > be happy to help evolve that recommendation. RFC6982 recommends this because usually it's more important to have this information during the life-time of a draft (to understand the maturity of the protocol) but then it might quickly get out-dated after publication. However, we had also drafts were we retained the section for final publication because e.g. the whole draft was based on one specific implementation. I think that is also the case here and there is nothing in RFC6982 that permits keeping this information in the draft (if it seen as still useful in future). Mirja ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Mirja Kühlewind's No Objection on draft-ietf-dnsop-serve-stale-09: (with COMMENT)
Thank you very much for your review, Mirja. > 1) It seems to me that this sentence in section 7 should/could > actually be phrased as a normative requirement in this document: "it > is not necessary that every client request needs to trigger a new > lookup flow in the presence of stale data, [...]" I agree. We had a lot of back-and-forth in the working group about normative language in this document, and but for the Standards Action section. I'm personally in support of more of it, but ended up having to strip out existing instances of normative language based on working group consensus. > 2) I find the Implementation Status section (8) actually quite > interesting for this document and maybe it should be considered to > keep it in the document for final publication. I personally am in favor of this, not just for this document but for all RFCs. RFC 6982 recommends that the section be removed, but I'd be happy to help evolve that recommendation. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] Mirja Kühlewind's No Objection on draft-ietf-dnsop-serve-stale-09: (with COMMENT)
Mirja Kühlewind has entered the following ballot position for draft-ietf-dnsop-serve-stale-09: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-dnsop-serve-stale/ -- COMMENT: -- Two comments: 1) It seems to me that this sentence in section 7 should/could actually be phrased as a normative requirement in this document: "it is not necessary that every client request needs to trigger a new lookup flow in the presence of stale data, but rather that a good-faith effort has been recently made to refresh the stale data before it is delivered to any client." Maybe worth considering... 2) I find the Implementation Status section (8) actually quite interesting for this document and maybe it should be considered to keep it in the document for final publication. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
