[OPSAWG] Tsvart last call review of draft-ietf-opsawg-ipfix-tcpo-v6eh-11
Reviewer: Wesley Eddy Review result: Ready This document has been reviewed as part of the transport area review team's ongoing effort to review key IETF documents. These comments were written primarily for the transport area directors, but are copied to the document's authors and WG to allow them to address any issues raised and also to the IETF discussion list for information. When done at the time of IETF Last Call, the authors should consider this review as part of the last-call comments they receive. Please always CC tsv-...@ietf.org if you reply to or forward this review. Thank you for responding to my prior review comments; the latest copy looks fine to me. ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
[OPSAWG] Tsvart early review of draft-ietf-opsawg-ipfix-tcpo-v6eh-05
Reviewer: Wesley Eddy Review result: Ready with Issues Comments: - The document is well-written and easy to read. - Section 6 is really nice and helpful! Issues: - The way an implementation understands the TCP ExIDs may benefit from slightly more explanation: -- In 4.2 and 4.3, is the idea that the implementation is just sampling the 16 or 32 bits following the experimental option kind being indicated, and assuming those 2 or 4 bytes to be ExIDs? From Section 6.2, I got the sense that the implementation is aware of particular ExID values specifically, to know if they should be reported as 2 or 4 byte values. -- Will any values present be reported, or only those which show up in the IANA registry? I assume any values will be reported, even if they are not registered ExIDs, since the registry changes over time, and implementations probably don't grab periodic updates of it. Questions: - This may be alright, but it seemed to me like for interoperability there should be some way to indicate what an implementation of this IE is doing with regard to this text in Section 3.1 (where maybe "may" should be "MAY"?): Several extension header chains may be observed in a Flow. These extension headers may be aggregated in one single ipv6ExtensionHeadersFull Information Element or be exported in separate ipv6ExtensionHeadersFull IEs, one for each extension header chain. - In Section 3.3, it seems backwards to me that this Limit IE being True means that no limitation was applied, whereas False means that it was limited. If the WG and implementers are okay with this, I'm not questioning it, but it seems odd, so I just wanted to make sure this was the intention. Nits: - The first paragraph in section 1 should probably mention the specific RFC(s) for the specified IEs with the noted problems, since it sounds from the beginning paragraphs of section 3 and 4 like some of those are already being addressed by the separate ipfix-fixes document. - Section 1.1, "do no correspond" -> "do not correspond" ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
[alto] Iotdir telechat review of draft-ietf-alto-new-transport-17
Reviewer: Wesley Eddy Review result: Ready with Issues I only found 1 real "issue" in reading this document, and a few smaller nits, described below. None of these comments are specifically related to IoTDIR type of concerns, and it doesn't seem like the protocol would be intended for use in IoT. Issues: 1) The placement of TIPS relative to other ALTO standards is unclear. This became evident to me on page 4, reading the bottom paragraph with "Despite the benefits, however, ...". Is the gist of this paragraph supposed to be that the WG does not think that TIPS should totally replace ALTO/SSE? It's not clear to me what the recommendation or applicability statement for these is in practical terms. The WG should convey more clearly what it believes implemenentations and deployments should be using, under what circumstances. If both protocols are maintained as standards track, then it should be clearly stated why that needs to be the case and that this does not obsolete ALTO/SSE. It seems to be created as another option, with unclear guidance provided to implementers about what to do. Nits: 1) page 4 from "no capability it transmits incremental" to "no capability to transmit incremental" 2) I don't know if this is typical for other ALTO documents, but the usage of the term "transport protocol" in the first paragraph of section 1 is not consistent with the Internet architecture where "transport protocols" are TCP, UDP, SCTP, etc., nor is it "transport" in the sense of MPLS, etc. I would suggest using the alternative term "transfer" to be less jarring. Of course, if this is already the standard terminology for ALTO that the IETF has accepted, then this comment can be ignored. 3) In the section 5.4 example, should "my-networkmap" in some of the "uses" values by "my-network-map" that was defined at the top? ___ alto mailing list alto@ietf.org https://www.ietf.org/mailman/listinfo/alto
[spring] Tsvart last call review of draft-ietf-spring-sr-replication-segment-14
Reviewer: Wesley Eddy Review result: Almost Ready This document has been reviewed as part of the transport area review team's ongoing effort to review key IETF documents. These comments were written primarily for the transport area directors, but are copied to the document's authors and WG to allow them to address any issues raised and also to the IETF discussion list for information. When done at the time of IETF Last Call, the authors should consider this review as part of the last-call comments they receive. Please always CC tsv-...@ietf.org if you reply to or forward this review. (1) Since this defines a behavior where one incoming packet can create N outgoing packets, I was surprised that there is nothing mentioned in the security considerations about how access to replication nodes and ingress for them should be protected in order to prevent abuse. (2) The intended use seems mainly to be where some outer control system is responsible for making sure that the replication operation will put packets onto distinct network paths, and not create congestion either locally or on some potential shared network segment downstream. It might be more clearly stated that it's assumed that building a proper multicast tree, managing group membership, and performing multicast congestion control need to be performed elsewhere. (3) I didn't recognize the syntax or pseudocode conventions in section 2.2.1; maybe this is common or defined somewhere else that could be referenced to be clear? ___ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
[bess] Tsvart last call review of draft-ietf-bess-evpn-lsp-ping-08
Reviewer: Wesley Eddy Review result: Ready This document has been reviewed as part of the transport area review team's ongoing effort to review key IETF documents. These comments were written primarily for the transport area directors, but are copied to the document's authors and WG to allow them to address any issues raised and also to the IETF discussion list for information. When done at the time of IETF Last Call, the authors should consider this review as part of the last-call comments they receive. Please always CC tsv-...@ietf.org if you reply to or forward this review. Some comments: (1) Is there an 'e' missing at the end of this sentence in Section 1?: validate data plane against the control plan. -> validate data plane against the control plane. (2) It seems like some words are missing in this sentence in Section 4.1: The EVPN MAC/IP Sub-TLV identifies the MAC or ARP/ND for an EVPN -> The EVPN MAC/IP Sub-TLV identifies the target MAC address for ARP/ND for an EVPN (3) For IP address used for examples (e.g. in Section 6.1), consider using the documentation prefix (RFC 5737). ___ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
[OPSAWG] Tsvart last call review of draft-ietf-opsawg-vpn-common-09
Reviewer: Wesley Eddy Review result: Ready with Issues This document has been reviewed as part of the transport area review team's ongoing effort to review key IETF documents. These comments were written primarily for the transport area directors, but are copied to the document's authors and WG to allow them to address any issues raised and also to the IETF discussion list for information. When done at the time of IETF Last Call, the authors should consider this review as part of the last-call comments they receive. Please always CC tsv-...@ietf.org if you reply to or forward this review. This document basically looks good to me, though I have a small number of comments: (1) I think this comment impacts only the narrative and not the YANG model itself. The list of possible underlay-transport values seems to be a mixture of expected types of encapsulations, but then a couple of things at the end that are signaling and not encapsulations per-se. The last 2 entries in the list on page 6 are what seem out of place to me - RSVP and BGP. I don't think it's quite correct to refer to these two as the underlay-transport. (2) This is a YANG model question, that I'm unsure of. I want to make sure that in the match-type when match-flow is used that a combination of L3 and L4 attributes can be used. It appears like either L3 or L4 can be indicated, mutually exclusive, but I don't quite understand how it would then be possible to properly represent the combination of IP, transport protocol, and ports that identify a flow. It seems like a list of criteria from both L3 and L4 components is what's needed to express a flow, rather than a choice of L3 or L4. ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
[OPSAWG] Tsvart last call review of draft-ietf-opsawg-vpn-common-06
Reviewer: Wesley Eddy Review result: Almost Ready This document has been reviewed as part of the transport area review team's ongoing effort to review key IETF documents. These comments were written primarily for the transport area directors, but are copied to the document's authors and WG to allow them to address any issues raised and also to the IETF discussion list for information. When done at the time of IETF Last Call, the authors should consider this review as part of the last-call comments they receive. Please always CC tsv-...@ietf.org if you reply to or forward this review. (1) I noticed in the "qos-classification-policy" there is "l4" support either TCP or UDP. It isn't clear if other transport protocols are purposefully not included. Should this also support SCTP and/or DCCP, or other transport protocol numbers in general? Are the QUIC aspects that might be matched contained within the UDP fields supported? (2) Is the allowable MTU another aspect of VPN services that should be able to be expressed? (3) ICMP isn't mentioned as an identity type, and I wondered if this should be. ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
