Re: [Gen-art] Genart last call review of draft-ietf-opsec-v6-21

2021-02-08 Thread Eric Vyncke (evyncke) 
Hello Erik,

Revision -23 (soon to be published) should incorporate the remaining issues 
(most of the previous ones were fixed in the just released -22). See EV23>

Thank you again for your valuable review

-éric

-Original Message-
From: Eric Vyncke 
Date: Saturday, 14 December 2019 at 22:22
To: Erik Kline , "gen-art@ietf.org" 
Cc: "last-c...@ietf.org" , "op...@ietf.org" 
, "draft-ietf-opsec-v6@ietf.org" 

Subject: Re: Genart last call review of draft-ietf-opsec-v6-21
Resent-From: 
Resent-To: Eric Vyncke , Kiran Kumar Chittimaneni 
, Merike Kaeo , 
, Ron Bonica , , Ignas 
Badonas , , Gyan Mishra 
, 
Resent-Date: Saturday, 14 December 2019 at 22:22

Hello Erik

Thank you again for the review. We have accepted all your nits except those 
below (see EV>). They will appear in revision -22

Regards

-éric (the other one)

On 02/12/2019, 17:24, "Erik Kline via Datatracker"  wrote:

- It's not clear if RFC 2119 text is needed for this document as it is 
now.

EV> it does IMHO as we have some cut of text from RFC having those 
words.


EV23> thinking twice, completely removed now

- 2.1.5

- Could perhaps more explicitly state that DHCPv6 is not mandatory
  to implement per IPv6 Node Requirements (RFC 8504).

EV23> text added

- 2.2

- One might quibble with the statement "the extension header chain
  must be be parsed completely".  It has to be parsed enough so that
  it can be completely traversed, but it need not necessarily be
  parsed in a way that a node has to "understand" the contents --
  this is how the extension headers are designed, after all.

EV23> text modified into " the extension header chain must be parsed completely 
(even if not processed)", I hope that it is clearer now

- 2.4.2

- With the mention of NTP I suddenly thought: should there be
  DNS-related text as well, or does that fall within this section 
too?

EV> as we mention protocols used by the routers, I would say that DNS is 
not really required & relied upon by routers (albeit often use), I would assume 
that DNS is simply included in the '...'

- 2.5.3

- The CYMRU link doesn't seem to go to a useful page anymore.  :-/

EV> indeed, it looks like CYMRU has become a commercial company :-( unable 
to find the previous document :-( removed all links

EV23> found back a CYMRU page that is now also used for bogons




___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

Re: [Gen-art] Genart last call review of draft-ietf-opsec-v6-21

2019-12-14 Thread Eric Vyncke (evyncke) 
Hello Erik

Thank you again for the review. We have accepted all your nits except those 
below (see EV>). They will appear in revision -22

Regards

-éric (the other one)

On 02/12/2019, 17:24, "Erik Kline via Datatracker"  wrote:

- It's not clear if RFC 2119 text is needed for this document as it is now.
 
EV> it does IMHO as we have some cut of text from RFC having those words.

- 2.1.5

- Could perhaps more explicitly state that DHCPv6 is not mandatory
  to implement per IPv6 Node Requirements (RFC 8504).

EV> I would prefer not to mention it in the sake of brevity. DHCPv4 is also not 
mandated for IPv4.


- 2.4.2

- With the mention of NTP I suddenly thought: should there be
  DNS-related text as well, or does that fall within this section too?

EV> as we mention protocols used by the routers, I would say that DNS is not 
really required & relied upon by routers (albeit often use), I would assume 
that DNS is simply included in the '...'

- 2.5.3

- The CYMRU link doesn't seem to go to a useful page anymore.  :-/

EV> indeed, it looks like CYMRU has become a commercial company :-( unable to 
find the previous document :-( removed all links



___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

Re: [Gen-art] Genart last call review of draft-ietf-opsec-v6-21

2019-12-03 Thread Eric Vyncke (evyncke) 
Thank you Erik for the extended review. The authors will fix the nits and 
clarify the text

-éric

On 03/12/2019, 02:24, "Erik Kline via Datatracker"  wrote:

Reviewer: Erik Kline
Review result: Ready with Nits

I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair.  Please treat these comments just
like any other last call comments.

For more information, please see the FAQ at

.

Document: draft-ietf-opsec-v6-21
Reviewer: Erik Kline
Review Date: 2019-12-02
IETF LC End Date: 2019-12-02
IESG Telechat date: Not scheduled for a telechat

Summary:

This is very large survey of applicable security text and RFCs.  I think 
it's a
good entry point for an operator starting out.

I captured lots of nits, but most of them are extremely minor wording 
questions.

Major issues:

Minor issues:

Nits/editorial comments:

- in general

- Several links that are meant to be other_rfc#section_X.Y.Z render
  instead as this_document#section_X.Y.Z (in the tools.ietf.org
  rendering).

- Abstract

? "several places of a network" -->
  "several types of networks"
? "procedural mitigations techniques" -->
  "procedural mitigation techniques"

- It's not clear if RFC 2119 text is needed for this document as it is now.

- 2.1

? "abundance of address space available" -->
  "abundance of address space is available"

- 2.1.5

- Could perhaps more explicitly state that DHCPv6 is not mandatory
  to implement per IPv6 Node Requirements (RFC 8504).

- 2.1.6

? "are specific consideration" -->
  "are specific considerations"

- 2.2

- One might quibble with the statement "the extension header chain
  must be be parsed completely".  It has to be parsed enough so that
  it can be completely traversed, but it need not necessarily be
  parsed in a way that a node has to "understand" the contents --
  this is how the extension headers are designed, after all.

  Regrettably, no better wording comes to mind, so I have no specific
  recommendation for what could be done here.

- 2.3.2

? "either intentional or malicious" -->
  "either unintentional or malicios" (not quite sure)

- This section could have a callback to 2.1.7 as a possible solution
  (toward the end, where it talks about host isolation) as this can
  also solve these problems.  (A forward link to 2.3.4 might be good
  too, since this is philosophically similar.)

- 2.4

? "number of Dijsktra execution" -->
  "number of Dijsktra executions"

- 2.4.1

? "configured such as" -->
  "configured so as to"

- 2.4.2

- With the mention of NTP I suddenly thought: should there be
  DNS-related text as well, or does that fall within this section too?

- 2.4.3

? "Both the save" -->
  "Both to spare"

- 2.5.3

- The CYMRU link doesn't seem to go to a useful page anymore.  :-/

- 2.6

- SNMP is mentioned (eslewhere too).  Should YANG/NETCONF/RESTCONF
  also get a gratuitous reference?

- Same question for DIAMETER vis a vis RADIUS.

- 2.6.1.5

? "operation security" -->
  "operational security"

- 2.6.2.2

? "in some case" -->
  "in some cases"

? "can sometime be" -->
  "can sometimes be"

- 2.6.2.3

- Even though section 2.6.1.1 already references RFC 5952 as the
  current recommended canonical string format, this section could
  link to it as well (just in case a reader has followed a deep link
  into this section and hasn't read anything else).

- 2.7.1

- Perhaps "you have twice" --> "the network operator has twice".

? "more relax security" -->
  "more relaxed security"

- 2.7.2

? "no more automated in most environment" -->
  "no longer automatic in most environments"

- 2.7.2.7

? "is no more used by" -->
  "is no longer used by"

- 2.7.2.8

- If UDP filtering guidelines are to be listed here (even
  parenthetically), you might include UDP 443 for QUIC, 500 for IKE,
  and 3478 for STUN.  Maybe just replace "block all" with something
  like "filter all judiciously" or something.

? "no more enabled" -->
  "no longer enabled"

- 2.7.3.1

? "and

[Gen-art] Genart last call review of draft-ietf-opsec-v6-21

2019-12-02 Thread Erik Kline via Datatracker 
Reviewer: Erik Kline
Review result: Ready with Nits

I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair.  Please treat these comments just
like any other last call comments.

For more information, please see the FAQ at

.

Document: draft-ietf-opsec-v6-21
Reviewer: Erik Kline
Review Date: 2019-12-02
IETF LC End Date: 2019-12-02
IESG Telechat date: Not scheduled for a telechat

Summary:

This is very large survey of applicable security text and RFCs.  I think it's a
good entry point for an operator starting out.

I captured lots of nits, but most of them are extremely minor wording questions.

Major issues:

Minor issues:

Nits/editorial comments:

- in general

- Several links that are meant to be other_rfc#section_X.Y.Z render
  instead as this_document#section_X.Y.Z (in the tools.ietf.org
  rendering).

- Abstract

? "several places of a network" -->
  "several types of networks"
? "procedural mitigations techniques" -->
  "procedural mitigation techniques"

- It's not clear if RFC 2119 text is needed for this document as it is now.

- 2.1

? "abundance of address space available" -->
  "abundance of address space is available"

- 2.1.5

- Could perhaps more explicitly state that DHCPv6 is not mandatory
  to implement per IPv6 Node Requirements (RFC 8504).

- 2.1.6

? "are specific consideration" -->
  "are specific considerations"

- 2.2

- One might quibble with the statement "the extension header chain
  must be be parsed completely".  It has to be parsed enough so that
  it can be completely traversed, but it need not necessarily be
  parsed in a way that a node has to "understand" the contents --
  this is how the extension headers are designed, after all.

  Regrettably, no better wording comes to mind, so I have no specific
  recommendation for what could be done here.

- 2.3.2

? "either intentional or malicious" -->
  "either unintentional or malicios" (not quite sure)

- This section could have a callback to 2.1.7 as a possible solution
  (toward the end, where it talks about host isolation) as this can
  also solve these problems.  (A forward link to 2.3.4 might be good
  too, since this is philosophically similar.)

- 2.4

? "number of Dijsktra execution" -->
  "number of Dijsktra executions"

- 2.4.1

? "configured such as" -->
  "configured so as to"

- 2.4.2

- With the mention of NTP I suddenly thought: should there be
  DNS-related text as well, or does that fall within this section too?

- 2.4.3

? "Both the save" -->
  "Both to spare"

- 2.5.3

- The CYMRU link doesn't seem to go to a useful page anymore.  :-/

- 2.6

- SNMP is mentioned (eslewhere too).  Should YANG/NETCONF/RESTCONF
  also get a gratuitous reference?

- Same question for DIAMETER vis a vis RADIUS.

- 2.6.1.5

? "operation security" -->
  "operational security"

- 2.6.2.2

? "in some case" -->
  "in some cases"

? "can sometime be" -->
  "can sometimes be"

- 2.6.2.3

- Even though section 2.6.1.1 already references RFC 5952 as the
  current recommended canonical string format, this section could
  link to it as well (just in case a reader has followed a deep link
  into this section and hasn't read anything else).

- 2.7.1

- Perhaps "you have twice" --> "the network operator has twice".

? "more relax security" -->
  "more relaxed security"

- 2.7.2

? "no more automated in most environment" -->
  "no longer automatic in most environments"

- 2.7.2.7

? "is no more used by" -->
  "is no longer used by"

- 2.7.2.8

- If UDP filtering guidelines are to be listed here (even
  parenthetically), you might include UDP 443 for QUIC, 500 for IKE,
  and 3478 for STUN.  Maybe just replace "block all" with something
  like "filter all judiciously" or something.

? "no more enabled" -->
  "no longer enabled"

- 2.7.3.1

? "and effective" -->
  "an effective"

- 3.2

? "IPv6-in-IP4" -->
  "IPv6-in-IPv4"

- There appears to be a broken internal reference to, I presume,
  section 2.8?

? "using IP4" -->
  "using IPv4"

- Since this section mentions filtering at the Internet connection,
  should it also have a reference to BCPs 38 and 84, for good measure?
  It is slightly different, so you might deem it unrelated.

- 4.2

? "coexistence i" -->
  "coexistence section"

- 4.3

? "powers up" -->
  "establishes a data connection" maybe?

- 5

? "have all IPv6 enabled" -->
  "all have IPv6 enabled"

- 6

? "for your convenience" -->
  "for the reader's convenience" maybe?

___
Gen-art mailing list
Gen-art@ietf.org