Hi Qin, Thanks for the comments. We believe they are address in version 13: https://datatracker.ietf.org/doc/draft-ietf-opsawg-oam-characterization/13
Please see below. On Tue, Sep 30, 2025 at 5:13 AM Qin Wu <[email protected]> wrote: > > Hi, authors: > I have read the latest version of draft-ietf-opsawg-oam-characterization and > have the following comments for your consideration: > > 1. Section 2, Paragraph 4 said: > " > These two examples, as well as other examples > of uses of the term "in-band" in previous documents are described > throughout Section 3. > " > [Qin]: Which previous documents? RFC5085 and RFC9551 in this paragraph or > documents in the previous paragraph in section 1, > My understanding is the former, but not sure this is clear to everybody. [TM] Rephrased. > > 2. Section 2, last paragraph said: > " > While interpreting existing documents, it is important to understand > the semantics of what "band" is a proxy for , and to be more explicit > if those documents are updated. > " > [Qin]: I am wondering whether proxy has different meaning in different > context, > s/a proxy for/stands for [TM] Rephrased. > > 3.Section 3.4, paragraph 3, last bullet > [Qin]: It looks inferred mode and direct mode are two new term related to > OAM, I am > wondering how inferred mode is related to Direct measurement, Inferred > Measurement, > How Direct mode is related to Direct measurement, Inferred Measurement. > > Secondly, how direct measurement is related to in data packet oam? How > inferred > measurement is related to active OAM and Hybrid OAM. > I think this paragraph lacks clarity about this. [TM] Rephrased. > > 4. Section 3.4, last 2nd paragraph: > " > The first sentence is not consistent with the second sentence. In the first > sentence, you are > using measurement protocol, in the second sentence, you are using other OAM > protocol. > " > [Qin]: The first sentence is not consistent with the second sentence. In the > first sentence, > you are using measurement protocol, in the second sentence, you are using > other OAM protocol. > [TM] Rephrased. > 5.Appendix A, last paragraph: > [Qin]: Suggest to add reference to RFC8655 for the term PREOF treatment. > Also suggest to add expanded name for PREOF > "Packet Replication, Elimination, and Ordering Functions” [TM] This sentence was quoted verbatim from RFC9551, and therefore it would be best to avoid changing the text or clarifying specific terminology. Thus, we suggest to leave it as-is. > > -Qin Thanks, The authors. > -----邮件原件----- > 发件人: Benoît Claise via Datatracker [mailto:[email protected]] > 发送时间: 2025年9月16日 15:47 > 收件人: [email protected]; > [email protected]; [email protected]; > [email protected] > 主题: [OPSAWG]WG Last Call: draft-ietf-opsawg-oam-characterization-12 (Ends > 2025-09-30) > > > Subject: WG Last Call: draft-ietf-opsawg-oam-characterization-12 (Ends > 2025-09-30) > > This message starts a 2-week WG Last Call for this document. > > Abstract: > As the IETF continues to produce and standardize different > Operations, Administration, and Maintenance (OAM) protocols and > technologies, various qualifiers and modifiers are prepended to the > OAM abbreviation. While, at first glance, the most used appear to be > well understood, the same qualifier may be interpreted differently in > different contexts. A case in point is the qualifiers "in-band" and > "out-of-band" which have their origins in the radio lexicon, and > which have been extrapolated into other communication networks. This > document recommends not to use these two terms when referring to OAM. > > This document considers some common qualifiers and modifiers that are > prepended, within the context of packet networks, to the OAM > abbreviation and lays out guidelines for their use in future IETF > work. > > This document updates [RFC6291] by adding to the guidelines for the > use of the term "OAM". It does not modify any other part of > [RFC6291]. > > File can be retrieved from: > https://datatracker.ietf.org/doc/draft-ietf-opsawg-oam-characterization/ > > Please review and indicate your support or objection to proceed with the > publication of this document by replying to this email keeping > [email protected] in copy. Objections should be motivated and suggestions to > resolve them are highly appreciated. > > Authors, and WG participants in general, are reminded again of the > Intellectual Property Rights (IPR) disclosure obligations described in BCP 79 > [1]. Appropriate IPR disclosures required for full conformance with the > provisions of BCP 78 [1] and BCP 79 [2] must be filed, if you are aware of > any. Sanctions available for application to violators of IETF IPR Policy can > be found at [3]. > > Thank you. > > [1] https://datatracker.ietf.org/doc/bcp78/ > [2] https://datatracker.ietf.org/doc/bcp79/ > [3] https://datatracker.ietf.org/doc/rfc6701/ > > > > _______________________________________________ > OPSAWG mailing list -- [email protected] > To unsubscribe send an email to [email protected] _______________________________________________ OPSAWG mailing list -- [email protected] To unsubscribe send an email to [email protected]
