Hi Murray, Thanks for the review and please find below the changes we made:
We review all SHOULD and proceeded to some changes that you can find below: https://github.com/ietf-homenet-wg/ietf-homenet-hna/commit/f6ff51deb2bdca2894310ff17b28a1278740da90 The end result is 6 SHOULD. The mangled part of section 4.1.1 has been fixed as mentioned below: https://github.com/ietf-homenet-wg/ietf-homenet-hna/commit/f66e354f883cd8aa879186e46ba6fbf30f098757 """ * If the DOI is not the DNS Registrar, then the proof of ownership needs to be established using some other protocol. ACME {{?RFC8555}} is one protocol that would allow an owner of an existing domain name to prove their ownership (but requires they have DNS already setup!) There are other ways such as putting a DOI generated TXT record, or web site contents, as championed by entities like Google's Sitemaster and Postmaster protocols. """ Yours, Daniel On Fri, Dec 30, 2022 at 9:54 PM Daniel Migault <mglt.i...@gmail.com> wrote: > Hi Murray, > > Thanks for the review. I will provide a more complete review in a few > days, but here are some quick and partial responses. > > Yours, > Daniel > > On Fri, Dec 30, 2022 at 7:16 PM Murray Kucherawy via Datatracker < > nore...@ietf.org> wrote: > >> Murray Kucherawy has entered the following ballot position for >> draft-ietf-homenet-front-end-naming-delegation-25: Discuss >> >> 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-homenet-front-end-naming-delegation/ >> >> >> >> ---------------------------------------------------------------------- >> DISCUSS: >> ---------------------------------------------------------------------- >> >> According to the shepherd writeup (and assuming it still reflects reality >> today; it's dated July of this year, nine revisions ago), there are no >> implementations, and none are planned. > > One of the co-author (Ray) implemented it, but it is not published. I am > planning to implement it as we recently had a use case for it. > >> There's no Implementation Status >> section either. However, in the reply to Paul's earlier DISCUSS, there >> as a >> claim that some part of this was implemented. I've also been told there >> is one >> vendor planning to implement this, but that doesn't match the record. Can >> someone clarify where we are today? The existence of implementations >> would >> certainly allay the previous concerns about complexity and clarity that >> were >> expressed in other prior ballot positions. >> >> This document has been in development for over 10 years. Assuming there >> is no >> wide deployment or an implementation to which one can refer, why are we >> publishing this on the standards track? Wouldn't Experimental or >> Informational >> be more appropriate? The shepherd writeup doesn't explain why Proposed >> Standard is justified; it just says "PS". >> > The reason we want a Standard Track is that our use case is 3GPP related > and 3GPP only considers Standard Track. > >> >> (Please note that RFC 2026 says implementations aren't required, so I am >> not >> requiring one either by posting this ballot. I just want to have the >> discussion.) >> >> >> ---------------------------------------------------------------------- >> COMMENT: >> ---------------------------------------------------------------------- >> >> Thanks for all the work that went into this, especially since its last >> pass >> through the IESG. >> >> I generally found this to be readable if I look at it as an applicability >> statement (RFC 2026, Section 3.2) over DNS for the Homenet use case. Was >> that >> the intent, or am I way off? >> >> Thanks to Darrel Miller for his ARTART review. (A second review on the >> latest >> revision is pending as I write this.) >> >> The last bullet of Section 4.1.1 appears to be mangled in a few places. >> Please >> review. >> >> I have my usual complaint about the use of SHOULD throughout the document: >> SHOULD provides implementers with a choice, and generally the SHOULDs here >> don't acknowledge that choice or provide implementers with any guidance >> about >> when it might be appropriate to exercise that choice. I suggest >> reviewing them >> (there are 25, and 6 RECOMMENDEDs) and either adding such prose, or >> reconsidering whether they should be MUST or MAY. >> >> >> >> _______________________________________________ >> homenet mailing list >> homenet@ietf.org >> https://www.ietf.org/mailman/listinfo/homenet >> > > > -- > Daniel Migault > Ericsson > -- Daniel Migault Ericsson
_______________________________________________ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
