[OPSAWG] Zaheduzzaman Sarker's Discuss on draft-ietf-opsawg-l3sm-l3nm-11: (with DISCUSS and COMMENT)
Zaheduzzaman Sarker 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: -- This specification refers to ietf-opsawg-vpn-common for qos related matching, hence I am raising similar discussion as I had for ietf-opsawg-vpn-common (see here https://datatracker.ietf.org/doc/draft-ietf-opsawg-vpn-common/). This specification specifies qos classification based on L4 criteria and describes the procedure for TCP and UDP. It is possible that new L4 protocols (for example QUIC) use UDP as substrate hence can create ambiguity based of the procedure described in the specification. This specification should consider such potential substrate usage of L4 protocols (specially UDP) and hint on the potential augmentations (there might be several ways to do that) or scope it down to not support such cases. -- COMMENT: -- Thanks to the authors for their efforts in the specification. Additional comment(s)- * I think if would be good if this specification also discusses the implication of wrong classification (e.g. for qos) based on the model specified here (no particular suggestion from me where but may be in security considerations). ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
[OPSAWG] Zaheduzzaman Sarker's Discuss on draft-ietf-opsawg-vpn-common-10: (with DISCUSS and COMMENT)
Zaheduzzaman Sarker has entered the following ballot position for draft-ietf-opsawg-vpn-common-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/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/ -- DISCUSS: -- I would like to discuss the extensibility of the model as described in section 3 regarding 'qos-classification-policy' when UDP is used as substrate. See more in my comments bellow. -- COMMENT: -- Thanks to the authors for working on this specifications and addressing TSVART review comments. Thanks Wesley Eddy for your TSVART reviews. Comments - * In this specification, UDP match criteria is described and claimed that the model can be augmented to include more L4 transport protocols. QUIC (RFC9000) is a new L4 transport protocol and uses UDP as substrate. For such L4 transport protocols, it might be ambiguous to apply qos classification policy based on what is defined here. In case of QUIC, it needs to identify from other UDP traffic that is traversing the network. Read more on QUIC traffic identification here ( https://quicwg.org/ops-drafts/draft-ietf-quic-manageability.html#name-identifying-quic-traffic). I think this specification should consider such potential substrate usage of L4 protocols (specially UDP) and hint on the potential augmentations (there might be several ways to do that) or scope it down to not support such cases. * May be the commented text in the section 4 for protocol identifiers should be updated to reflect what is describes in the section 3 for "underlay-transport". Section 3 talks about underlay transports and how they are set. ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
[OPSAWG] Zaheduzzaman Sarker's No Objection on draft-ietf-opsawg-l2nm-18: (with COMMENT)
Zaheduzzaman Sarker 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: -- Thanks for addressing my discuss comments. I think I got what I wanted to achieve with the Discuss.. that is to see whether those references are conscious choicee or oversights. Hence, I am clearing by discuss. I, however, think it will be great if the authors ( along with AD) can go through the document again and make sure references are correctly categorized. ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
[OPSAWG] Zaheduzzaman Sarker's Discuss on draft-ietf-opsawg-l2nm-18: (with DISCUSS)
Zaheduzzaman Sarker has entered the following ballot position for
draft-ietf-opsawg-l2nm-18: 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-l2nm/
--
DISCUSS:
--
Thanks for the effort to produce this YANG model, I always fascinate by the
work done in creating the YANG models.
I have found inconsistencies in the classification of normative references and
informative references, hence, would like to discuss those. Some examples below-
- in the terminology section while [RFC6241], [RFC7950], [RFC8466], [RFC4026],
and [RFC8309] are normative references, [RFC8969] and [RFC8340] are not. But
clearly this document uses terms defined in those documents and I as a reader
had to open those RFCs to understand what the terms are and without that I
would not be possible to understand this document.
- sometimes the this document is correctly referring to other documents as
normative, as terms or processes are defines there but sometimes it is not. for
example -
'signaling-option':
Indicates a set of signaling options that are specific to a given VPN network
access, e.g., a CE ID ('ce-id' identifying the CE within the VPN) and a remote
CE ID as discussed in Section 2.2.2 of [RFC6624].
Now, without understanding what is discussed or defined in RFC6624 it was hard
for me to understand the node/leaf mentioned in this document. Thus, I felt
RFCC6624 should be a normative reference but it was not.
- The reference modules from this document cannot be informative reference, can
they? For example in section 8.1 it says -
This module references [RFC3032], [RFC4446], [RFC4448], [RFC4553],
[RFC4618], [RFC4619], [RFC4717], [RFC4761], [RFC4816], [RFC4842], and
[RFC5086].
however, RFC4842 and RFC5086 is informative reference.
I would say, please go through the document and correctly categorise all the
references.
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg
[OPSAWG] Zaheduzzaman Sarker's No Objection on draft-ietf-opsawg-sap-14: (with COMMENT)
Zaheduzzaman Sarker has entered the following ballot position for draft-ietf-opsawg-sap-14: 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-sap/ -- COMMENT: -- Thanks for working on this specification. I must say, without the right context and knowledge about network topology in this context it is very hard to follow figure 3. A description of the figure or reference of the document one should read to understand the topology would be a great help. ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
[OPSAWG] Zaheduzzaman Sarker's No Objection on draft-ietf-opsawg-tlstm-update-12: (with COMMENT)
Zaheduzzaman Sarker 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: -- Thanks for working on this specification. Special thanks for the shepherd's write-up, it was very helpful. I was just wondering - as there is an intended impact on the future here, "Renegotiation of sessions is not supported as it is not supported by TLS 1.3." what is the intended implication on the application of future versions of TLS? ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
[OPSAWG] Zaheduzzaman Sarker's No Objection on draft-ietf-opsawg-sbom-access-15: (with COMMENT)
Zaheduzzaman Sarker has entered the following ballot position for draft-ietf-opsawg-sbom-access-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-sbom-access/ -- COMMENT: -- Thanks for working on this specification. I also stumbled upon "sbom" and "vuln" nodes in section 1.2. I assumed these refers to the nodes in the YANG tree sbom node = starts with sbom- and vuln node = starts with vuln- yes that I had to guess to continue reading. Now I see Roman has a discuss on this point hence supporting the discuss. I believe evenif it might be a convention call those node as I assumed, we could be more clear by actually describing the notion in the doc. And if my assumption is wrong then we definitely need to describe the nodes so that readers like me don't make wrong assumption :-). ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
[OPSAWG] Zaheduzzaman Sarker's No Objection on draft-ietf-opsawg-mud-iot-dns-considerations-12: (with COMMENT)
Zaheduzzaman Sarker 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: -- No objection from transport layer specific issues, however, this was not a easy read for me. It often convolutes process steps with practice, issues and recommendations, hence hard to follow. I strongly support Paul's discuss points. I have following comments/questions and I believe the document will be enriched if those are addressed: - Abstract : it says - This document details concerns about how Internet of Things devices use IP addresses and DNS names. I am with the impression that these concerns are not for the entire community of IoT devices, rather for those uses MUD and wanted to use DNS. Also detailing only concerns does not seem the entire goal of this document. Why does the document start with such statement? - Please define "antipattern" in this document. I understand it comes from an external source, any day that definition can change and the usage of "antipattern" in this document may become out of context. It is better to agree on what the "antipattern" means in the context of this document. - Section 1 : This references to sections to describe particular things and that reference does not map to the section numbers of this document. I think there is not need to such calling out of sections in the introduction, it is confusing. - Section 1 : The third section of this document details how current trends in DNS resolution such as public DNS servers, DNS over TLS (DoT), DNS over QUIC (DoQ), and DNS over HTTPS (DoH) cause problems for the strategies employed. Where can I find the promised details? DoQ is only mentioned once in later sections. - Section 6: - Please explain the geofenced name before providing recommendations for it. - How should the manufacturers interpret "strong recommendation" ? Is there any particular reason not to use normative text here? ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
