Thank you very much for the clarification! Yours, Daniel
On Thu, Aug 11, 2022 at 7:38 AM Eric Vyncke (evyncke) <evyn...@cisco.com> wrote: > [2nd attempt as O365 has rejected my first reply...] > > > > Hello Daniel, > > > > Thanks for the changes except for the references, the goal of the > normative/informative is not ‘to pass the id-nits’ examination but rather > to give the readers the list of what they MUST read to implement > (normative) and the list of useful links to understand (informative) > > > > Regards, > > > > -éric > > > > PS: going in vacation mode for one week... > > > > *From: *Daniel Migault <mglt.i...@gmail.com> > *Date: *Wednesday, 10 August 2022 at 18:00 > *To: *Eric Vyncke <evyn...@cisco.com> > *Cc: *"homenet@ietf.org" <homenet@ietf.org> > *Subject: *Re: [homenet] AD review of > draft-ietf-homenet-front-end-naming-delegation-16 > > > > Hi Eric, > > > > Thanks for the response. Just to follow-up on the latest comments > > > > On Tue, Aug 9, 2022 at 2:11 AM Eric Vyncke (evyncke) <evyn...@cisco.com> > wrote: > > Hello Daniel, > > > > Thank you for the quick reply. I had a quick browse through the commit and > it seems that some points are yet to be addressed: > > - List of normative references [1] > > Currently we set the normative and informational references so it passes > the checks. As a result any standard track reference is moved to the > normative section and informational references are moved to the informative > section. . I am wondering if you are requesting that we only keep the > essential normative references in the normative sections - that is the > references that are mandatory to be considered. If that is the case, this > could lead to a standard track reference being moved to the informative > section. Before we proceed to the changes, we just would like to make > sure this is what is expected. > > > > > - RFC 7404 is not specifying LLA ;-) > > This is correct but it explains how to use them. We updated LLA > references for IPv4/IPv6 as follows: > > > > A device or service may have Global Unicast Addresses (GUA) (IPv6 > {{?RFC3787}} or IPv4), a Unique Local IPv6 Address (ULA) {{?RFC4193}}, as > as well IPv6-Link-Local addresses{{!RFC4291}}{{!RFC7404}}, IPv4-Link-Local > Addresses {{!RFC3927}} (LLA), and private IPv4 addresses {{!RFC1918}}. > > > - s/ as as well/as well as/ ? > > changed > > > - > - no justification for ‘one to three’ in section 1.2, simply remove > those words > > The justification we added was a plausible list of instances, but we are > fine removing it. > > OLD: > > For a very few numbers (one to three) of hosts (media servers, VPN > gateways, ... ), > > NEW: > > For a very few numbers of hosts, > > > - > > > > Yours, > > Daniel > > Please continue the good work > > > > Regards > > > > -éric > > > > [1] I am sure that you know > https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/ > > > > *From: *Daniel Migault <mglt.i...@gmail.com> > *Date: *Tuesday, 9 August 2022 at 04:21 > *To: *Eric Vyncke <evyn...@cisco.com> > *Cc: *"homenet@ietf.org" <homenet@ietf.org> > *Subject: *Re: [homenet] AD review of > draft-ietf-homenet-front-end-naming-delegation-16 > > > > Hi Erik, > > > > Thanks for the careful review. That is really much appreciated. We have > addressed most of the changes in line as well as here: > > > https://github.com/ietf-homenet-wg/ietf-homenet-hna/commit/f9157a3db159dc327a3e9d5c85e9f9f83a458729 > > > > There is one remaining change we need to make, and I hope we will be able > to submit a new version in the coming days. Feel free to let us know if the > changes are addressing your concerns. > > > > Yours, > Daniel > > > > On Mon, Aug 8, 2022 at 9:31 AM Eric Vyncke (evyncke) <evyncke= > 40cisco....@dmarc.ietf.org> wrote: > > As usual, I do my own review before requesting the IETF Last Call for all > documents. The intent is to give another polishing pass on the I-D. > > > > For this review, the MD format is used. > > > > Hope this helps > > > > Regards > > > > -éric > > > > # Éric Vyncke, INT AD, comments for > draft-ietf-homenet-front-end-naming-delegation-16 > > CC @evyncke > > > > Thank you for the work put into this document. Multiple nits and typos are > identified in the end of this review, I would have expected a document that > has been through spell and grammar checkers. > > > > Please find below one blocking DISCUSS points (easy to address), some > non-blocking COMMENT points (but replies would be appreciated even if only > for my own education), and some nits. > > > > Special thanks to Stephen Farrel for the shepherd's detailed write-up > including the WG consensus, *but* it lacks the justification of the > intended status. > > > > I hope that this review helps to improve the document, > > > > Regards, > > > > -éric > > > > ## DISCUSS > > > > ### id-nits, references to be updated > > > > Please have a look at > https://author-tools.ietf.org/api/idnits?url=https://www.ietf.org/archive/id/draft-ietf-homenet-front-end-naming-delegation-16.txt > and address the updated references. > > > > ### id-nits, downref > > > > As noted by Stephen in his review (and I second his proposal), several > normative references should probably "just" informative. > > > > downref have been moved to informative > > ### HNA certs > > > > >From my reading of the text, it is really unclear whether HNA certs are / > may be self-signed and what the subject alt name is (IP address ? FQDN ? > other). > > > > The text does not specify how certificate authentication is performed and > leaves it relatively open to what TLS supports. Since the communication > between the DM and the HNA is mutually authenticated there are two > certificates involved: the certificates of the HNA and the certificate of > the DM. > > In most deployments the DM is expected to be authenticated using the web > PKI or alternatively using DANE or when the HNA is completely provisioned > with some provisioned keys. To authenticate the HNA, the DM may need to > bind the HNA to a registered client with the associated Registered Homenet > Domain. > > There are multiple ways, one is that the certificate contains an account > reference as well as the FQDN which could be both inserted in the SAN (URN > and FQDN). Other deployments may only have certificates with the FQDN... It > is highly probable that the DM will trust the information based on the CA > that issued the certificate - which as I imagine is likely to belong to the > same organization as the DM. On the other hand, a Let's encrypt certificate > may also be acceptable. > > > > The current text in Section "Securing the Control Channel" omits all > details and is as mentioned below: > > > > OLD: > > The DM SHOULD authenticate the HNA and check that inbound messages are > from the appropriate client. > > The DM MAY use a self-signed CA certificate mechanism per HNA, or public > certificates for this purpose. > > > > I propose the following text, please let me know if that addresses your > concern. > > > > NEW: > > The DM SHOULD authenticate the HNA and check that inbound messages are > from the appropriate client. > > The DM MAY use a self-signed CA certificate mechanism per HNA, or public > certificates for this purpose. > > The HNA certificate needs to provide sufficient trust to the DM that the > HNA is legitimate. When certificates are used, it is left to the DM to > define what information carried by the certificate is acceptable as well as > which CA can issue the certificate. For example, some deployments may use > domain validation certificates with the Registered Homenet Domain as a SAN > of type FQDN. Other deployments may use specifically formed certificates > with additional information such as a user account as a SAN of type URN, > signed by a specific CA may be used. > > > > > > ### Section 1, multiple IP addresses > > > > In `A device may have a Global Unicast Address (GUA),`, it appears by the > use of 'a' that devices can have only one. Suggest removing 'a'. > > > > In the same vein, even in residential network, there may be global IPv4 > addresses. > > > > changed to: > > A device may have Global Unicast Addresses (GUA) (IPv6 or IPv4), a Unique > Local IPv6 Address (ULA), as as well IPv6-Link-Local addresses, > IPv4-Link-Local Addresses, and RFC1918 addresses. > > ### Section 1.2, 1 to 3 ? > > > > Please justify the limit to 3 in `For a very few number (one to three) of > hosts` > > > > changed to: > > For a very few number (one to three) of hosts (media servers, VPN > gateways, . .. ),... > > ### Section 1.2, requirements ? > > > > Please add a reference (or rephrase) the requirement in `Such dependence > does not meet the requirement for`. > > > > adding {{?RFC7368}} as a reference of the requirement. > > ### Section 2, Homenet Authoritative Servers: > > > > For which zones `Homenet Authoritative Servers:` ? > > > > adding: > > for the Homenet Zone > > ### Section 3.2 > > > > The I-D proposes to use DoH & DoQ as transport, but did the authors check > that AXFR operations can be made over DoH ? > > I am not aware of this being standardized but I do not see anything that > could prevent it. > > > > The current text I see mentioning DoH and DoQ are as follows: > > > > The information exchanged between the HNA and the DM uses DNS messages > protected by DNS over TLS (DoT) {{!RFC7858}}. > Other specifications may consider protecting DNS messages with other > transport layers, among others, DNS over DTLS {{?RFC8094}}, or DNS over > HTTPs (DoH) {{?RFC8484}} or DNS over QUIC {{?RFC9250}}. > > > > I do see some confusion that QUIC or DoH are not clearly identified as not > supporting AXFR (now). I propose the following change: > > In the future, other specifications may consider protecting DNS messages > with other transport layers, among others, DNS over DTLS {{?RFC8094}}, or > DNS over HTTPs (DoH) {{?RFC8484}} or DNS over QUIC {{?RFC9250}}. > > > > The other place I found is there and I do not think any other changes are > needed. > > > > Supported Transport (dm\_transport) > : The transport that carries the DNS exchanges between the HNA and the DM. > Typical value is "DoT" but it may be extended in the future with "DoH", > "DoQ" for example. > > This parameter is OPTIONAL and by default the HNA uses DoT. > > ### Section 4.5.4 SHOULD ? > > > > Please explain when the 'SHOULD' does not apply. > > > > SHOULD has been removed. > > > > ### Section 5, port XX > > > > As the XX on DM is 853, does it require the HNA to also listen on XX == > 853 ? > > > > Yes for the synchronization channel: > > > > On the other hand, the Synchronization Channel is set between the DM > working as a client using port ZZZZ ( a high range port) toward a service > provided by the HNA at port XX. > > ### Section 5 > > ``` > > The use of a primary / secondary mechanism is RECOMMENDED instead of > > the use of DNS Update > > ``` > > > > What is 'primary/secondary mechanism' ? Missing transfer ? > > > > 'DNS update' is it the HTTP RESTful one ? Is it the same as 'DNS UPDATE > [RFC2136]' used later in the section ? > > > > I think the most accurate reference for primary / secondary is 1996. The > mechanisms was described a master / slave. Yes DNS Update is DNS UPDATE. I > added the two references and the text has been changed as follows: > > > > The use of a primary / secondary mechanism {{!RFC1996}} is RECOMMENDED > instead of the use of DNS UPDATE {{?RFC2136}}. > > > > We changed all DNS Update to DNS UPDATE as well. > > ### Section 11.3 > > > > Who is the end user in : > > ``` > > ... For > > that reason end users may choose not to respond to PTR DNS queries > > and MAY instead return a NXDOMAIN response. > > ``` > > You are correct this is the end-user / admin. ;-) > > > > OLD: > > For that reason end users may choose not to respond to PTR DNS queries and > MAY instead return a NXDOMAIN response. > > > > NEW: > > For that reason PTR DNS queries and MAY instead be configured to return > with NXDOMAIN. > > > > ### Appendix A, why in appendix ? > > > > Is there a reason why the reverse zone is in the appendix ? There should > at least be a forward reference in the introduction to the appendix but > better to move in the main body. > > > > Re-added in the body. The reason it has been put in the appendix is that > it is a variant of the forward zone - that is a specific case. On the other > hand, it could be also seen as an essential part of the architecture. > > > > ## COMMENTS > > > > ### Shepherd's review, intended status > > > > Stephen, as noted above, please include some justification for the > intended PS status. > > > > ### Section 1, devices or services ? > > > > ``` > > Home network owners often have devices that they wish to access > > outside their home network - i.e., from the Internet using their > > names. > > ``` > > > > As DNS contains more than mere IP addresses and as a single device can > host many services with different IP addresses, propose to use 'devices and > services'. > > > > This issue also appears in other sections (e.g., sect 1.1) > > > > we updated 6 ish occurrences. > > ### Section 1.1, un-parsable ? > > > > Is it parsable for a native-English speaker ? > > ``` > > While this document does not create any normative mechanism by which > > the selection of names to publish, > > ``` > > > > I think the wording below might be better > > > > While this document does not create any normative mechanism to select the > names to publish, this document anticipates that the home network > administrator (a human), will be presented with a list of current > names and addresses. > > > > ### Section 1.1, inside ? > > > > Please define (or add a reference) for `on the inside of the home`. > > > > see above. > > ### Section 1.1, DHCP rebinding ? > > > > The reference to RFC 6644 is a little weird to me, either use 'DHCP > rebind' or use the right RFC for DHCPv6. > > The reference to DHCPv6 has been updated and the sentence is as follows: > > The address of the device or service can be collected from a number of > places : mDNS {{!RFC6762}}, DHCP {{!RFC8415}}, UPnP, PCP {{!RFC6887}}, > or manual con figuration. > > > > ### Section 1.1, RFC 1918 or private > > > > Please add a reference to ULA and use 'private IPv4 addresses' rather than > 'RFC 1918 addresses' ? > > > > Here is the updated text: > > > > A device or service may have Global Unicast Addresses (GUA) (IPv6 > {{?RFC3787}} or IPv4), a Unique Local IPv6 Address (ULA) {{?RFC4193}}, as > as well IPv6-Link-Local addresses, IPv4-Link-Local Addresses (LLA) > {{?RFC7404}}, and private IPv4 addresses {{!RFC1918}}. > > ### Section 1.1, TLS ? > > > > Why is TLS mentioned here ? It should rather be in the security section. > > > > I think the text is expected to highlight that name are global identifiers > even if local scope IP addresses are used. > > > > The old text was: > > In general, one expects the GUA to be the default address to be published. > However, publishing the ULA and RFC1918 may enable local communications > within the home network. > Since the communication has been initiated with a name which remains a > global identifier, the communication can be protected by TLS the same way > it is protected on the global Internet. > A direct advantage of enabling local communication is to prevent > communications even in case of Internet disruption. > > > > Perhaps the new text below is clearer: > > > > In general, one expects the GUA to be the default address to be published. > > However, publishing the ULA and RFC1918 may enable local communications > within the home network. > A direct advantage of enabling local communication is to > enable communications even in case of Internet disruption. > > However, since communications are established with names which remains a > global identifier, the communication can be protected by TLS the same way > it is protected on the global Internet. > > ### Section 1.1 > > > > This is probably the reverse: > > ``` > > A direct advantage of enabling local > > communication is to prevent communications even in case of Internet > > disruption. > > ``` > > > > changed prevent to enable > > ### Section 1.2 > > > > `As there are some commonalities provides by individual home` possibly a > typo. > > > > change provides to provided > > ### Section 3.1, which network ? > > > > In `When the request is coming within the network`, which network ? Even > if guessable, let's be clear. > > > > changed to: > > When the request is coming within the home network, > > > > ### Section 3.1 > > > > Should '.local' also appear in figure 1? > > > > My understanding is that .local is mostly used with DNSSD which is > advertised via multicast as opposed to a zone. For that reason home.arpa > seems more appropriated. Now it is also correct that there are some > mechanisms that convert .local advertised via DNSSD into a zone, but I > think such considerations are a bit out of scope of the document. > > ### Section 3.2 > > > > What is `cloud provider's anycast addresses`? > > > > The anycast address is the address used by the cloud provider to > distribute the homenet zone. I agree this is not necessarily an anycast > address though I think it clearly shows the interest of using a cloud > provider with specific properties. > > > > Perhaps the following change can clarify the text: > > > > OLD: > > The visible NS records SHOULD remain pointing at the cloud provider's > anycast addresses. > > > > NEW: > > The visible NS records SHOULD remain pointing at the cloud provider's > server IP address -- which in many cases will be an anycast addresses. > > > > ### Section 4.6 oxymoron ? > > > > Isn't `The DM MAY use a *self-signed CA* certificate mechanism per HNA` an > oxymoron ? > > > > I think what the text is trying to say is that the DM may use a dedicated > CA specifically provisioned for the service and dedicated to issue > certificates for HNA. > > I agree that the text can be hard to parse and considering that we already > changed some of the initial text in a previous comment, I think we can > simply remove the sentence. > > The full paragraph would move from : > > > > OLD: > > The DM SHOULD authenticate the HNA and check that inbound messages are > from the appropriate client. > The DM MAY use a self-signed CA certificate mechanism per HNA, or public > certificates for this purpose. > The HNA certificate needs to provide sufficient trust to the DM that the > HNA is legitimate. When certificates are used, it is left to the DM to > define what information carried by the certificate is acceptable as well as > which CA can issue the certificate. For example, some deployments may use > domain validation certificates with the Registered Homenet Domain as a SAN > of type FQDN. Other deployments may use specifically formed certificates > with additional information such as a user account as a SAN of type URN, > signed by a specific CA may be used. > > > > TO: > > The DM SHOULD authenticate the HNA and check that inbound messages are > from the appropriate client. > The HNA certificate needs to provide sufficient trust to the DM that the > HNA is legitimate. When certificates are used, it is left to the DM to > define what information carried by the certificate is acceptable as well as > which CA can issue the certificate. For example, some deployments may use > domain validation certificates with the Registered Homenet Domain as a SAN > of type FQDN. Other deployments may use specifically formed certificates > with additional information such as a user account as a SAN of type URN, > signed by a specific CA may be used. > > > > ### Section 4.6, ambiguous > > > > In `The DM MAY use a self-signed CA certificate mechanism per HNA`, is > this cert used to verify the connection from HNA or rather used by the DM > to sign its messages ? > > > > It is for the DM to authenticate the HNA. I think the text above clarifies > this as well. > > ### Section 4.7 SHOULD > > > > When can an implementation not follow the "SHOULD" ? > > > > The text in question is as follows: > > > Limited exchanges: > : the purpose of the Hidden Primary Server is to synchronize with the DM, > not to serve any zones to end users, or the public Internet. > This results in a limited exchanges (AXFR/IXFR) with a small number of IP > addresses and such limitations SHOULD be enforced by policies described in > {{sec-cpe-sec-policies}}. > > > > > > The intent is to say that the implementation SHOULD enable filtering > unexpected DNS packets and IP addresses. I think the following sentence may > be clearer: > > This results in a limited number of possible exchanges (AXFR/IXFR) with a > small number of IP addresses and an implementation SHOULD enable filtering > policies as described in {{sec-cpe-sec-policies}}. > > > > ### Section 3, synchronization or transfer > > > > Just wondering whether 'synchronization' is the best word (as it is mainly > HNA updated one-way the DM), why not simply 'transfer' ? > > I am obviously biaised, but I do think that synchronization is more > appropriated as the channel is used to tranfer as well as to check the file > version to ensure both primary and secondary have the same version of the > zone file. > > ### Section 5 > > > > A small figure would be nice. > > Actually Figure 1 mentions all channels. Do you think we should remind the > reader about this or do you expect another figure ? > > > > ### Section 5, CPE only > > > > ``` > > The HNA acts as a Hidden Primary Server, which is a regular > > authoritative DNS Server listening on the WAN interface. > > ``` > > > > Does this mean that only CPE can be a HNA ? Then, what about the previous > paragraphs about multiple HNA at home? > > > > Practically this is expected to be the most common case, but HNA is not > necessarily a CPE. When there are multiple candidates for the HNA, we need > to pick one. > > I think we have some text that mentions this but feel free to let me > know if I am missing something. > > > > Note that there is no standard way to distribute a DNS primary between > multiple devices. > As a result, if multiple devices are candidate for hosting the Hidden > Primary, some specific mechanisms should be designed so the home network > only selects a single HNA for the Hidden Primary. > Selection mechanisms based on HNCP {{!RFC7788}} are good candidates. > > > > ### Section 5.1 > > > > Please also add which parties are the primary and secondary. > > > > I suppose the correspondence between HNA / DM and primary / secondary is > missing. I propose the following change: > > > > OLD: > > First the primary notifies the secondary that the zone must be updated and > leaves the secondary to proceed with the update when possible/convenient. > > > > NEW: > > First the HNA (primary) notifies the DM (secondary) that the zone must be > updated and leaves the DM (secondary) to proceed with the update when > possible/convenient. > > > > Note that I also changed the exchange description that seems like an > additional procedure as opposed to a more detailed description of the high > level mechanism just described above. I think that was part of the > confusion and the text is now as follows: > > > > More specifically, the HNA sends a NOTIFY message, which is a small packet > that is less likely to load the secondary. > Then, the DM sends AXFR {{!RFC1034}} or IXFR {{!RFC1995}} request. This > request consists in a small packet sent over TCP (Section 4.2 > {{!RFC5936}}), which also mitigates reflection attacks using a forged > NOTIFY. > > > > ### Section 5.1, DNS resolution > > > > Humm is `(via DNS resolution)` normative ? > > > > change to via a DNS resolution > > When can the last 'SHOULD' be ignored ? > > > > The SHOULD is likely to be ignored on minimal implementations. The > additional SHOULD describes a mechanism to make the mechanism more stable > but that is not strictly mandatory. > > ### Section 7, SHOULD > > > > Please explain when the 'SHOULD' can be ignored. > > > > The first SHOULD has been changed from: > > OLD: > > The HNA, as Hidden Primary SHOULD drop any DNS queries from the home > network. > > NEW: > > The HNA, as Hidden Primary SHOULD drop any DNS queries from the home > network -- as opposed to return DNS errors. > > > > The second SHOULD has been changed to : > > > > OLD: > > The HNA SHOULD drop any packets arriving on the WAN interface that are not > issued from the DM. > > > > NEW: > > The HNA SHOULD drop any packets arriving on the WAN interface that are not > issued from the DM -- as opposed to server as an Homenet Authoritative > Server exposed on the Internet. > > ### Section 9, reverse zone > > > > In `it is RECOMMENDED that only the newly reachable IP addresses be > published`, what is the recommendation for the reverse zone(s) ? > > > > As the HNA does not really own the reverse zone, once the IP address is > not valid anymore, the HNA is expected to have no control over the reverse > zone. As a result, I do not see any action to be done by the HNA for the > reverse zone. > > > > That said, we can probably detail this a bit. The added text is as follows: > > Regarding the Homenet Reverse Zone, the new Homenet Reverse Zone has to > be populat > ed as soon as possible, and the old Homenet Reverse Zone will be deleted > by the ow > ner of the zone (and the owner of the old prefix which is usually the ISP) > once th > e prefix is no longer assigned to the HNA. The ISP SHOULD ensure that the > DNS cach > e has expired before re-assigning the prefix to a new home network. This > may be en > forced by controlling the TTL values. > > ### Section 10 > > > > Suggest moving section 10 as a sub-section of section 11. > > > > ### Section 10 > > > > No clue of to understand: > > ``` > > For instance, an adult child checking on the > > state of a home automation system for a parent. > > ``` > > > > *I need to check * this with my co-authors. > > > > ### Section 11.2 > > > > Should temporary IPv6 addresses be mentioned as well ? > > > > We have added some text and the current paragraph looks like this: > > > > IP addresses may be used to locate a device, a host or a service. > > However, home networks are not expected to be assigned a time invariant > prefix by ISPs. In addition IPv6 enables temporary addresses that makes > them even more volatile {{!RFC8981}}. > > ### Section 11.4 > > > > Please rename this section to something else as it is not the usual > 'operational considerations' section. > > > > changed to deployment considerations > > ### Appendix A > > > > ``` > > In the case of the reverse zone, the DOI authenticates the source of > > the updates by IPv6 Access Control Lists. > > ``` > > DOI or DM ? > > > > The DM is part of the DOI, so that will not become fundamentally wrong. > The reason we keep DOI is that the DM is essentially focused on DNS aspects > while authentication is likely to be defer to a dedicated function > different from the DOI. I tend to refer DOI. > > > > ### Appendix A.1 > > > > s/2001:db8:aeae:0001::2/2001:db8:aeae:1::2/ > > > > Does this mean 2 control channels (one for WAN and one for inside LAN) ? > > > > I think this is just one IP of the network. We probably did not take :2 as > something generic as opposed to :1 or :0, but I am happy to hear what seems > to you a better choice. > > Unsure whether the following is true: > > ``` > > With IPv6, the domain space for IP addresses is so large that reverse > > zone may be confronted with scalability issues. > > ``` > > > > The reverse zone associated to ::/64 can be non trivial to manage > especially when very few IPs are effectively being used. I suspect the > wording is unclear and propose to replace it as follows: > > With IPv6, the reverse domain space for IP addresses associated to > a subnet such as ::/64 is so large that reverse zone may be confronted with > scalability issues. > > > > ### Appendix A.2 > > > > s/RG router/CPE/ > > > > ok > > ### Appendix B > > > > Is not normative, then is it useful ? > > > > What is 'front-end protocol' ? > > > > The front end protocol is the legacy name for the protocol described in > this document. I think the section gives a good sense of how the HNA needs > to be provisioned and configured, s I think that is important to have such > a section. > > > > ### Appendix B.1 > > > > Hmm a little unclear at first sight whether this section is explaining the > parameters of appendix B. > > agree the twp sections have been merged. > > > > ### Appendix C > > > > Even if not normative, use cases are often described in the introduction > section. Consider moving this appendix in section 1. > > > > moved as section 1.3 > > > > ## NITS > > > > ### Abstract & section 1 > > > > s/needs/need/ > > > > ok > > ### Section 1.1 > > > > s/home network administrator (a human), will be presented with a list/home > network administrator, (a human being), will be presented with a list/ ? > > > > ok > > ### Section 1.2 > > > > s/For a very few number/For a very few numbers/ ? > > ok > > > > ### Section 4.2 > > > > `so the that DOI`? how to parse this ? > > changed to: so the DOI > > > > ### No comma before 'and' > > > > AFAIK, there is no comma before 'and', exception made for the Oxford comma > of course. > > > > ok - works for me. > > ### Section 4.2 > > > > s/were/was/ ? > > > > I cannot find it in section 4.2 it might have been changed addressing a > previous comment. > > ### Section 4.5 > > > > s/long term session/long-term session/ > > > > ok > > ### Section 4.6 > > > > Unbalanced parenthesis. > > > > ok > > ### Section 4.7 > > > > s/describe din/described in/ > > ok > > > > ### Section 5 > > > > Duplicate `toward a service a service` > > > > ok > > ### Section 6 > > > > s/is outside/are outside/ ? > > > > ok > > ### Non-empty well-known > > > > Several missing '-' in 'non-empty' and 'well-known' (when applicable). > > > > ok > > ### E.g. > > > > "E.g." should be enclosed in ','. > > > > ok > > ### Section 9 > > > > 'by by' ? > > ok > > > > ### Section 10 > > > > s/privacy MAY be provide/privacy MAY be provided/ > > > > ok > > ### Section 11.1 > > > > `To ensure the multiple TLS session are are continuously authenticating ` > duplicated 'are' > > ok > > > > s/This MAY Be handle by a off-line /This MAY be handled by an off-line/ > > > > ok > > ### DNS in uppercase > > > > There are a couple of 'dns' (lowercase) instances. > > > > ok > > ## 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 > > > > > -- > > Daniel Migault > > Ericsson > > > > > -- > > Daniel Migault > > Ericsson > -- Daniel Migault Ericsson
_______________________________________________ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet