Thank you (!) Mikael for the thorough review. The intent is to have it be as complete a document with ‘rough concensus’ to overall security considerations so your comments below are exactly what we are looking for. Even during a last call.
For group overall - I have privately sent the last call info to 6 operational folks I know who don’t typically follow IETF lists and asked for a thorough review. I know, shocking :) I had sent the list to co-authors so they were aware. I’ll work with co-authors to also see how best to capture all comments and get them resolved with ‘group concensus’. - merike > On Apr 19, 2017, at 8:26 AM, Mikael Abrahamsson <[email protected]> wrote: > > On Wed, 12 Apr 2017, Gunter Van De Velde wrote: > >> This is to open a two week WGLC for >> https://tools.ietf.org/html/draft-ietf-opsec-v6. >> If you have not read it, please do so now. You may send nits to the author, >> but substantive discussion should go to the list. >> >> I will close the call on 26 April 2017 > > Hi, > > I went through -11. Reading it and commenting as if I never read it before > (which I don't remember doing, but since I am mentioned in the > acknowledgement section I must have :) ) > > 2.1.2. I would like to see the last paragraph moved to first in this section, > ie have the IETF recommendation start this off, not finish it. > > Somewhere in 2.1.x, can we have a note about the /64 per host as a means of > tracking devices instead of having to track individual addresses? > > 2.3.1. I keep hearing people talk about SeND. The paragraph rightly ends with > with "SeND isn't widely available in implementations". Can we start off with > that? Also potentially move the whole SeND section to later in 2.3.x so that > the actually useful protocols come first? > > 2.4.x. Should this document have all this text on router security? Does this > text say anything in opposition to RFC6192 that it starts off with a > reference to? > > 2.6.x. This document has 0 mentions of the word "YANG" or "NETCONF". I think > it should contain more such references. For instance, 2.6.1.4 mentions using > CLI tools to dump ND table. There is a YANG model for that. > > 2.6.1.4. Here is one example where /64 per host and only tracking that, would > be useful approach. > > 2.6.1.5. Option 37 would be one way to keep track of DHCPv6 IA_NA and where > they are. I don't think if that's implied in the 6221 5.3.2 reference? > > 2.6.2.3 This is one of a few "..." in there. Is that really what we want in a > finished RFC? > > 2.7. "Some text"? > > 2.7.2. Blocking all tunnels? What's the recommendation here? "...it could be > helpful to block all default configuration tunnels"? > > 2.7.2.x. I've seen advice that if you can, disable ISATAP, 6to4 and TEREDO on > all your enterprise machines (where you can, this was specifically for > enterprise Windows deployments). Shouldn't we mention this here? Unless you > know that you need it, turn it off? Or if there is a document somewhere > talking about this, reference it? > > 2.7.2.4. I'd like to start this with the fact that anycast 6to4 has been > deprecated. > > > This document is a nice overview of a lot of topics, it contains lots of good > links to documents that are good for reader to know. I actually think this is > the best feature of this document, ie that it overviews a lot of different > topics and gives the reader ideas for further reading. However, reading the > document it felt a bit like there was a bit more work needed. It's 95% there, > but I think there are more things that needs discussion. I also think this > document needs wider review. Notifying 6man and v6ops was a good thing. It > seems there have been more discussion there than here in OPSEC, but I think > the authors follow those groups as well. > > So my comment for this in WGLC is that I would like to have more people look > at the document and I think we need a few more revisions before it's ready > for publication. Overall, I think this document contains valuable information > and after some more review and discussion I definitely would like to see it > published. > > > > -- > Mikael Abrahamsson email: > [email protected]_______________________________________________ > OPSEC mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/opsec
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ OPSEC mailing list [email protected] https://www.ietf.org/mailman/listinfo/opsec
