Hi Anthony, Thanks for the response and the multiple reviews. These reviews have been useful and in general I am happy with what we received from the various directorates - so thanks for the extra work.
Yours, Daniel On Thu, Feb 9, 2023 at 5:31 AM Anthony Somerset <anthony.somer...@liquid.tech> wrote: > Hi Daniel > > > > I am happy with the proposed rewording of DDoS attack surface – this at > least remains accurate to what is taking place. > > > > Thanks > > > > Anthony > > > > *From: *Daniel Migault <mglt.i...@gmail.com> > *Date: *Wednesday, 08 February 2023 at 17:36 > *To: *Anthony Somerset <anthony.somer...@liquid.tech> > *Cc: *dns...@ietf.org <dns...@ietf.org>, > draft-ietf-homenet-front-end-naming-delegation....@ietf.org < > draft-ietf-homenet-front-end-naming-delegation....@ietf.org>, > homenet@ietf.org <homenet@ietf.org>, last-c...@ietf.org < > last-c...@ietf.org> > *Subject: *Re: [homenet] Dnsdir last call review of > draft-ietf-homenet-front-end-naming-delegation-26 > > CAUTION: This email has originated from a free email service commonly used > for personal email services, please be guided accordingly especially if > this email is asking to click links or share information. > > > > Hi Anthony, > > > > Thanks for the review. Please find below how we intend to address your > comments. > > > > Yours, > Daniel > > > > On Tue, Jan 31, 2023 at 12:32 PM Anthony Somerset via Datatracker < > nore...@ietf.org> wrote: > > Reviewer: Anthony Somerset > Review result: Ready with Issues > > Hello > > I have been selected as the DNS Directorate reviewer for this draft. The > DNS Directorate seeks to review all DNS or DNS-related drafts as > they pass through IETF last call and IESG review, and sometimes on special > request. The purpose of the review is to provide assistance to the ADs. > For more information about the DNS Directorate, please see > https://wiki.ietf.org/en/group/dnsdir > > There are are clear and direct references to various DNS RFC's and this > draft is not in any major conflict with the wider DNS space but the > following specific suggestions relating to DNS are made. > > I previously Reviewed Version 18 of this draft and am re-rereviewing in > line with the comments I made in that review - > > https://datatracker.ietf.org/doc/review-ietf-homenet-front-end-naming-delegation-18-dnsdir-telechat-somerset-2022-10-12/ > > Having re-read the new version a few times, and keeping track of the > various > reviews as not to duplicate reports for same issues i will try not say the > same > things again. > > I specifically note that Geoff has done a very definitive review of > version 25 > of the document and i won't repeat those comments in this review but > suffice > to say i do concur with the assessment of the situation in his review and > agree with the position of Ready with Issues as well > > I am happy with the large effort to reflow the document - it does now read > in a > more sensible order and helps with clarity. > > I am also happy with the additional security considerations that make > sense. > > Major Issues: None > > Minor Issues: > > Section 2 - Public Authoritative Servers - my original NIT was dealt with > but I > note that anycast is now referenced here which is still extraneous, we are > not > attempting to deal with the standard of how Public Authoritative Servers be > managed operationally > > > > I agree that we are not concerned on how the Public Authoritative Servers > are managed. I suppose the comment is concerning the following sentence. > > If that the case, I am not reading any suggestion on how these servers are > operated. Our main purpose here is to make sure the reader understands > which servers we are talking about. This is the sense of the sentence: "are > often implemented in an anycast fashion.". I propose to leave the text as > it, but remain open to changes if I am missing something. > > """ > > are the authoritative name servers for > the Public Homenet Zone. Name resolution requests for the > Registered Homenet Domain are sent to these servers. Some DNS > operators would refer to these as public secondaries, and for > higher resiliency networks, are often implemented in an anycast > fashion. > > """ > > > > > Section 3 - now Section 5 - i note specifically the comment about: > > "In the case the HNA is a CPE, outsourcing to the DOI protects the home > network > against DDoS for example." > > I personally would consider this a dangerously inaccurate statement. > > This offers NO protection against a DDoS, at best it (only) slightly > reduces > the attack surface exposed but it provides no meaningful additional > protection. > > I specifically repeat this and recommend the statement be removed or > re-worded > appropriately > > I see your point. > > I propose to replace: > > OLD: > > """ > > In the case the HNA is a CPE, outsourcing to the DOI protects the home > network against DDoS for example. > """ > > by NEW: > > """ > > In the case the HNA is a CPE, outsourcing to the DOI reduces the attack > surface of the home network to DDoS for example. > > """ > > > > I assume the nit mentioned below have been addressed previously. In other > words, no action is expected. > > > > Section 3.2 - Original NIT dealt with > > 1.1 - now 3 - NIT dealt with > > 3.1 now 5.1 - Typo fixed > > 4.5.1 - now 6.5.1 - i believe this NIT to be well addressed now, the > reflowing > of the document definitely helps here. > > Thanks > > > > _______________________________________________ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet > > > > > -- > > Daniel Migault > > Ericsson > This email disclaimer applies to the original email, all attachments and > any subsequent emails sent by Liquid Telecom. This email contains valuable > business information that is privileged, confidential and/or otherwise > protected from disclosure, intended only for the named person or entity to > which it is addressed. If you are not the intended recipient of this email > and you received this e-mail in error, any review, use, dissemination, > distribution, printing or copying of this e-mail is strictly prohibited and > may be unlawful and/or an infringement of copyright. Please notify us > immediately of the error and permanently delete the email from your system, > retaining no copies in any media. No employee or agent is authorized to > conclude any binding agreement on behalf of Liquid Telecom with another > party or give any warranty by email without the express written > confirmation by an authorized representative or a director of Liquid > Telecom. Nothing in this email shall be construed as a legally binding > agreement or warranty or an offer to contract. Liquid Telecom will not be > responsible for any damages suffered by the recipient as a result of the > recipient not taking cognizance of this principle. Liquid Telecom accepts > no liability of whatever nature for any loss, liability, damage or expense > resulting directly or indirectly from the access of any files which are > attached to this message. Any email addressed to Liquid Telecom shall only > be deemed to have been received once receipt is confirmed by Liquid Telecom > orally or in writing. An automated acknowledgment of receipt will not > suffice as proof of receipt by the Liquid Telecom. This email disclaimer > shall be governed by the laws of South Africa. > > Internal All Employees > -- Daniel Migault Ericsson
_______________________________________________ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
