Éric Vyncke has entered the following ballot position for draft-ietf-dnsop-generalized-notify-08: Yes
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/about/groups/iesg/statements/handling-ballot-positions/ for more information about how to handle DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-dnsop-generalized-notify/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks for the revised version. It addresses my previous blocking DISCUSS points (kept below for archive) Email thread: https://mailarchive.ietf.org/arch/msg/dnsop/Zgc5Q9c2ZAPXi9pJC6zfl2Copoo/ # ALL BELOW IS FOR ARCHIVE ONLY ## DISCUSS (previously blocking) As noted in https://www.ietf.org/blog/handling-iesg-ballot-positions/, a DISCUSS ballot is just a request to have a discussion on the following topics: ### Section 4.1 Deeply sorry, but please use only the example domains in this document rather than `mie.jp`, which is not an example/documentation domain name if not mistaken. ### Section 4.3 Where is a 'valid NOTIFY' defined in `Upon receipt of a (potentially forwarded) valid NOTIFY(CDS) `? This is also related to section 2.1 where the behavior for unknown/unspecified RRtype/scheme is not defined. ## COMMENTS (non-blocking) ### Intended status and section 7 The intended status is "proposed standard" for a rather important change (albeit if only for optimization, i.e., can fail) but there are no real live deployments yet. Did the WG consider using an experimental status first, and proposed standard after 1 year of experimentation ? ### Section 1.1 This section would be more palatable for non-DNS expert by adding some examples. s/design requirements/design goals/ (as this is not real hard requirements) ### Section 2.3 All text is normative in a PS, but why not stressing the "should" by using a "SHOULD" in `message should be sent to the address and port listed` ? Please explain also why some DNS servers could bypass this "should". ### Section 3 s/for discovering that notification target./for discovering that notification target(s)./ ? ### Section 3.1 Suggest instantiating all fields (scheme/port/target) of the example as done in other examples. Should there be an informative reference for `in ICANN's model` ? _______________________________________________ DNSOP mailing list -- dnsop@ietf.org To unsubscribe send an email to dnsop-le...@ietf.org
