Thank you. There’s a lot of comments/grammar to make sure we have incorporated (a good thing since we all are grateful for the thorough reviews) and early next week there should be a new version that has incorporated all of the comments made.
- merike > On Dec 9, 2019, at 2:10 PM, Smith, Donald <[email protected]> > wrote: > > Merike, and WG team, I would be willing to review for grammar etc.. if there > is a newer version to review. > > I don't want to step on other's comments/suggestions so … > > if (initial_ttl!=255) then (rfc5082_compliant==0) > [email protected] > > ________________________________________ > From: OPSEC [[email protected]] on behalf of Warren Kumari > [[email protected]] > Sent: Monday, December 09, 2019 2:49 PM > To: Merike Kaeo > Cc: Tim Chown; [email protected]; [email protected]; > [email protected] > Subject: Re: [OPSEC] [Last-Call] Opsdir last call review of > draft-ietf-opsec-v6-21 > > [ - last-call@ flor clutter ] > > Authors, > > Thank you for being diligent in addressing comments -- please SHOUT > LOUDLY once you believe that it is ready for me to progress. > > Thanks! > W > > On Sat, Dec 7, 2019 at 2:26 AM Merike Kaeo > <[email protected]> wrote: >> >> Hello Tim. >> >> We will be reviewing and considering the July 2018 comments from you (and >> Don) along with the other AD review comments from the past few weeks. >> >> - merike >> >>> On Dec 6, 2019, at 8:41 AM, Tim Chown <[email protected]> wrote: >>> >>> Hi, >>> >>> No problem, it’s not a big issue. I must admit I didn’t check at the time >>> for any responses after completing the last review. But now looking back >>> at the opsec archives I don’t see any response to that email (bar a >>> separate comment) nor any changes that I could see to the document as a >>> result. If there is something I missed please do point it out. >>> >>> Anyway, if you can consider those comments when looking at the additional >>> notes in the new review, that would be great. Overall the document is >>> certainly in much better shape than 18 months ago, and very close to being >>> done :) >>> >>> Best wishes, >>> Tim >>> >>>> On 6 Dec 2019, at 16:17, Merike Kaeo <[email protected]> wrote: >>>> >>>> Hi Tim. >>>> >>>> You are someone who has over the years made many substantial >>>> recommendations to this document so I will echo Eric’s comment that if we >>>> did not react to your last review it was a gross oversight. I will look >>>> at my archives since I recall making a concerted effort to make sure we >>>> included all the review comments from 2017/2018 in a version around >>>> October 2018. >>>> >>>> - merike >>>> >>>> >>>>> On Dec 6, 2019, at 6:19 AM, Eric Vyncke (evyncke) <[email protected]> >>>>> wrote: >>>>> >>>>> Tim >>>>> >>>>> Thank you for your additional review. And, I feel really bad if we, the >>>>> authors, have not reacted to your previous review (even if I had in mind >>>>> that we acted on it -- possibly not changing the text to fit completely >>>>> your view) >>>>> >>>>> -éric >>>>> >>>>> On 06/12/2019, 10:34, "Tim Chown via Datatracker" <[email protected]> >>>>> wrote: >>>>> >>>>> Reviewer: Tim Chown >>>>> Review result: Not Ready >>>>> >>>>> I have reviewed this document as part of the Operational directorate's >>>>> ongoing >>>>> effort to review all IETF documents being processed by the IESG. These >>>>> comments were written with the intent of improving the operational >>>>> aspects of >>>>> the IETF drafts. Comments that are not addressed in last call may be >>>>> included >>>>> in AD reviews during the IESG review. Document editors and WG chairs >>>>> should >>>>> treat these comments just like any other last call comments. >>>>> >>>>> This draft analyses operational security issues related to the >>>>> deployment of >>>>> IPv6, and describes appropriate mechanisms and practices to mitigate >>>>> potential >>>>> threats. >>>>> >>>>> I had previously reviewed the draft as an OPS-DIR Early Review in July >>>>> 2018, as >>>>> detailed in >>>>> >>>>> https://imss91-ctp.trendmicro.com:443/wis/clicktime/v1/query?url=https%3a%2f%2fmailarchive.ietf.org%2farch%2fmsg%2fopsec%2f6s%5fYFrXNPwtbQRe62D3%5fAtXb6as&umid=B210175F-994C-6205-A9B8-476D58DC50BF&auth=19120be9529b25014b618505cb01789c5433dae7-c806c2ebb47f1714bad5ce71961b8c07a2b6b345, >>>>> but I >>>>> don’t see any evidence of these comments being acted upon, or any >>>>> response, so >>>>> as far as I can see, the comments in this review still apply, and I >>>>> would urge >>>>> the authors to review these comments. >>>>> >>>>> That said, there have been a number of improvements to the draft in the >>>>> past 18 >>>>> months, and overall it is a much better document for those changes. The >>>>> question is at what point the WG should simply ship the draft as “good >>>>> enough”, >>>>> rather than try to improve it further. >>>>> >>>>> At the moment I think the document is Not Ready, though it’s getting >>>>> nearer to >>>>> being Ready with Nits. >>>>> >>>>> General comments: >>>>> >>>>> There are a number of typos / grammatical errors in the document. While >>>>> the >>>>> RFC Editor will correct, e.g., in the abstract - “mitigations” should be >>>>> singular, in the intro “with that have been”, in 2.1 “of address space >>>>> available” (add “is”), “allow” should be “allows”. Just needs a careful >>>>> proof >>>>> read. >>>>> >>>>> Specific comments: >>>>> >>>>> Abstract: >>>>> >>>>> “places” should be “aspects” or similar. >>>>> >>>>> 2.1.1: >>>>> >>>>> Or for internal communication stability in networks where external >>>>> connectivity >>>>> may came and go, e.g., many ISPs provide ULAs in home networks. >>>>> >>>>> 2.1.5: >>>>> >>>>> This section muddles privacy addresses with stable per-prefix >>>>> identifiers. >>>>> They have different uses, and can be used independently or together. >>>>> >>>>> You say “RFC 8064 specifies a way to”, but I think you should cite RFC >>>>> 7217 as >>>>> the address generation mechanism, and RFC 8064 as the recommendation to >>>>> use >>>>> that, but note that you can still use RFC 4941 addresses alongside RFC >>>>> RFC 7217 >>>>> addresses. >>>>> >>>>> 2.1.6 >>>>> >>>>> As per my previous review I think you should have a section on address >>>>> accountability / auditing, and discuss that for all address assignment >>>>> methods, >>>>> be it DHCPv6 or SLAAC/RFC7217. You say here DHCPv6 is used for audit >>>>> purposes, >>>>> yet later in the doc say there are issues with that approach. >>>>> >>>>> Address accountability is the most common question I get asked when >>>>> speaking to >>>>> universities about IPv6 deployment when there is (dual-stack) >>>>> multi-addressing. >>>>> >>>>> This can be a place to mention DHCPv6 anonymity profiles, but that would >>>>> be >>>>> better in a separate section on address and thus user privacy. >>>>> >>>>> 2.2.4 >>>>> >>>>> As per later in the document, emphasise here that IPSec is optional >>>>> (some still >>>>> have the original IPv6 marketing message in their head…) >>>>> >>>>> 2.3.3 >>>>> >>>>> “his packets” -> “their packets” to be gender neutral. >>>>> >>>>> How widely deployed is SAVI in practice? A comment is rightly made >>>>> about SeND, >>>>> but what about SAVI implementation? >>>>> >>>>> Can also suggest the /64 per host isolation approach here before the “A >>>>> drastic >>>>> technique” paragraph. >>>>> >>>>> 2.6.1.5 >>>>> >>>>> Address accountability appears again here in the 5th paragraph. You can >>>>> get a >>>>> level of accountability from polling network devices where DHCPv6 is not >>>>> used; >>>>> this should be discussed somewhere. >>>>> >>>>> 2.7.1 >>>>> >>>>> Should mention RFC 7123 here, and also in Section 3. >>>>> >>>>> 3.2 >>>>> >>>>> Given you raise VPNs, you should add a note about RFC 7359. >>>>> >>>>> In R&E campus enterprises, eduroam is widely deployed and gives >>>>> accountability >>>>> through federated 802.1x based network access. >>>>> >>>>> 4.3 >>>>> >>>>> You manage to avoid talking about IPv6 NAT until here. Then assume >>>>> there is no >>>>> IPv6 NAT on a CPE. Would it be better to not mention IPv6 NAT at all, >>>>> or dare >>>>> you open that can of very wriggly worms in this document? I imagine the >>>>> IESG >>>>> reviews may ask, given the widely held industry belief that “NAT is added >>>>> security” :). RFC 4864 still has value, but you cite that for a >>>>> different >>>>> reason. >>>>> >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> OPSEC mailing list >>>>> [email protected] >>>>> https://imss91-ctp.trendmicro.com:443/wis/clicktime/v1/query?url=https%3a%2f%2fwww.ietf.org%2fmailman%2flistinfo%2fopsec&umid=B210175F-994C-6205-A9B8-476D58DC50BF&auth=19120be9529b25014b618505cb01789c5433dae7-05c94ff50001b4c4be23be90aa7081dad0210434 >>>>> >>>> >>>> -- >>>> last-call mailing list >>>> [email protected] >>>> https://imss91-ctp.trendmicro.com:443/wis/clicktime/v1/query?url=https%3a%2f%2fwww.ietf.org%2fmailman%2flistinfo%2flast%2dcall&umid=B210175F-994C-6205-A9B8-476D58DC50BF&auth=19120be9529b25014b618505cb01789c5433dae7-b0a078ee876a1cf581929d58486534a30fea6393 >>> >> > > > -- > I don't think the execution is relevant when it was obviously a bad > idea in the first place. > This is like putting rabid weasels in your pants, and later expressing > regret at having chosen those particular rabid weasels and that pair > of pants. > ---maf > > _______________________________________________ > OPSEC mailing list > [email protected] > https://imss91-ctp.trendmicro.com:443/wis/clicktime/v1/query?url=https%3a%2f%2fwww.ietf.org%2fmailman%2flistinfo%2fopsec&umid=B210175F-994C-6205-A9B8-476D58DC50BF&auth=19120be9529b25014b618505cb01789c5433dae7-05c94ff50001b4c4be23be90aa7081dad0210434 > This communication is the property of CenturyLink and may contain > confidential or privileged information. Unauthorized use of this > communication is strictly prohibited and may be unlawful. If you have > received this communication in error, please immediately notify the sender by > reply e-mail and destroy all copies of the communication and any attachments. >
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ OPSEC mailing list [email protected] https://www.ietf.org/mailman/listinfo/opsec
