Barry Leiba has entered the following ballot position for draft-ietf-dane-ops-14: 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-dane-ops/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Editorial comments only -- most very minor, but one for Section 4 and its subsections is more substantive. -- Section 1 -- DNSSEC validated DANE TLSA records can be used to augment or replace the use of trusted public Too many cascading modifiers can make a sentence confusing (even if you were to hyphenate "DNSSEC-validated", as it should be). I suggest untangling that slightly, this way: NEW DANE TLSA records validated by DNSSEC can be used to augment or replace the use of trusted public END [RFC6698] defines three TLSA record fields with respectively 4, 2 and 3 currently specified values. There's nothing to correspond with "respectively" here (compare that with the correct use in the first paragrah of the Introduction). Try this: NEW [RFC6698] defines three TLSA record fields, the first with 4 possible values, the second with 2, and the third with 3. END -- Section 3 -- A bit of awkward wording here, and an overly long sentence, both easily fixed: OLD When a servers does support SNI, but is not configured with a certificate chain that exactly matches the client's SNI extension, SHOULD respond with some other (default or closest match) certificate chain, since clients may support more than one server name, but can only put a single name in the SNI extension. NEW When a server supports SNI but is not configured with a certificate chain that exactly matches the client's SNI extension, the server SHOULD respond with another certificate chain (a default or closest match). This is because clients might support more than one server name, but can only put a single name in the SNI extension. END -- Section 4 -- Protocol designers need to carefully consider which set of DANE certificate usages to support. I'm not sure why this (and the next sentence) is referring to "protocol designers". Is this not aimed at implementation/deployment choices? If that's not correct, who are the targets for this advice? I also find this section to be rather hard to follow -- I can't clearly figure out what the advice really is. Can you do a little reorganization here, separating the advice out from the explanation of why? I don't care whether you put the explanation first or the advice first, but it would help to have one paragraph that says, clearly and without fuss, what the recommendation is. This applies to the subsections as well. _______________________________________________ dane mailing list dane@ietf.org https://www.ietf.org/mailman/listinfo/dane
