[OPSAWG] Éric Vyncke's No Objection on draft-ietf-opsawg-model-automation-framework-07: (with COMMENT)
Éric Vyncke 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: -- Thank you for the work put into this document. Please find below a couple of non-blocking COMMENT points and nits. I hope that this helps to improve the document, Regards, -éric == COMMENTS == A generic comment: it hurts my eyes to see several occurrences of "NAT" as a service in an IETF document in 2020... Should there be a reference to draft-claise-opsawg-service-assurance-architecture (albeit not yet an adopted document) ? There are a lot of detailed service creations with a good decomposition of all the required steps; but, little is written on the importance of YANG models (as opposed to any standard data exchange), so, the current title seems a little misleading. -- Abstract -- To be honest, I fail to understand why data models can be used to 'derive' configuration information. Did the authors mean 'describe' or 'specify' ? Later "This document describes an architecture" while the title of this document if "framework" ? Slight semantic difference ;-) And later "accommodate modules that", is it 'YANG modules' or 'data models' ? -- Section 4 -- The complex figure 4 would benefit from some textual introduction referring to the subsections. Also, the meaning of the arrow would gain if specified. E.g., why "Service Diagnosis" does not have a loop back to optimization or assurance ? -- Section 4.2.2 -- If not mistaken, this is the first appearance of the notation "". Do the angle brackets have a specific meaning? -- Section 4.2.3 -- Suggestion to use the figure 4 wording as the title esp. since the wording of MDT is not really used in the sub-section. -- Section 6 -- Is it required/useful to have the 'standard YANG security considerations" in this document that does not contain any YANG module? -- Section 10.1 -- Most of the references should probably be informational only. == NITS == Generic nit, I found the use of capitalized "Service Model" or "Network Models" a little disturbing. -- Section 1 -- "how different layer YANG data models" is rather difficult to parse, suggest to rephrase it. -- Section 4.4 -- Is it "service decomposing" or "service decomposition" ? ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
[OPSAWG] Éric Vyncke's No Objection on draft-ietf-opsawg-tacacs-yang-10: (with COMMENT)
Éric Vyncke has entered the following ballot position for draft-ietf-opsawg-tacacs-yang-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/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-tacacs-yang/ -- COMMENT: -- Thank you for the work put into this document. Please find below some non-blocking COMMENT points (but replies would be appreciated), and one nit. I hope that this helps to improve the document, Regards, -éric == COMMENTS == I like to be able to specify the VRF via vrf-instance as well as the source-interface, which is not the case of RFC 7317 (if not mistaken). -- Section 4 -- Should the leaf "server-type" also be mandatory ? == NITS == -- Section 2.1 -- s/Tree diagrams used/The tree diagram used/ as there is a single tree ;-) ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
[OPSAWG] Éric Vyncke's No Objection on draft-ietf-opsawg-finding-geofeeds-10: (with COMMENT)
Éric Vyncke has entered the following ballot position for draft-ietf-opsawg-finding-geofeeds-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/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: -- Thank you for the work put into this document. Please find below some non-blocking COMMENT points (but replies would be appreciated), and some nits. Thank you to George Michaelson for his shepherd's write-up (including the WG consensus). Nice to have acknowledged him. Thank you Jean-Michel Combes for the INT-DIR Last Call review at: https://datatracker.ietf.org/doc/review-ietf-opsawg-finding-geofeeds-08-intdir-lc-combes-2021-05-14/ The telechat INT-DIR review by Wassim Haddad also seconds a good opinion of this document. I hope that this helps to improve the document, Regards, -éric == COMMENTS == -- Section 3 -- Having a standards track document relying on a 'remarks:' attribute looks really weird. Should it rather be informational ? NB: I understand that changing the RPSL syntax is mostly mission impossible. Should the case when both "remarks: Geofeed" and "geofeed" are present but differ be mentioned ? -- Section 4 -- What happens if the public key of the certificate is changed? Should the cert serial number be part of the signature? Or at least mention the obvious that the signature must be re-executed when the cert if changed (e.g., in section 5). -- Section 5 -- Is there any reason why the doc shepherd is not acknowledged ? == NITS == I find the use of the colon in "inetnum:" quite annoying and confusing. The use of quotes in the last § of section 3 is easier to read and parse -- Section 3 -- Do the examples really need to be in IPv4 ? ;-) -- Section 4 -- The use of "department" in "getting the department with the Hardware Security Module" is difficult to understand by non-English native readers (at least for me as I had to re-read it twice and guess the meaning). ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
[OPSAWG] Éric Vyncke's No Objection on draft-ietf-opsawg-ipfix-mpls-sr-label-type-08: (with COMMENT)
Éric Vyncke has entered the following ballot position for draft-ietf-opsawg-ipfix-mpls-sr-label-type-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-ipfix-mpls-sr-label-type/ -- COMMENT: -- Thank you for the work put into this document. I have only one suggestion: expand "IE" on the first use. Special thanks to Med Boucadair for his detailed shepherd's write-up notably about the WG consensus. I hope that this helps to improve the document, Regards, -éric ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
[OPSAWG] Éric Vyncke's No Objection on draft-ietf-opsawg-vpn-common-10: (with COMMENT)
Éric Vyncke 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: -- As I am abroad on vacations, I had not time to review in depth this document, hence I am trusting the Internet directorate Last-Call review by Suresh: https://datatracker.ietf.org/doc/review-ietf-opsawg-vpn-common-09-intdir-lc-krishnan-2021-08-30/ I was about to post similar comments as Erik Kline's ones about the lack of IPv6 terminology in the classification but Med's reply is OK. May I suggest though to clearly reference RFC 8519 (which should be updated) where this topic is discussed ? I also appreciate the reuse of the (incomplete) ACL YANG modules. Regards -éric ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
[OPSAWG] Éric Vyncke's No Objection on draft-ietf-opsawg-ntf-10: (with COMMENT)
Éric Vyncke has entered the following ballot position for draft-ietf-opsawg-ntf-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-ntf/ -- COMMENT: -- Thank you for the work put into this document. All in all, this is a very good introduction document to telemetry but I am unsure whether it is a 'framework' (and this is a real concern of mine). Due to the amount of documents on the next IESG telecast agenda, I did not review the appendixes. Please find below some non-blocking COMMENT points (but replies would be appreciated even if only for my own education), and some nits. Special thanks to Alexander Clemm for the shepherd's write-up about the WG consensus. Thanks also to Jean-Michel Combes for his Internet directorate review at: https://datatracker.ietf.org/doc/review-ietf-opsawg-ntf-10-intdir-telechat-combes-2021-11-24/ I believe that Jean-Michel spotted a serious issue in the security section but I trust the Security Area Directors on this specific topic and will not raise a block DISCUSS on this point especially as Haoyu Song has taken some actions. I hope that this helps to improve the document, Regards, -éric As a non-English speaker, the document title is a little ambiguous at first sight: is it about telemetry about network data or about using the network to get some telemetry ? Unsure whether this ambiguity can be removed. BTW, I like the sections on use cases and challenges but I am ambivalent whether they are useful in this document. A lot of the concepts in this framework could be used for other applications beyond network layer telemetry. Was this extension considered by the authors ? There are several informative references to IRTF & IETF drafts, which is OK of course but those drafts may never be published. Perhaps, is it premature to publish this document ? -- Section 2 -- Suggest to rely on https://www.rfc-editor.org/materials/abbrev.expansion.txt to avoid redefining well-known terms as JSON or MIB. -- Section 3 -- No need to reply but I am unsure whether the paragraph about SDN, AN, ... brings any value to this document. -- Section 3.1 -- Should there be some words about whether actual packet content is part of telemetry ? -- Section 3.2 -- Should there be a mention of "big data" again when enumerating the 4 Vs ? -- Section 3.3 -- Is it the forwarding chip that generate, package, and send the telemetry as hinted in the first bullet ? I would guess that the chip indeed collects the data but it is up to another component to do rest. Please add a definition/reference for "sFlow". -- Section 3.4 -- Should there also be a mention of common naming/ID if data needs to be merged among different sources ? I.e., having common keys with the same format or at least having some equivalence. "In-network customisation" seems partly contradictory with unified models or did I misread this part ? For an uneducated reader (like myself), I wonder whether actual packet content is included in "The data originated from the data plane forwarding chips" -- Section 3.5 -- In "Efficient data fusion is critical for applications to reduce the overall quantity of data", is it about "fusion" or "aggregation" ? -- Section 4.1 -- In figure 2, what is 'template' ? This does not seem a well-defined term, suggest to remove it. Also in figure 2, suggest replace "HTTP" by "HTTPS" In figure 2, what is the meaning of "plain" for data encoding ? -- Section 4.1.3 -- Could the "quality" in the first paragraph be described as it is rather vague? Later in this section "The data should be structured and labeled", what is meant by 'labeled' ? And later in the same §, I am unsure how to understand "data types"... (as I read "data types" as float vs. integer) or is it simply "data" Suggest to make the taxonomy part a subsection. Is there a reason why "AM" is not expanded in "AM [RFC8321]" ? In "Big Data sources that analyse streams of information, such as Twitter messages", I am afraid that I fail to understand how sources can analyse data. -- Section 4.2 -- I fail to understand why formatting is part of "Data Generation and Processing" and not of "Data Encoding and Export". -- Section 4.4 -- Please excuse my lack of knowledge in this domain, but I have hard time to understand how MIB & YANG modules can help in data generation and processing in figure 5. Should there be some additional clarifications ? Again, possibly because I am not an expert in this field. --
[OPSAWG] Éric Vyncke's No Objection on draft-ietf-opsawg-l2nm-18: (with COMMENT)
Éric Vyncke has entered the following ballot position for draft-ietf-opsawg-l2nm-18: 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-l2nm/ -- COMMENT: -- # Éric Vyncke, INT AD, review of # Éric Vyncke, INT AD, review of draft-ietf-opsawg-l2nm-18 CC @evyncke Thank you for the work put into this document. It solves a common and important issue while keeping backward compatibility. Please find below some non-blocking COMMENT points (but replies would be appreciated even if only for my own education), and some nits. Special thanks to Adrian Farrel for the shepherd's write-up including the WG consensus and the intended status. The use of IANA-maintained YANG modules looks attractive to me. I hope that this helps to improve the document, Regards, -éric ## COMMENTS ### Set of L2VPN technologies Just wondering how extensible this model is ? I.e., the L2 cross-connect of RFC 8986 is not included, any reason why ? How easy would it be to extend this model to also include RFC 8986 ? ### Section 2 ``` The corresponding YANG module can be used by a service orchestrator to request a VPN service to a network controller or to expose the list of active L2VPN services. ``` Does this mean that state information (e.g., counters) are not included ? Actually, sections 7.3 & 7.6.3 mention some status & OAM support so suggest adding status & OAM to the above text. ### Section 6 While I understand that "ethernet" is used in a broad concept (i.e., also covering Wi-Fi), I find the use of 'ethernet' a little restrictive as layer-2 VPN could exist in a near future with technologies that are not IEEE 802.3 based (e.g., some IoT networks or the good old frame relay). Alas, probably too late to change anything. ### Section 7.4 ``` 'svc-mtu': Is the service MTU for an L2VPN service (i.e., Layer 2 MTU including L2 frame header/tail). It is also known as the maximum transmission unit or maximum frame size. ``` Does it include CRC and/or preamble ? It would be nice also to mention the unit of this metric. Same question in the 'mtu' in section 7.6.4. ### Section 8.4 Missing "units" in "svc-mtu'. Is 300 msec a valid default aging timer for a MAC address ? This seems really short. ### Sections A.2 & A.3 Thanks for providing an IPv6 example ;-) ## NITS ### MAC is uppercase I noticed at least one occurence of 'mac' in lower case. ## Notes This review is in the ["IETF Comments" Markdown format][ICMF], You can use the [`ietf-comments` tool][ICT] to automatically convert this review into individual GitHub issues. [ICMF]: https://github.com/mnot/ietf-comments/blob/main/format.md [ICT]: https://github.com/mnot/ietf-comments ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
[OPSAWG] Éric Vyncke's No Objection on draft-ietf-opsawg-yang-vpn-service-pm-13: (with COMMENT)
Éric Vyncke has entered the following ballot position for draft-ietf-opsawg-yang-vpn-service-pm-13: 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-yang-vpn-service-pm/ -- COMMENT: -- # Éric Vyncke, INT AD, comments for draft-ietf-opsawg-yang-vpn-service-pm-13 CC @evyncke Thank you for the work put into this document. Please find below some non-blocking COMMENT points (but replies would be appreciated even if only for my own education), and some nits. Special thanks to Adrian Farrel for the shepherd's detailed write-up including the WG consensus *and* the justification of the intended status. I hope that this review helps to improve the document, Regards, -éric ## COMMENTS ### Relationship with other OPSAWG documents Just curious: it this work somehow related to draft-ietf-opsawg-service-assurance-architecture ? I.e., should this document add some reference to the service assurance I-Ds ? ### Section 2.1 As 'PE' is defined, I was also expecting to see 'CE' (notably used in section 4.1) and 'P' (notably used in section 4.3). ### Section 3 Suggest to explain why in `Models are key for automating network management operations.`. ### Section 4 Unsure about the value of figure 2, but feel free to keep it (this is a matter of taste). ### Section 4.3 Just curious about why `mac-num-limit` is used rather than `maximum-mac-entries` for consistency with the previous entries? ### Section 4.4 Would it be useful to split `inbound-non-unicast` into broadcast and multicast ? ## NITS ### Space after ':' It would nicer if there was a space character after several ':'. ### Section 4.4 s/updatd/updated/ ## Notes This review is in the ["IETF Comments" Markdown format][ICMF], You can use the [`ietf-comments` tool][ICT] to automatically convert this review into individual GitHub issues. [ICMF]: https://github.com/mnot/ietf-comments/blob/main/format.md [ICT]: https://github.com/mnot/ietf-comments ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
[OPSAWG] Éric Vyncke's No Objection on draft-ietf-opsawg-service-assurance-architecture-12: (with COMMENT)
Éric Vyncke has entered the following ballot position for draft-ietf-opsawg-service-assurance-architecture-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-service-assurance-architecture/ -- COMMENT: -- # Éric Vyncke, INT AD, comments for draft-ietf-opsawg-service-assurance-architecture-12 CC @evyncke Thank you for the work put into this document. Very interesting and very easy to read document: congratulations ! Please find below some non-blocking COMMENT points (but replies would be appreciated even if only for my own education). Special thanks to Michael Richardson for the shepherd's detailed write-up including the WG consensus *but* it lacks the justification of the intended status. Please note that Benno Overeinder is the Internet directorate reviewer (at my request) and you may want to consider this int-dir reviews as well when Benno will complete the review (no need to wait for it though): https://datatracker.ietf.org/doc/draft-ietf-ippm-rfc8321bis/reviewrequest/16061/ I hope that this review helps to improve the document, Regards, -éric PS: thanks for listing me as contributor. ## COMMENTS ### Section 1 Please explain what the "SAIN orchestrator" is before using this concept. It would also be nice to describe what the "assurance graph" is. As I had some background information on SAIN, I was able to follow the introduction but I am unsure whether other readers will be able to understand it without reading the next section. Suggest to either reduce the section 1 (as section 3 goes in more details) or move the terminology section before the description. Unsure whether graphs have roots ;-) in "The root of the assurance graph". ### Section 3 Should there be text on how the SAIN orchestrator generates the assurance graph before decomposing it ? I.e., a forward reference to section 3.1 Figure 1, as the text is also about VIM and NFC, should "Network System" be replaced by "System" or any generic term? ### Section 3.1 What is meant by "peer1 tunnel interface" ? Is it the egress interface used by the encapsulated packets ? Or is it the set of ingress interfaces where the to-be-encapsulated packets are received from ? (of course the same reasoning when decapsulating packets). ### Section 3.1.1 Unsure whether DAG is really a requirement (rationale will be welcome in the text), but suggest to rename the 'top' box into 'middle' (or 'synthetic') as it is not really on the top of figure 3. This would also avoid the use of "empty" box in figure 7. ### Section 3.2 Are SLO used anywhere else in the document? Else, don't introduce the acronym. ### Section 3.3 Is `a subservice also defines its assurance`correct? I would have expected `a subservice is associated to its assurance`. ### Section 3.4 What is the purpose of "global computation graph" ? ### Section 3.9 ``` The assurance graph will change over time, because services and subservices come and go (changing the dependencies between subservices), or simply because a subservice is now under maintenance. ``` But section 3.6 seems to indicate that maintenance is just an event/metric and does not cause a change in the assurance graph itself. ## Notes This review is in the ["IETF Comments" Markdown format][ICMF], You can use the [`ietf-comments` tool][ICT] to automatically convert this review into individual GitHub issues. [ICMF]: https://github.com/mnot/ietf-comments/blob/main/format.md [ICT]: https://github.com/mnot/ietf-comments ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
[OPSAWG] Éric Vyncke's Discuss on draft-ietf-opsawg-service-assurance-yang-10: (with DISCUSS and COMMENT)
Éric Vyncke has entered the following ballot position for draft-ietf-opsawg-service-assurance-yang-10: 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/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-service-assurance-yang/ -- DISCUSS: -- # Éric Vyncke, INT AD, comments for draft-ietf-opsawg-service-assurance-yang-10 CC @evyncke Thank you for the work put into this document. A very interesting piece of work and a well-written piece of text (even if I am balloting DISCUSS). The examples are also helping. Please find below some DISCUSS points (+ suggestions), some non-blocking COMMENT points (but replies would be appreciated even if only for my own education). Special thanks to Michael Richardson for the shepherd's detailed write-up including the WG consensus *but* it lacks the justification of the intended status. It would have been nice to list the implementations (even if I know one). Please note that Tommy Pauly is the Internet directorate reviewer (at my request) and you may want to consider this int-dir reviews as well when Tommy will complete the review (no need to wait for it though): https://datatracker.ietf.org/doc/draft-ietf-opsawg-service-assurance-yang/reviewrequest/16806/ Also, thanks to the WG chairs and the responsible AD to bundle this I-D and its companion to the same IESG telechat: it helps a lot! I hope that this review helps to improve the document, Regards, -éric ## DISCUSS As noted in https://www.ietf.org/blog/handling-iesg-ballot-positions/, a DISCUSS ballot is a request to have a discussion on the following topics: ### BCP14 template As noted by https://author-tools.ietf.org/api/idnits?url=https://www.ietf.org/archive/id/draft-ietf-opsawg-service-assurance-yang-10.txt and Lars, the BCP14 template is not correct even if it is required for a proposed standard (it mentions BCP13 ;-) ). As I have further DISCUSS issues below, I am raising the trivial BCP14 issue to a blocking DISCUSS. ### Section 3.3 To my SQL eyes, it hurts to use a -1 value for health-score when there is no value. There is no "mandatory true" statement for this leaf, i.e., it can be absent in the telemetry. Is there a semantic difference between the absence of health-score and the value of -1 ? Is the SAIN collector expected to process those 2 cases differently ? Suggest to either remove the -1 sentinel value, or add "mandatory true" attribute, or be specific about the difference (if any). ### Section 4 It is unclear from this section whether it applies to IETF-specified YANG modules only? I.e., may a vendor augment this IETF YANG module in its own namespace ? I guess so, but worth writing it (or restrict this section to future IETF work only). -- COMMENT: -- ## COMMENTS ### Downref As noted by https://author-tools.ietf.org/api/idnits?url=https://www.ietf.org/archive/id/draft-ietf-opsawg-service-assurance-yang-10.txt and Lars, there is a downward reference that was not mentioned in the IETF LC. ### Lack of YANG doctors review ? Even if one author is Mr. YANG ;-), is there a reason why there is neither a Last Call nor a Telechat review by the YANG doctors ? ### Section 1 ``` [I-D.ietf-opsawg-service-assurance-architecture] specifies an architecture and a set of involved components for service assurance, called Service Assurance for Intent-Based Networking (SAIN). ``` The SAIN architecture draft is informational, so it cannot "specify". Please use "describes". ### Section 3.1 ``` The two subservices presented above need different sets of parameters to fully characterize one of their instance. An instance of the device subservice is fully characterized by a single parameter allowing to identify the device to monitor. For ip-connectivity subservice, at least the device and IP address for both ends of the link are needed to fully characterize an instance. ``` s/two subservices presented/two example subservices presented/ While I am not English native speaker, I wonder whether the plural form should be used for "IP address for both ends" ? `The dependencies are modelled as an adjacency list,` or simply `The dependencies are modelled as a list,` ? ### Section 3.2 ``` The date of last change "assurance-graph-last-change" is read only. It must be updated each time the graph structure is changed by addition or deletion
[OPSAWG] Éric Vyncke's Yes on draft-ietf-opsawg-service-assurance-yang-11: (with COMMENT)
Éric Vyncke has entered the following ballot position for draft-ietf-opsawg-service-assurance-yang-11: 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-service-assurance-yang/ -- COMMENT: -- Thank you for the -11 revision, it addresses all my previous blocking DISCUSS points [1] and most of my COMMENT ones. Still wondering why under-maintenance.contact can be free form in addition to an URI. But, this is not a blocking point. Please note that Tommy Pauly is the Internet directorate reviewer (at my request) and you may want to consider this int-dir reviews as well when Tommy will complete the review (no need to wait for it though): https://datatracker.ietf.org/doc/draft-ietf-opsawg-service-assurance-yang/reviewrequest/16806/ As I like the work, I am even balloting a YES. [1] See https://mailarchive.ietf.org/arch/msg/opsawg/lH6bv_qVwxO7r5kYYHodZbpxhXs/ ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
[OPSAWG] Éric Vyncke's No Objection on draft-ietf-opsawg-tlstm-update-12: (with COMMENT)
Éric Vyncke has entered the following ballot position for draft-ietf-opsawg-tlstm-update-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-tlstm-update/ -- COMMENT: -- # Éric Vyncke, INT AD, comments for draft-ietf-opsawg-tlstm-update-12 CC @evyncke Thank you for the work put into this document. Please find below some non-blocking COMMENT points. Special thanks to Joe Clarke for the shepherd's detailed write-up including the WG consensus **and** the justification of the intended status. I hope that this review helps to improve the document, Regards, -éric ## COMMENTS ### MIB Doctor review Like Lars, I wonder whether there was a MIB doctor review. ### Section 3.1 This text is repeated, is it on purpose ? ``` The reason 0-RTT is disallowed is that there are no "safe" messages that if replayed will be guaranteed to cause no harm at a server side: all incoming notification or command responses are meant to be acted upon only once. See Security considerations section for further details ``` ## Notes This review is in the ["IETF Comments" Markdown format][ICMF], You can use the [`ietf-comments` tool][ICT] to automatically convert this review into individual GitHub issues. [ICMF]: https://github.com/mnot/ietf-comments/blob/main/format.md [ICT]: https://github.com/mnot/ietf-comments ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
[OPSAWG] Éric Vyncke's Discuss on draft-ietf-opsawg-add-encrypted-dns-11: (with DISCUSS and COMMENT)
Éric Vyncke has entered the following ballot position for draft-ietf-opsawg-add-encrypted-dns-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/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-add-encrypted-dns/ -- DISCUSS: -- # Éric Vyncke, INT AD, comments for draft-ietf-opsawg-add-encrypted-dns-11 CC @evyncke Thank you for the work put into this document. Once the trivial DISCUSS is addressed, I will be happy to ballot a YES. Please find below one blocking DISCUSS points (easy to address), some non-blocking COMMENT points (but replies would be appreciated even if only for my own education), and some nits. Special thanks to Bernie Volz for the shepherd's detailed write-up including the WG consensus even if the justification of the intended status is rather vague. Other thanks to Tatuya Jinmei, the Internet directorate reviewer (at my request), please consider this int-dir review: https://datatracker.ietf.org/doc/review-ietf-opsawg-add-encrypted-dns-10-intdir-telechat-jinmei-2023-03-09/ (and I have read Med's replies and resolution of the issues) I hope that this review helps to improve the document, Regards, -éric ## DISCUSS As noted in https://www.ietf.org/blog/handling-iesg-ballot-positions/, a DISCUSS ballot is a request to have a discussion on the following topics: ### What to do with non-permitted DHCP option ? Sections 3.1 and 3.2 contain text like `Permitted DHCPv6 options in the DHCPv6-Options Attribute are maintained by IANA in the registry created in Section 8.4.1.` but I was unable to find anywhere in the document what is the expected behaviour of a RADIUS client receiving a non-permitted DHCP option ? At the bare minimum, I would expect the I-D to mention "non-permitted DHCP options MUST silently be ignored by the RADIUS client" Or did I fail to find a similar statement in the text ? -- COMMENT: -- ## COMMENTS ### Abstract Should the sentence `Even if the specification was initially motivated by the configuration of encrypted DNS resolvers,` be removed from the abstract ? It adds nothing but confusion. ### Section 3 Should the whole paragraph starting with `RADIUS servers have conventionally tolerated the input of arbitrary data via the "string" data type (Section 3.5 of [RFC8044])... ` rather be in the security (or operational) considerations section ? ### Section 3.1 Should normative language be used in `However, the server is not required to honor such a preference.`? I.e., the rest of the paragraph uses normative language. ### Section 4 Should 'DHCP relay' be mentioned in the section title ? It would of course be very long then but clearer for the reader (esp in the ToC) ## NITS ### Section 3.2 Suggest to use the same layout as in section 3.1 for the "value" field. ## Notes This review is in the ["IETF Comments" Markdown format][ICMF], You can use the [`ietf-comments` tool][ICT] to automatically convert this review into individual GitHub issues. [ICMF]: https://github.com/mnot/ietf-comments/blob/main/format.md [ICT]: https://github.com/mnot/ietf-comments ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
[OPSAWG] Éric Vyncke's Yes on draft-ietf-opsawg-add-encrypted-dns-12: (with COMMENT)
Éric Vyncke has entered the following ballot position for draft-ietf-opsawg-add-encrypted-dns-12: 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-add-encrypted-dns/ -- COMMENT: -- Thanks for addressing my previous DISCUSS[1], I sincerely think that the document is better now. Regards -éric [1] https://mailarchive.ietf.org/arch/msg/opsawg/yV4NKUp6tcmFGTkXomh7s1vmwhY/ ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
[OPSAWG] Éric Vyncke's Yes on draft-ietf-opsawg-sbom-access-15: (with COMMENT)
Éric Vyncke has entered the following ballot position for draft-ietf-opsawg-sbom-access-15: 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-sbom-access/ -- COMMENT: -- Thank you for the work put into this document. Please find below some non-blocking COMMENT points (but replies would be appreciated even if only for my own education). Special thanks to Win Wu for the shepherd's detailed write-up including the WG consensus and the justification of the intended status. I hope that this review helps to improve the document, Regards, -éric # COMMENTS (non blocking) ## 'transparency' vs. 'sbom' This is probably due to historical reasons, but I find it strange to have the YANG module named 'transparency' while this term does not appear in the abstract. ## Abstract I am not a native English speaker, so I am probably outside of my expertise here, but: * `automation is necessary to locate what software is running` should 'to identify' or 'to list' be better ? * `to provide the locations of software bills of materials (SBOMS) and to vulnerability information.` is there a verb missing between 'to' and 'vulnerability' ? I must admit that I cannot parse this sentence. ## Section 1 `we seek` who is the 'we' ? s/the model is a discovery mechanism/the model can be used as a discovery mechanism/ ? I.e., how can a model be a mechanism ? In `report to administrators the state of a system.` "state" is rather vague, can the state be qualified ? I.e., "security state" ? In the introduction of the 3 methods, the 2nd one (URI) is the only one having a normative MUST. Is it on purpose that the two other methods do not have normative language ? ## Section 6 `the endpoint SHOULD NOT provide unrestricted access by default` this is indeed a key point as the SBOM can also be viewed as the list of open doors to the device. I am really unsure how to fix this problem at all... I would also wish to have a mean to keep the SBOM information available for years even after manufacturer bankruptcy ... ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
[OPSAWG] Éric Vyncke's Yes on draft-ietf-opsawg-ipfix-srv6-srh-10: (with COMMENT)
Éric Vyncke has entered the following ballot position for draft-ietf-opsawg-ipfix-srv6-srh-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-ipfix-srv6-srh/ -- COMMENT: -- # Éric Vyncke, INT AD, comments for draft-ietf-opsawg-ipfix-srv6-srh-10 Thank you for the work put into this document. Please find below some non-blocking COMMENT points (but replies would be appreciated even if only for my own education). Special thanks to Mohamed Boucadair for the shepherd's detailed write-up including the WG consensus and the justification of the intended status. I hope that this review helps to improve the document, Regards, -éric ## COMMENTS ### More than data plane I like the idea of exporting srhIPv6ActiveSegmentType for operation, it goes well beyond the plain export of the SRH header. I just fear that the extra information is redundant and will be repeated quite often. ### Section 5.1.9 What would happen if this information is learned by two sources ? ### Section 6.3 Beside encapsulation, I do not see how multiple (S)RHs could be in one IPv6 packet. Anyway, the router will, per RFC 8200, only act on the outermost one. I.e., strongly suggest that this I-D specifies that only the outermost SRH & associated behavior are specified. ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
[OPSAWG] Éric Vyncke's No Objection on draft-ietf-opsawg-rfc7125-update-06: (with COMMENT)
Éric Vyncke has entered the following ballot position for draft-ietf-opsawg-rfc7125-update-06: 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-rfc7125-update/ -- COMMENT: -- # Éric Vyncke, INT AD, comments for draft-ietf-opsawg-rfc7125-update-06 Thank you for the work put into this document. ROA are indeed critical for the security and stability of the Internet. As usual for a -bis document, I reviewed only the diffs. Please find below some non-blocking COMMENT points (but replies would be appreciated even if only for my own education), and one nit. Special thanks to Joe Clarke for the shepherd's detailed write-up including the WG consensus *and* the justification of the intended status. I hope that this review helps to improve the document, Regards, -éric # COMMENTS ## Misleading file name While not important at this stage, this document appears more like a 7125-bis than a 7125-update. ## Section 3 In which cases can the Exporter deviate from the SHOULD in `SHOULD use reduced-size encoding` ? # NITS ## Section 3 Suggest to either use actions (on receiving) or roles(i.e., Exporter) in all clauses in `this Information Element MUST be exported with a value of zero and MUST be ignored by the Collector` ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
[OPSAWG] Éric Vyncke's No Objection on draft-ietf-opsawg-9092-update-10: (with COMMENT)
Éric Vyncke has entered the following ballot position for draft-ietf-opsawg-9092-update-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/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: -- # Éric Vyncke, INT AD, comments for draft-ietf-opsawg-9092-update-10 Thank you for the work put into this document. Please find below some non-blocking COMMENT points (but replies would be appreciated even if only for my own education). Special thanks to Michael Richardson for the shepherd's detailed write-up including the WG consensus *BUT* it lacks the justification of the intended status. Other thanks to Sheng Jiang, the Last Call Internet directorate reviewer: https://datatracker.ietf.org/doc/review-ietf-opsawg-9092-update-06-intdir-lc-jiang-2023-11-20/ (and I have seen interactions with the draft authors) I hope that this review helps to improve the document, Regards, -éric # COMMENTS (non-blocking) ## No IPv6 Examples I can only strongly regret, esp knowing the authors, that the examples are IPv4 only. Note: this issue prevents me to strongly support this document with a YES ballot. ## Section 3 Should the text be more normative than the plain text ``` The migration not only implies that the RIRs support the geofeed: attribute, but that all registrants have migrated any inetnum: ojects from remarks: to geofeed: attributes ``` ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
[OPSAWG] Éric Vyncke's No Objection on draft-ietf-opsawg-mud-iot-dns-considerations-12: (with COMMENT)
Éric Vyncke 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: -- # Éric Vyncke, INT AD, comments for draft-ietf-opsawg-mud-iot-dns-considerations-12 Thank you for the work put into this document. It is a nice piece of work, clear and easy to read. Please find below some non-blocking COMMENT points (but replies would be appreciated even if only for my own education). Special thanks to Henk Birkholz for the shepherd's detailed write-up including the WG consensus and the *very light* justification of the intended status. Please note that Dave Thaler is the IoT directorate reviewer (at my request) and you may want to consider this iot-dir review as well when it will be available (no need to wait for it though): https://datatracker.ietf.org/doc/draft-ietf-opsawg-mud-iot-dns-considerations/reviewrequest/19052/ You may also expect an Int-dir review as: https://datatracker.ietf.org/doc/draft-ietf-opsawg-mud-iot-dns-considerations/reviewrequest/19051/ (not yet assigned though) I hope that this review helps to improve the document, Regards, -éric # COMMENTS (non-blocking) ## Absence of mDNS Is mDNS used in the context of MUD ? If so, then it should be mentioned here. ## Abstract Let's be positive s/This document details concerns /This document details considerations / ## Section 1 s/Some Enterprises do this already. /Some organisations do this already. / ? (e.g., governmental agencies, ...) Suggest to put the sentence `The first section of this document...` on its own 1-sentence paragraph. ## Section 3 Suggest to always use "DNS names" rather than plain "names". Applicable in several places in the document. Isn't the mapping from address to DNS names usually called "reverse mapping" ? E.g., section 3.1.3 uses `reverse names`. ## Section 3.1 Suggest to add "often" in the too assertive sentence `Attempts to map IP address to names in real time fails for a number of reasons`. ## Section 3.1.2 `They could determine when a home was occupied or not`: actually when I leave home to travel (e.g., to IETF-119) most of my IoT devices are still active as I want to 'control' my home from remote. ## Section 3.1.3 `Service providers` is rather vague in this context, is it the access/internet SP or a hosted-IoT-service ? ## Section 3.2 It seems indeed to be the most obvious technique. So obvious that it should be given a hint in the introduction. Is there a common use case where the MUD controller is changing location ? I.e., then having different forward DNS resolution answers ? I would also expect the authoritative geo-sensitve servers will use a short DNS TTL in their answers. ## Section 4 Thanks for pointing me to "antipatterns", I learned something :-) OTOH, I had to follow the link to understand the paragraph :-( ## Section 4.3 Unsure whether using a real case with Amazon is useful here... ## Section 5 Whether the MUD devices and the MUD controllers use the same recursive resolver is probably orthogonal to the use of DoT/DoH. ## Section 6 AFAIK, LLDP can also be used per RFC 8520 in addition to DHCP to retrieve the MUD string. ## Section 6.5 The section title is about `Prefer DNS servers learnt from DHCP/Route Advertisements` but the text is only about DHCP. Btw, the exact wording is "Route*r* Advertisement" and a reference to RFC 8106 could be useful. Which are the reasons in `There are a number of reasons to avoid this` ? ## Section 7 `The use of non-local DNS servers exposes the list of names resolved to a third party` even if the recursive resolution is done 'locally' (i.e., on a CPE) it will leak the MUD requests, we could argue that using a non-local recursive resolver will only expose the requests to this non-local server but not to the actual authoritative server. ## References Please note that DNR & DDR are published as RFC 9462 / 9463 (dated November 2023). ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
[OPSAWG] Éric Vyncke's No Objection on draft-ietf-opsawg-mud-acceptable-urls-11: (with COMMENT)
Éric Vyncke has entered the following ballot position for draft-ietf-opsawg-mud-acceptable-urls-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/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-acceptable-urls/ -- COMMENT: -- # Éric Vyncke, INT AD, comments for draft-ietf-opsawg-mud-acceptable-urls-11 Thank you for the work put into this document. Please find below one blocking DISCUSS points (easy to address), some non-blocking COMMENT points (but replies would be appreciated even if only for my own education), and some nits. Special thanks to Henk Birkholz for the shepherd's detailed write-up including the WG consensus and the justification of the intended status. I hope that this review helps to improve the document, Regards, -éric # COMMENTS (non-blocking) ## Section 3.1 About the 2nd paragraph, the conflation of unsecure protocols (telnet) with a no-credential use case is confusing. The issue discussed here is not telnet vs. SSH but poor credentials. Suggest removing telnet/http protocols in the example. The 4th paragraph is important but I fail to see the link with this section "adding capabilities". ## Section 3.3 ALso unsure whether this section should be in this I-D. ## Section 4 References to the protocol for MUD sources are probably welcome. ## Section 4.1 `That it, the signing authority is pinned. ` should this be "that is" ? Also, I am not sure whether all readers will understand what is meant by "pinned". ## Section 5 What is the meaning of the "proposed mechanism" in a standard track document? Let's be more assertive and remove "proposed". Is there a common definition of "lowest Certification Authority (CA)" ? If so, a normative reference is welcome. "SHOULD" is used twice, when can an implementation deviate from the "SHOULD" ? I.e., why not a "MUST". ## Section 5.1 Where is "Base-URI" defined in this (or in another document) defined ? To be honest, I was about to ballot a blocking DISCUSS on this point. s/it contains the same series of segments/it contains the same serie of segments/ ? In `if a device ever suggests a URL that was previously used` how can a device downgrade to a previous firmware ? ## Section 5.3.1 Is this just an example ? If so, let's be clear in the section title. Last paragraph, should it be a "MUST" in `The manufacturer must continue to serve`. ## Section 5.3.2 Why can an implementation deviate from the `SHOULD NOT` ? ## Section 6 Should this section use more normative uppercase verbs ? ## Section 7 Is there any change wrt to RFC 8520 privacy considerations ? # NITS (non-blocking / cosmetic) I find the use of "!" in an IETF document rather unusual, but this is a matter of taste. ## Section 5.1 s/series of segment/series of segments/ ? ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
[OPSAWG] Éric Vyncke's No Objection on draft-ietf-opsawg-tacacs-13: (with COMMENT)
Éric Vyncke has entered the following ballot position for draft-ietf-opsawg-tacacs-13: 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-tacacs/ -- COMMENT: -- Thanks for the work everyone has put into this document. I have some comments and some nits. I also support most of the other comments issued by the IESG members. And, I appreciate the time taken to document a protocol that I used in the mid 90's ;-) it took sometime to document it... I also appreciate the use of 'obfuscation' in section 4.7. == COMMENTS == - section 1, I am unsure whether the 'today' in 'It is primarily used today...' still stands in 2019. - a little late to ask, but, is there any reason why draft-dahm-opsawg-tacacs does not refer to 'The Draft' in the datatracker? - section 4.8, the flag values are 0x01 and 0x04, but what about the other bits? Should they be considered as 0 and ignored on reception? - section 5.1, should TAC_PLUS_AUTHEN_SVC_ARAP := 0x04 also be deprecated ? - section 5.4.2.1 about 'ASCII login' while I understand that years ago it was ASCII only hence the name of the value but the text is unclear whether UTF-8 could be used (assuming that the network devices support this character set) - section 8.2, the route attribute is defined only for IPv4 while the T+ can send IPv6 addresses to the client. Is it sensible? == NITS == - abstract TACACS is an acronym which should be expanded in the abstract - section 3 could be updated esp around "character mode front end and then allow the user to telnet" - section 4.1 add that the port 49 has been allocated by the IANA ? - section 4.3 talks about flags but the packet format is also presented in section . Not a logical flow - section 8.1 s/IPV6 address text representation defined/IPv6 address text representation is defined/ (lower case V as well) - section 8.2, please clarify the inacl value, is it an ACL name or an ASCII representation of the list of ACL entries? ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
[OPSAWG] Éric Vyncke's No Objection on draft-ietf-opsawg-sdi-10: (with COMMENT)
Éric Vyncke has entered the following ballot position for draft-ietf-opsawg-sdi-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/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: -- Thank you for the work put into this document. The document is easy to read. Please also reply to Nancy's IoT directorate review at: https://datatracker.ietf.org/doc/review-ietf-opsawg-sdi-10-iotdir-telechat-cam-winget-2020-05-14/ (Thank you Nancy for the review) I am also trusting my security AD peers for the security aspects. Please find below a couple on non-blocking COMMENTs. I hope that this helps to improve the document, Regards, -éric == COMMENTS == Should the "IP address" be scoped ? I.e., is it global scope or (IPv4 and IPv6) link-local only ? -- Sections 1 & 2 -- PLEASE when mentioning DHCP also refer to DHCPv6 RFC 8415 (trusting the authors to fix this before final publication). You may also explore whether IPv6 Router Advertisement / PvD could be an option. -- Section 1.1 -- This is an informational document, so, I wonder whether a reference to BCP 14 is useful. (see also Murray's comment on section 4.2) -- Section 4.2 -- Is there a reason to suggest the use of TLS to fetch the certificate? Normally a certificate is public information and is authenticated. -- Section 5.1 -- Is there a need to store the public key (and the associate cert I guess) in TPM ? ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
[OPSAWG]Éric Vyncke's No Objection on draft-ietf-opsawg-tsvwg-udp-ipfix-12: (with COMMENT)
Éric Vyncke has entered the following ballot position for draft-ietf-opsawg-tsvwg-udp-ipfix-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-tsvwg-udp-ipfix/ -- COMMENT: -- # Éric Vyncke, INT AD, comments for draft-ietf-opsawg-tsvwg-udp-ipfix-12 Thank you for the work put into this document. Thanks to Joe Touch for his int-dir reviews but also kudos to the authors for reacting to Joe's issue about the SAFE/UNSAFE split and the normative reference to draft-ietf-opsawg-ipfix-tcpo-v6eh. The I-D is now in much better shape. Please find below some non-blocking COMMENT points (but replies would be appreciated even if only for my own education). Special thanks to Thomas Graf for the shepherd's detailed write-up including the WG consensus and the justification of the intended status. I hope that this review helps to improve the document, Regards, -éric # COMMENTS (non-blocking) ## Link to draft-ietf-tsvwg-udp-options There is a normative reference to draft-ietf-tsvwg-udp-options, so all is good, but it might have been better to wait for draft-ietf-tsvwg-udp-options rather than having to review this I-D without knowing what will be the published specification of UDP options. ## Section 1 s/widely deployed in *operators* networks/widely deployed in networks/ IPFIX is largely deployed outside of operators (in the sense if (I)SP) ;-) s/The IE specified in Section 4.1 uses the new abstract data type defined/The IE specified in Section 4.1 uses the new abstract data type *unsigned256* defined/ ? ## Section 3 While is it nice for the reader to have a short description of UDP options, it does not say anything about "Kind" as in `Options indicated by Kind values`... So, the reader must anyway read the UDP options draft. Suggest adding a short description of the Kind. ## SAFE or safe This document uses both "safe" and "SAFE" for what seems the same concept. Please select one writing everywhere to reduce confusion. ## Use of MUST w/o BCP14 There are a couple of "MUST" and "MUST NOT" in the text without any BCP14 template. This is OK, but the "MUST" is then equivalent to a "must", so suggest either using only lower case "must" or including BCP14 template. The lowercase "must" is anyway normative as it is part of a Proposed Standard but somehow less defined as the BCP14 "MUST". ## Section 4.1 s/The bit is set to 1 if the corresponding safe UDP option is observed in the Flow/The bit is set to 1 if the corresponding safe UDP option is observed *at least once* in the Flow/ s/The bit is set to 0 if the option is *not* observed in the Flow./The bit is set to 0 if the option is *never* observed in the Flow./ Same comment for the unsafe options in section 4.2 What about "UDP option extended format" ? I.e., where the Kind is expressed over 2 octets. Suggest adding some text restricting the use of this I-D to only "normal 1-octet Kind". ## Section 4.3 I am afraid that I do not understand what value to use based ont the Description. Are the only allowed values: 127 and 254 ? ___ OPSAWG mailing list -- opsawg@ietf.org To unsubscribe send an email to opsawg-le...@ietf.org
[OPSAWG]Éric Vyncke's Yes on draft-ietf-opsawg-ipfix-tcpo-v6eh-16: (with COMMENT)
Éric Vyncke has entered the following ballot position for draft-ietf-opsawg-ipfix-tcpo-v6eh-16: 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-ipfix-tcpo-v6eh/ -- COMMENT: -- # Éric Vyncke, INT AD, comments for draft-ietf-opsawg-ipfix-tcpo-v6eh-16 Thank you for the work put into this document. Please find below one blocking some non-blocking COMMENT points (but replies would be appreciated even if only for my own education), and one nit. Special thanks to Thomas Graf for the shepherd's detailed write-up including the WG consensus and the justification of the intended status. I hope that this review helps to improve the document, Regards, -éric # COMMENTS (non-blocking) ## Section 3 Suggest using the IE acronym rather than "Information Element" in the subsections of this section. ## Section 3.1 s/Type of an IPv6 extension header observed *in packets* of this Flow./Type of an IPv6 extension header observed *in at least one packet* of this Flow./ ? (or "in some packets") ## Section 3.2 I was wondering about this IE and the previous one as they looked quite atomic (plus the use of "consecutive") until I read the specification of ipv6ExtensionHeaderTypeCountList. Suggest adding a forward reference to section 3.4 and add some text that those 2 IEs can only occur in ipv6ExtensionHeaderTypeCountList. E.g., "This atomic IE MAY only occur in ipv6ExtensionHeaderTypeCountList as specified in section 3.4". ## Section 3.3 It took me to read until section 8.4.1 to understand the the bit number is *NOT* the extension header type per RFC 8200. It is really confusing with `The "No Next Header" (59) value` text, which I also read as bit 59. Strongly suggest adding a note on the value referring to NEW_IPFIX_IPv6EH_SUBREGISTRY not only in "Additional Information" but in "Description" (as it is really normative). ## Section 3.4 `How an implementation disambiguates between unknown upper-layer protocols vs. extension headers is not IPFIX-specific` is true but why not specifying the expected behavior of the collector at least? Citing RFC 8883 as an example, does not really help in a PS. Alternatively, the IANA NEW_IPFIX_IPv6EH_SUBREGISTRY could redefine UNK as "unknown extension or transport header". ## Sections 3.5 & 3.6 Excellent idea :-) Thanks ## Missing RH Type ? It would be really to be able to also export the Routing Header type, perhaps in an optional new IE following ipv6ExtensionHeaderType in the list or by adding more values in NEW_IPFIX_IPv6EH_SUBREGISTRY (cfr also section 8.4.2 `For example, a registration may request two bits for a new EH to cover specific behaviors or uses of that EH.`)? ## Section 4.1 `The value of tcpOptionsFull IE may be encoded in fewer octets` should it rather be a "SHOULD" (with explanations about the consequences of bypassing the SHOULD) ? s/The presence of tcpSharedOptionExID16List or tcpSharedOptionExID32List IEs is an indication that a shared TCP option (Kind=253 or 254) is observed in a Flow./The presence of tcpSharedOptionExID16List (Kind=253) or tcpSharedOptionExID32List (Kind=254) IEs is an indication that a shared TCP option is observed in a Flow./ ? ## Sections 4.2 and 4.3 Same comment as in sections 3.2 and 3.3. ## Section 5 Should it be an "Implementation Consideration" ? # NITS (non-blocking / cosmetic) ## Section 3.4 Should plural form be used for "header" in the example ? ___ OPSAWG mailing list -- opsawg@ietf.org To unsubscribe send an email to opsawg-le...@ietf.org
[OPSAWG]Éric Vyncke's No Objection on draft-ietf-opsawg-ipfix-fixes-10: (with COMMENT)
Éric Vyncke has entered the following ballot position for draft-ietf-opsawg-ipfix-fixes-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/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-fixes/ -- COMMENT: -- # Éric Vyncke, INT AD, comments for draft-ietf-opsawg-ipfix-fixes-10 Thank you for the work put into this document. Please find below some non-blocking COMMENT points (but replies would be appreciated even if only for my own education), and some nits. Special thanks to Thomas Graf for the shepherd's detailed write-up including the WG consensus and the justification of the intended status. I hope that this review helps to improve the document, Regards, -éric # COMMENTS (non-blocking) ## Abstract Section 1 Suggest using the full name of the IANA registry "IP Flow Information Export (IPFIX) Entities" (i.e., with "Entities" at the end). ## Section 1 Be more assertive in a PS: s/This document intends to update /This document updates / ## Section 4.3.2 Is it the "first" or "least-significant" byte in `A structure is currently associated with the first byte.`? Can only regret using the IPv4 terminology in 2024 as in `Bad TTL` rather than "Bad Hop-Limit/TTL" (would also suggest using "expired" as I do not know what a "bad" hop-limit is). I understand that this would require changing https://www.iana.org/assignments/ipfix/ipfix.xhtml#forwarding-status but why not doing it in the same "fix I-D" ? I would assume that Forwarding-Status should be a normative reference. ## Section 6.10.2 RFC 3022 does not contain the word "NAT44" so it cannot be a reference for NAT44 ;-) You may want to use "See [RFC3022] for the definition of NAT (commonly named NAT44)" or similar. BTW, thanks for fixing NAT66 into NPTv6 ;-) ## Sections 6.23.2 and 6.24.2 Suggest removing the reference to RFC 791 & 3234 as they are neither related to NAT nor used in the IANA registry. # NITS (non-blocking / cosmetic) ## Section 5 I am just puzzled by the order of the rows in table 1, it looks neither logical nor alphabetical. ___ OPSAWG mailing list -- opsawg@ietf.org To unsubscribe send an email to opsawg-le...@ietf.org
[OPSAWG]Éric Vyncke's No Objection on draft-ietf-opsawg-mud-tls-15: (with COMMENT)
Éric Vyncke has entered the following ballot position for draft-ietf-opsawg-mud-tls-15: 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-tls/ -- COMMENT: -- # Éric Vyncke, INT AD, comments for draft-ietf-opsawg-mud-tls-15 Thank you for the work put into this document. Please find below some non-blocking COMMENT points (but replies would be appreciated even if only for my own education), and one nit. Special thanks to Thomas Fossati for the 18-month old shepherd's detailed write-up including the WG consensus and a *very light* justification of the intended status. Other thanks to Miek Gieben, the Internet directorate reviewer, please consider this int-dir review: https://datatracker.ietf.org/doc/review-ietf-opsawg-mud-tls-15-dnsdir-telechat-gieben-2024-07-27/ (alas there is still no mention to RFC 7858 in this revision even after Tiru's 2024-07-29 email) I hope that this review helps to improve the document, Regards, -éric # COMMENTS (non-blocking) ## Section 12.2 Please fix this, there are 2 normative references listed for RFC 6234 & 5869 that are not used at all, i.e., remove all unused references (per idnits tool). ## Section 1 Like observed by Roman, using an 8-year old reference as the foundation of this document may indicate that this document may be useless in 2024. In `Specifically, malware may not use the DoH server provided by the local network` please add references to ADD RFC. Humm, I wonder why there is "mud" in the I-D title if the document contains `This is superior to the layers 3 and 4 ACLs of Manufacturer Usage Description Specification (MUD)` ;-) ## Section 3 "middlebox" is used but not specified in this document, suggest using the right MUD terminology. The ambiguous "middlebox" also appears in other sections. Is ` end-of-life of a device` linked to ` IoT manufacturer no longer supports the device`, I guess so but this is not clear at all. Please add a reference to "Slowloris". ## Section 5.2 As some IoT devices won't ever be updated, should the YANG module also support *obsoleted* TLS versions ? A very contentious decision of course but I would prefer to support it than ignoring old devices. # NITS (non-blocking / cosmetic) ## Section 7 The example includes `2019-18-06T` could it be refreshed to 2024 ? ___ OPSAWG mailing list -- opsawg@ietf.org To unsubscribe send an email to opsawg-le...@ietf.org
