John Scudder has entered the following ballot position for draft-ietf-homenet-front-end-naming-delegation-18: 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: ---------------------------------------------------------------------- This isn't my only concern with this document but Warren Kumari has broadly covered the space with his own DISCUSS. I did want to highlight this one, though. I think it should be relatively easy to fix. Section 4.6, "Securing the Control Channel", almost-mandates security: ``` The control channel between the HNA and the DM MUST be secured at both the HNA and the DM. ``` It does not, however, specify any mandatory-to-implement security mechanism, although it provides an interesting and wide-ranging discussion of many options. It's very difficult for me to see how interoperable implementations can be built, that comply with the quoted requirement, by someone working from the current specification. It does seem from other hints in the document that the authors consider TLS mandatory even though it's not stated as such in Section 4.6. For example, Security Considerations subsection 12.1 says, ``` The channels between HNA and DM are mutually authenticated and encrypted with TLS [RFC8446] and its associated security considerations apply. ``` Another hint that TLS is viewed as mandatory-to-implement is from a different document also currently under review, draft-ietf-homenet-naming-architecture-dhc-options-21 (Sections 4.2 and 4.3): ``` The bit for DNS over TLS [RFC7858] MUST be set. ``` I talk about this more in my comment on Section 4.6, but there's just no way to read this paragraph as mandating TLS: ``` Secure protocols (like TLS [RFC8446]) SHOULD be used to secure the transactions between the DM and the HNA. ``` It doesn't even quite mandate secure transport in general, since it's a SHOULD (so presumably there are times when an implementor can sensibly ignore it, though these are not discussed). What's more, TLS is only given as an example of one transport that would be OK, not as the mandatory-to-implement secure transport. As written, any secure transport, for example TCP-AO, would satisfy this SHOULD. Based on the hints throughout the rest of the document set, that the authors think of TLS as the mandatory-to-implement base transport, I think this section should be rewritten to match that expectation. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- # RTG AD John Scudder's comments for draft-ietf-homenet-front-end-naming-delegation-18 CC @jgscudder Thanks for the work on this document, it clearly reflects a lot of effort. I hope these comments help you get it over the finish line. Although I'm not enough of a DNS expert to evaluate the details of what the document specifies, the number of inconsistencies and minor errors I've flagged in my review makes me concerned that there may be problems with implementability. For this reason I support Warren Kumari's DISCUSS. In my comments below I've flagged a few grammar nits, but for the most part I've tried to restrict myself to cases where it seemed like there was a risk of misunderstanding if not corrected. Even when/if these are fixed I think the document would benefit from a full go-over either manually or using an automated grammar checker, before sending it to the RFC Editor. (Yes the RFC Editor will do their best to fix all of these. But it's better for the authors to do it to the best of their ability, including because occasionally, despite their best efforts, the RFC Editor introduces a "fix" that results in an unwanted normative change.) ## COMMENTS ### Global - "associated to" There are at least 13 occurrences of the phrase "associated to". Can these all be replaced by the more idiomatically correct "associated with"? I hesitate, because "associated to" in computing can have a technically-distinct meaning, however if that's the case in any of these I think such uses of "associated to" may need clarification. So, to be clear: I suggest either replacing these by "associated with", or if that's inappropriate, clarifying the meaning. ### Global - SHOULD vs. MUST A quick grep shows 32 instances of SHOULD or SHOULD NOT in the document (not counting the two in the boilerplate). I haven't audited each one, but for many of these it's difficult to see why they're SHOULD and not MUST. My own heuristic is to think of SHOULD as a "must/unless" pair -- it's desirable to provide some guidance to the implementator as to what circumstances would justify ignoring the SHOULD. If you can't actually think of good reasons to do that, consider changing the SHOULD to a MUST. Or if you're using SHOULD in the sense of "we think you ought to implement it this way but we are trying to be considerate and not yell MUST at you all the time" it's also reasonable to use lower-case words instead of RFC 2119 keywords. I won't comment separately on each individual SHOULD in the document but I encourage you to review them. ### Section 1 "KSK (DS RRset)" Please provide a reference or other hints for those readers who don't speak DNSSEC as a first language (like me). "KSK" could probably use to be expanded on first use, too. ### Section 1.1 ``` However, since communications are established with names which remains a global identifier ``` I don't understand what that clause means. ### Section 1.2 ``` even adapted to IPv6 and ignoring those associated to an IPv4 development ``` I don't understand what this clause means. Is there a word missing between "those" and "associated", and perhaps "to" should be "with"? ### Section 1.3.2 Please expand "CSR" on first use (and provide a reference if appropriate). ### Section 3.1 - "as described" ``` as described in Figure 1 ``` Perhaps "as depicted in Figure 1"? I don't think Figure 1 can be said to be a (full) description of anything. ### Section 3.1 - "answer to" "it is not expected to answer to DNS requests" --> "it is not expected to answer DNS requests" (changed "answer to" to just "answer", there is a slightly different shade of meaning) ### Section 3.2 ``` The visible NS records SHOULD remain pointing at the cloud provider's server IP address" ``` This is the sole mention of a "cloud provider" in the document. Re-word? ### Section 4 ``` the IP address and port number to use and protocol to set secure session ``` I don't understand what that clause means (in particular "protocol to set secure session"). ### Section 4.2 For this text, ``` By accepting the DS RR, the DM commits in taking care of advertising the DS to the parent zone. Upon refusal, the DM clearly indicates it does not have the capacity to proceed to the update. ``` Would the below rewrite be correct? If not, please propose another. ``` By accepting the DS RR, the DM commits to advertise the DS to the parent zone. On the other hand if the DM does not have the capacity to advertise the DS to the parent zone, it indicates this by refusing the DS RR. ``` ### Section 4.3 I don't understand what this paragraph is telling me about the provision of the IP address by the HNA: ``` The HNA works as a primary authoritative DNS server, while the DM works like a secondary. As a result, the HNA must provide the IP address the DM is using to reach the HNA. The synchronization Channel will be set between that IP address and the IP address of the DM. By default, the IP address used by the HNA in the Control Channel is considered by the DM and the specification of the IP by the HNA is only OPTIONAL. The transport channel (including port number) is the same as the one used between the HNA and the DM for the Control Channel. ``` You start out by saying the "the HNA must provide the IP address the DM is using to reach the HNA". (By the way when you say "is using" I think you mean "should use". No?) I note the use of "must". But then you go on to say that "the specification of the IP by the HNA is only OPTIONAL". (I assume that "the IP" here means "the IP address" that was discussed a few sentences back, probably you should add the word "address" if so.) These two sentences, the "must" in the first one and the "OPTIONAL" in the later, seem directly in opposition to one another. :-( ### Section 4.5.2 ``` The DM SHOULD ignore non-empty the Pre-requisite and Additional Data section" ``` I don't know what this means. If "non-empty" weren't there, I would get it, it would just mean "ignore the pre-req and additional data sections no matter what their content is" -- so maybe the easiest fix is to delete "non-empty" (and changing "section" to "sections" while you're at it), as in ``` The DM MUST ignore the Pre-requisite and Additional Data sections, if present. ``` ### Section 4.5.2 These two paragraphs seem a little inconsistent: ``` An error indicates the MD does not update the DS, and other method should be used by the HNA. The regular DNS error message SHOULD be returned to the HNA when an error occurs. In particular a FORMERR is returned when a format error is found, this includes when unexpected RRSets are added or when RRsets are missing. A SERVFAIL error is returned when a internal error is encountered. A NOTZONE error is returned when update and Zone sections are not coherent, a NOTAUTH error is returned when the DM is not authoritative for the Zone section. A REFUSED error is returned when the DM refuses to proceed to the configuration and the requested action. ``` I would have guessed that the implication of some of the errors cited in the second paragraph is that the HNA should correct the problem and then retry. But the first paragraph seems to indicate that an HNA shouldn't bother even considering the error code, because "and other method should be used by the HNA". I'm not sure how, or if, to resolve this seeming inconsistency. ### Section 4.5.3 ``` Similarly to Section 4.5.2, DNS errors are used and an error indicates the DM is not configured as a secondary. ``` Related to the previous comment -- is this true regardless of what error code is returned, for example would a FORMERR mean that the DM is not configured as a secondary? Even given that any error implies that the operation failed, what if the DM had already been previously configured as secondary, and the operation were merely updating some parameter? Would the previous configuration be voided, as the text currently implies? Or would the DM remain configured as secondary, using the previous configuration? ### Section 4.6 These two paragraphs seem inconsistent: ``` The control channel between the HNA and the DM MUST be secured at both the HNA and the DM. Secure protocols (like TLS [RFC8446]) SHOULD be used to secure the transactions between the DM and the HNA. ``` MUST the channel be secured? Or is it only SHOULD? Also, does the second paragraph really mean "secure *transport* protocols", or is the ambiguity intentional? By ambiguity, I suppose the paragraph as written might be satisfied by object-level security, for instance, and for that matter it leaves it up to the reader to even define exactly what they mean by "security". Finally, see also my DISCUSS comments -- if you actually want to mandate TLS (as implied by some of the other parts of this document, and draft-ietf-homenet-naming-architecture-dhc-options-21), you need to make some changes to this section. ### Section 4.6 Please expand SAN on first use. ### Section 7 ``` Depending how the communications between the HNA and the DM are secured, only packets associated to that protocol SHOULD be allowed. ``` This is too vague. What specifically about the means of securing the communications would lead the implementor to follow, or disregard, the SHOULD? ### Section 10 ``` Then, the HNA advertises the DM via a NOTIFY, that the Public Homenet Zone has been updated ``` Probably you mean "advertises to" or maybe better, "advises", where you've written "advertises"? If not, then I don't understand what's happening in this part. ### Section 12.2 Consider using "their" instead of "his". ### Section 14 Was "its" chosen as the pronoun for two persons being thanked, based on those persons' preferences? If not then consider whether you've used the right pronoun in those two places, in my experience it's fairly rare -- but not unheard-of! -- for a person to prefer to be referred to as "it" rather than the more common "he", "she", or "they". ### Appendix A.1 I'm a little confused -- the first couple of paragraphs led me to believe that this section was just going to tell me what parameters are required, but wasn't going to mandate the means of providing them. But then we come to, ``` The above parameters MUST be be provisioned for ISP-specific reverse zones, as per [I-D.ietf-homenet-naming-architecture-dhc-options]. ``` The "MUST" combined with the "as per" implies you're mandating that DHCPv6 be used to provision the parameters. If you really do intend to make dhc-options mandatory, it needs to be a normative reference. On the other hand if, as I think is likely, you only intended to use dhc-options as an example, perhaps something like this rewrite? ``` The above parameters MUST be be provisioned for ISP-specific reverse zones. One example of how to do this can be found in [I-D.ietf-homenet-naming-architecture-dhc-options]. ``` ### Appendix B - "registered_domain" or "zone"? This threw me off -- in the CDDL you show "registered_domain" but in the explanatory text you describe (what I think is) this field as "Registered Homenet Domain (zone)". Should the latter be "Registered Homenet Domain (registered_domain)" instead? (Or, rename "registered_domain" in the CDDL as "zone"?) ### Appendix B - 2119 keywords It's weird that you lead with "This section is non-normative" but then pepper the content with the RFC 2119 keyword "OPTIONAL". I think probably you don't mean it's "non-normative" (that generally means something like "this is an example, it doesn't define anything, it can safely be ignored"). Rather, I think you mean implementing it is optional. I think you could fix this by deleting the words "is non-normative and". Also, "MANDATORY" isn't an RFC 2119 keyword but you've capitalized it like one. If you want to introduce your own keyword to put the the force of VERY SERIOUS NORMATIVE CAPITALIZATION behind this word, I think it would be a good idea to define it in your Terminology section, probably right after the RFC 2119 boilerplate paragraph. Alternately, you could just change all your uses of "mandatory" and "optional" in this section to lower-case. It would still be clear, IMO. ## NITS - "these names needs" --> "these names need" - "The remaining of the document" --> "the rest of the document" - "buys a domain name to a registrar" --> "buys a domain name from a registrar" - "DOI has a roof of ownership" --> "roof" should be... "proof"? - "as detaille din further details below" --> "as detailed below" - "rsynch" --> "rsync" - "meth of" --> "method" ## Notes This review is in the ["IETF Comments" Markdown format][ICMF], You can use the [`ietf-comments` tool][ICT] to automatically convert this review into individual GitHub issues. [ICMF]: https://github.com/mnot/ietf-comments/blob/main/format.md [ICT]: https://github.com/mnot/ietf-comments _______________________________________________ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
