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
_______________________________________________ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
