[Gen-art] Genart last call review of draft-cheshire-sudn-ipv4only-dot-arpa-15

[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-cheshire-sudn-ipv4only-dot-arpa-??
Reviewer: Erik Kline
Review Date: 2020-02-17
IETF LC End Date: 2020-02-17
IESG Telechat date: Not scheduled for a telechat

Summary:

Are any of the recommendations for client resolvers in this document
covered the IPR (https://datatracker.ietf.org/ipr/3077/) claimed for:

https://tools.ietf.org/html/rfc8305#section-7

(which has some similar/related recommendations, especially 7.3)?

Otherwise, I think this is basically ready, with just a few random nits
noted below (and ignoring the jeremiad-esque tone about the
design/implications of the middlebox protocol nature of RFC 7050 ;-).

Major issues:

Minor issues:

Nits/editorial comments:

[ abstract ]
* 3rd para could be removed for brevity (but keep same in the intro)

[ 4.1 ]

* Consider whether to including references to 1.1, 8.8, and 9.9
  services.  I think the following might suffice:

1.1.1.1  https://1.1.1.1
8.8.8.8  https://developers.google.com/speed/public-dns/
9.9.9.9  https://quad9.net/

* s/is is/it is/

[ 6 ]
I'm not sure I follow the logic about whether/why ipv4only.arpa
must not be a signed zone.  It seems to me that the concluding
paragraph beginning with 'Consequently, ...' actually lays out
the rationale in the most straightforward manner in this section.

It's a nice TL;DR, but I'm not sure how to formulate a useful
recommendation for reflowing text to better highlight this.

[ 8.1 ]
Consider referring to RFC 8499 for DNS terminology, if that improves
the descriptions of types of resolvers.


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

[Gen-art] Genart telechat review of draft-ietf-bfd-vxlan-09

[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 wait for direction from your
document shepherd or AD before posting a new version of the draft.

For more information, please see the FAQ at

.

Document: draft-ietf-bfd-vxlan-??
Reviewer: Erik Kline
Review Date: 2019-12-16
IETF LC End Date: None
IESG Telechat date: 2019-12-19

Summary:

-09 addresses my concerns from -07.  Thank you for this.

The one "nit" is that it seems to have introduced a recommendation to use
:::7f00:0/104 as an IPv6 loopback prefix.  (a) This document should follow
the format recommendations of RFC 5952 section 4.3 and lowercase the "F"s.  But
(b) more importantly, I'm not sure how implementations may treats this space.

The use of an RFC4291 section-2.5.5.2 mapped v4 address doesn't necessarily
make the packet a part of an IPv6 connection.  Nevertheless, I'm not sure I
have a strong feeling about this as it may still exercise enough of the IPv6
stack in a VTEP.

I definitely do think that in the case of BFD on the management VNI targeting
an IPv6 link-local address of the VTEP would be better.  However, I expect that
if :::127.0.0.0 does prove to have some issues in the future a -bis can be
written quickly with a recommendation.

Also, Suresh may have ideas for a solution.

Major issues:

Minor issues:

Nits/editorial comments:


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

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

[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

[Gen-art] Genart last call review of draft-ietf-httpbis-http2-tls13-02

[Erik Kline via Datatracker]

Reviewer: Erik Kline
Review result: Ready

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-httpbis-http2-tls13-??
Reviewer: Erik Kline
Review Date: 2019-10-12
IETF LC End Date: 2019-10-11
IESG Telechat date: 2019-10-17

Summary:  LGTM; ready.

Major issues:  none

Minor issues:  none

Nits/editorial comments:  none


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

[Gen-art] Genart last call review of draft-ietf-pce-stateful-pce-auto-bandwidth-10

[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-pce-stateful-pce-auto-bandwidth-10
Reviewer: Erik Kline
Review Date: 2019-08-27
IETF LC End Date: 2019-08-28
IESG Telechat date: Not scheduled for a telechat

Summary:

Gentle reminder for the authors to double-check all the lower case "should"s,
"required"s, and "must not"s (etc) to make sure it's not important that they be
capitalized (since the case-sensitive requirements text is referenced).

Major issues:

Minor issues:

Nits/editorial comments:

There are some periodic grammatical changes that I think would be nice, but I
assume that can get sorted out with the RFC editor.

Two random things I'll note:

Section 1> I can't find "Path Control Element" in RFC 5440. Should this be
"Path Computation Element"?

Section 5.2>
.  s/speaker wish to disable/speaker wishes to disable/
.  s/of same type/of the same type/

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

[Gen-art] Genart last call review of draft-ietf-ospf-yang-23

[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-ospf-yang-??
Reviewer: Erik Kline
Review Date: 2019-07-17
IETF LC End Date: 2019-07-17
IESG Telechat date: Not scheduled for a telechat

Summary:

Major issues:

Minor issues:

I feel like the "version" text in 2.3 was confusing.  The first thing I did was
glance back up the overview where I (a) didn't see "version" mentioned and (b)
initially thought that "af" was maybe a proxy for "version".

But then later on it seems that "version" is only a mandatory property of the
LSA.

I'm not sure that I have concretely useful suggestions for improving this text,
and in fact it might well be that for expected readers of the document this is
in fact a non-issue.  Just thought I'd relay my experience.

Nits/editorial comments:

Page 25: NMDA RFC is 8342, not 8242.

Page 81: references draft-ietf-bdf-yang-xx.txt. This is referenced
elsewhere in the doc (correctly), so I think just remove the -xx may
be fine?

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

[Gen-art] Genart last call review of draft-ietf-bfd-vxlan-07

[Erik Kline via Datatracker]

Reviewer: Erik Kline
Review result: On the Right Track

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-bfd-vxlan-07
Reviewer: Erik Kline
Review Date: 2019-05-27
IETF LC End Date: 2019-05-31
IESG Telechat date: Not scheduled for a telechat

Summary:

If my understanding is correct (which it may well not be), this document
places restrictions on the inner Ethernet and IP layer deployment that
previously may not have been present.

My reading if this document is that the outer IP header and the inner IP
header have the same VTEP src and dst IPs.  The outer and inner Ethernet
headers have the same source MAC and may have the same dst MAC. Is this
correct?

If so, this would mean that the VTEP's MAC address (or the special dest MAC)
cannot be used within the VXLAN network (or at least not on the same host.
Similarly, it appears that the VTEP's IP addresses are no longer free to
be used within the encapsulated VXLAN VNI. Do I understand this correctly?
Was this always the case?

If there is a document defining restrictions that VTEPs place on the
inner VXLAN segment, that might be good to reference.

Failing that, I think I would like to see some discussion of alternatives
that were rejected with reasons behind their rejection.

One possible solution might be to use "impossible" Ethernet addresses and
"impossible" IP addresses in the inner packet.  For example, a source
IP address of all ones or all zeros would be very unlikely to ever be a
valid IP packet.  I'm not 100% sure, but I suspect that a source MAC of
all ones would also never really be treated as valid.  Clever use of
multicast IP and Ethernet addresses in the source fields might also be
sufficient to render the inner packet "invalid" in the sense that it would
never collide with legitimate traffic.

If I have misread this document, or VTEPs are already placing constraints
on the inner VXLAN environment similar to those above, then this review
should instead be treated as "Ready with Nits".

Major issues:

Only my concern/misunderstanding described above.

Minor issues:

None.

Nits/editorial comments:

* The document generally does a really good job of Expanding Acronyms
  At First Use (EAAFU) -- very much appreciated. In section 1 though,
  NVE is used without accompanying expansion, I think.

* There is no 4.2 so maybe sections 4 and 4.1 could just be section 4.


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

[Gen-art] Genart last call review of draft-ietf-isis-segment-routing-extensions-23

[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-isis-segment-routing-extensions-??
Reviewer: Erik Kline
Review Date: 2019-04-17
IETF LC End Date: 2019-04-17
IESG Telechat date: Not scheduled for a telechat

Summary:

For what little I know of IS-IS and segment routing, this all seems to make
general sense.  I simply had some language/style nits (below).

Major issues:

Minor issues:

Nits/editorial comments:

# Section 1

* "SR's control-plane can be applied ..., and do not require...".  It looks
like the subject of the sentence is "control-plane" and so perhaps "do not"
should be "does not".

* s/draft/document/g

# Section 2.1

* "Algorithms identifiers" -> "Algorithm identifiers"

# Section 2.2.2

* Length: variable

Should this say "11-12" (1 + 1 + 6 + 3-4)?

* "set of Adj-SID each router" -> "set of Adj-SIDs each router", perhaps.

# Section 2.3

s/valu eis/value is/

# Section 2.4

Silly, naive question: does the length include the sum of the octets
representing the sub-TLVs?

# Section 2.4.6

In example 3, I would recommend s/0xD/0x0D/ & s/0x0/0x00/ & s/0x1/0x01/ ,
but perhaps that's just a personal readability thing.

# Section 3.3

* "by other components than" -> "by components other than", perhaps.

* "to know what are the local SIDs" -> "to know what the local SIDs are",
  perhaps.

* "The SRLB sub-TLV is used for this purpose...", (instead of "that purpose")
maybe.

* "which mechanisms are outside" -> "which are outside", maybe.

* "the SRLB TLV" -> "the SRLB sub-TLV", I think.


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