[OPSAWG]Erik Kline's No Objection on draft-ietf-opsawg-ipfix-tcpo-v6eh-17: (with COMMENT)
Erik Kline has entered the following ballot position for draft-ietf-opsawg-ipfix-tcpo-v6eh-17: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ for more information about how to handle DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-opsawg-ipfix-tcpo-v6eh/ -- COMMENT: -- # Internet AD comments for draft-ietf-opsawg-ipfix-tcpo-v6eh-17 CC @ekline * comment syntax: - https://github.com/mnot/ietf-comments/blob/main/format.md * "Handling Ballot Positions": - https://ietf.org/about/groups/iesg/statements/handling-ballot-positions/ ## Comments ### S3.6 * "reported that IPv6 packets with extension headers are often dropped" A useful citation here might be RFC 7872, "Observations on the Dropping of Packets with IPv6 Extension Headers in the Real World". ## Nits ### S3.4 * "the occurrences of the Fragment headers" -> "the occurrence of the Fragment header" to match the example scenario's description. ___ OPSAWG mailing list -- opsawg@ietf.org To unsubscribe send an email to opsawg-le...@ietf.org
[OPSAWG] Erik Kline's No Objection on draft-ietf-opsawg-mud-iot-dns-considerations-12: (with COMMENT)
Erik Kline has entered the following ballot position for draft-ietf-opsawg-mud-iot-dns-considerations-12: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ for more information about how to handle DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-opsawg-mud-iot-dns-considerations/ -- COMMENT: -- # Internet AD comments for draft-ietf-opsawg-mud-iot-dns-considerations-12 CC @ekline * comment syntax: - https://github.com/mnot/ietf-comments/blob/main/format.md * "Handling Ballot Positions": - https://ietf.org/about/groups/iesg/statements/handling-ballot-positions/ ## Comments ### S3 * "ip6.arpa", not "ipv6.arpa" This is correct elsewhere in the doc, but this seems to have been missed. ### S3.2 * "recursive servers should cache data for at least..." ... while still respecting TTLs in the replies, yes? ### S6.4 * I suggest finding some text to point to that defines what a "geofenced" name is. Right now this feels like the kind of thing that everyone "just knows what it means", but could use some formal description. ## Nits ### S3.1 * s/mapping/mappings/? ### S4.1 * s/inprotocol/in-protocol/ ### S4.2 * "all those addresses DNS for the the name" -> "all those addresses in the DNS for the name" ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
[OPSAWG] Erik Kline's Yes on draft-ietf-opsawg-9092-update-10: (with COMMENT)
Erik Kline has entered the following ballot position for draft-ietf-opsawg-9092-update-10: Yes When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ for more information about how to handle DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-opsawg-9092-update/ -- COMMENT: -- # Internet AD comments for draft-ietf-opsawg-9092-update-10 CC @ekline * comment syntax: - https://github.com/mnot/ietf-comments/blob/main/format.md * "Handling Ballot Positions": - https://ietf.org/about/groups/iesg/statements/handling-ballot-positions/ ## Comments ### S5 * "... processing is too hard." Perhaps there's a better wording that might be found here. "imposes significant computational complexity" or something? ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
[OPSAWG] Erik Kline's No Objection on draft-ietf-opsawg-ipfix-srv6-srh-12: (with COMMENT)
Erik Kline has entered the following ballot position for draft-ietf-opsawg-ipfix-srv6-srh-12: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ for more information about how to handle DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-opsawg-ipfix-srv6-srh/ -- COMMENT: -- # Internet AD comments for draft-ietf-opsawg-ipfix-srv6-srh-12 CC @ekline * comment syntax: - https://github.com/mnot/ietf-comments/blob/main/format.md * "Handling Ballot Positions": - https://ietf.org/about/groups/iesg/statements/handling-ballot-positions/ ## Comments ### S6.2 * We might clarify here that no export method involves any "decompression" of a compressed SID. (I assume unpacking a compressed SID is entirely the responsibility of an analysis function within or downstream of the collector.) ## Nits ### S5.2 * s/designed experts/designated experts/ ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
[OPSAWG] Erik Kline's Yes on draft-ietf-opsawg-l2nm-17: (with COMMENT)
Erik Kline has entered the following ballot position for
draft-ietf-opsawg-l2nm-17: Yes
When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)
Please refer to
https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/
for more information about how to handle DISCUSS and COMMENT positions.
The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-opsawg-l2nm/
--
COMMENT:
--
# Internet AD comments for {draft-ietf-opsawg-l2nm-17}
CC @ekline
## Comments
### S6
* Should the 'df-election' description make brief mention of the meaning
and use of the 'revertive' boolean?
### S8.3
* I can find neither 'revertive' nor 'preempt' in RFC 8584. Can the
description be expanded a bit to provide more context (or maybe the
reference section)?
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg
[OPSAWG] Erik Kline's No Objection on draft-ietf-opsawg-ntf-12: (with COMMENT)
Erik Kline has entered the following ballot position for draft-ietf-opsawg-ntf-12: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/blog/handling-iesg-ballot-positions/ for more information about how to handle DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-opsawg-ntf/ -- COMMENT: -- [S3.1; question] * Figure 2: Is PCAP a possible Data Encoding for the Forwarding Plane? * Figure 2: Should "plain text" be replaced by something like "proprietary"? I suspect the intent was to communicate that custom/bespoke encodings may still be quite common. ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
[OPSAWG] Erik Kline's Discuss on draft-ietf-opsawg-l3sm-l3nm-11: (with DISCUSS and COMMENT)
Erik Kline has entered the following ballot position for draft-ietf-opsawg-l3sm-l3nm-11: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/blog/handling-iesg-ballot-positions/ for more information about how to handle DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-opsawg-l3sm-l3nm/ -- DISCUSS: -- [general] * I'm sure there are plenty things I'm not understanding, and probably these things are easy to address. But in general I feel like there could be some tension between needing to specify/model the L3 attributes that are used to provision both the endpoint and the clients with a possibly somewhat cleaner separation for holding client IP provisioning info. At what point, for example, should there be something like a separate "client-ip-provisioning-profile" string that is referenced? I think some of the richness of what can be expressed in IPv6 RAs may be bringing these ideas up, some of which can be expressed in DHCP as well but operationally may be less common. The contents of RIOs in particular seem like a bit of client provisioning information that an endpoint might need to be aware of as well. [S7.6.2] * Provisioning IPv6 clients can be more rich than the DHCPv6/SLAAC model noted here (and much more so than IPv4/DHCPv4). Since you document how local-address/prefix-length becomes a PIO, should there be other related IP connectivity provisioning information in here, like: * more than just one PIO? (is this just repeated ip-connection/ipv6 entries, one for each on-link prefix?) * one or more RIOs that might need to be advertised to clients? * others (PVDIO, ...)? If this is "out of scope" for this document, where does it belong in the overall provisioning of an L3VPN service (out of curiosity, given that this document kinda models DHCP IP allocation ranges)? [S8] * Under provider DHCPv6 servers, the server definition has an "address-assign" choice of "number" with a "number-of-dynamic-address" (defaulting to "1"), but the description talks about the number of allocated prefixes. Should this value be "number-of-dynamic-prefixes" instead? * Which of these elements describes whether or not DHCPv6 PD (Prefix Delegation) is enabled, and the prefix pools used? -- COMMENT: -- [S7.2, nit] * "refers to as set of policies" -> "refers to a set of policies" [S7.3, nit] * "a P node or event a dedicated node" -> "a P node or even a dedicated node" [S7.4, nit] * "Indicates the maximum prefixes" -> "Indicates the maximum number of prefixes", perhaps? [S7.6.1, nit] * "is the layer two connections" -> "is the layer two connection" (although this sentence may be redundant with the one two sentences prior) [S7.6.6, nit] * "carrierscarrier" -> "carriers-carrier" ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
[OPSAWG] Erik Kline's No Objection on draft-ietf-opsawg-vpn-common-10: (with COMMENT)
Erik Kline has entered the following ballot position for draft-ietf-opsawg-vpn-common-10: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/blog/handling-iesg-ballot-positions/ for more information about how to handle DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-opsawg-vpn-common/ -- COMMENT: -- [S3, question] * Should "ipv6/ttl" actually be "ipv6/hoplimit"? I'm not sure what might have been defined in other YANG documents elsewhere, but "ttl" is not the term normally associated with IPv6 (8200s3). * Should "ipv6/protocol" actually be "ipv6/nextheader"? The field in the header is actually "Next Header" (8200s3), but is the intention here to identify the next "logical higher-layer protocol", i.e. skipping over other headers that might be in between the IPv6 header and, say, a TCP header? * How does "private or public cloud" count as "external connectivity"? Seems like the referenced 4364s11 is primarily concerned with Internet access. I guess it seems odd to me to consider a VPN endpoint in a cloud instance especially different from any other (e.g., physical) endpoint... ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
[OPSAWG] Erik Kline's No Objection on draft-ietf-opsawg-finding-geofeeds-08: (with COMMENT)
Erik Kline has entered the following ballot position for draft-ietf-opsawg-finding-geofeeds-08: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-opsawg-finding-geofeeds/ -- COMMENT: -- [[ comments ]] [ general ] * Please see the INT-DIR comments (https://datatracker.ietf.org/doc/ review-ietf-opsawg-finding-geofeeds-08-intdir-lc-combes-2021-05-14/) if you have not already. ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
[OPSAWG] Erik Kline's No Objection on draft-ietf-opsawg-model-automation-framework-07: (with COMMENT)
Erik Kline has entered the following ballot position for draft-ietf-opsawg-model-automation-framework-07: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-opsawg-model-automation-framework/ -- COMMENT: -- [[ nits ]] [ section 1 ] * "processing of customer's" -> "processing of customer", perhaps * The colon-delimited sentence ending the paragraph doesn't seem to imply that list is what should logically follow. I think the sentence aims to imply that in-house and silo nature of existing work has lead the some challenges, including the ones listed. I think a slight reword might fix this up pretty easily. * "between a NETCONF/RESTCONF clients and servers" -> "between NETCONF/RESTCONF clients and servers" * "YANG is transport independent" -> "YANG is a transport-independent" * "model composing" -> "model composition" perhaps? * "out of the scope" -> "out of scope" [ section 3.2 ] * "that to fulfil the service request"? perhaps "that fulfill the service request"? [ section 3.4 ] * "to support newly added module", suggest either: "to support newly added modules" or "to support a newly added module" (probably the former, given subsequent "and features") [ section 4.2.4 ] * "or network resources be mis-allocated" -> "or network resources might be mis-allocated" ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
[OPSAWG] Erik Kline's No Objection on draft-ietf-opsawg-sdi-11: (with COMMENT)
Erik Kline has entered the following ballot position for draft-ietf-opsawg-sdi-11: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-opsawg-sdi/ -- COMMENT: -- [[ comments ]] * Perhaps a suggestion that vendors might want to have a factory-installed option for interested customers that /only/ an encrypted config can be tried and no attempt to use a plaintext config will be made. * Security considerations paragraph about control of the configuration server should include a mention that the key is not required for interference if the booting device will happily fall back to loading a cleartext config. * Though less common than DHCPv4, consider acknowledging the broader (open) issue of file/TFTP server service discovery (DHCPv6, RAs plus resolution of a well-known hostname, DNSSD, ...). [[ nits ]] [ section 4.2 ] * "Publish TFTP Server" --> "Publish to TFTP Server", perhaps ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
