Re: [OPSAWG] WG Adoption Call for draft-opsawg-evans-discardmodel-02
Hi Everyone, I also support adoption of this document. Thank you to the authors for accepting my suggestions for a small part of its content! -David ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
Re: [OPSAWG] A new draft on Network Incident Terminology
Dear Adrian and Davis, Nice! Thanks a lot for this document. I think it will help future documents to chose the correct terms and language. I reviewed and have some minor input. Regarding Change: A modification to the state of a resource in time. I believe it not only applies to a resource but also a network entity such a network path or a NRLI. Not only applying to management but also to control plane. From a Network Anomaly Detection perspective it might even stretch to an outlier, including also forwarding plane. See https://datatracker.ietf.org/doc/html/draft-netana-nmop-network-anomaly-semantics-00#section-2. Regarding Incident: An event that has a negative effect that is not as required/desired. For me an incident is one or more symptoms (https://datatracker.ietf.org/doc/html/draft-netana-nmop-network-anomaly-semantics-00#section-4). As you described, an event can be positive or negative. One or more negative event or measurement can lead into a symptom. See also https://datatracker.ietf.org/doc/html/rfc9418#section-2. Regarding Problem definition. I suggest to go towards the an objective or intend (https://datatracker.ietf.org/doc/html/rfc9315) is no longer fulfilled. Best wishes Thomas From: Adrian Farrel Sent: Thursday, January 18, 2024 4:15 PM To: ne...@ietf.org Cc: draft-opsawg-evans-discardmo...@ietf.org; draft-netana-opsawg-nmrg-network-anomaly-semant...@ietf.org; draft-feng-opsawg-incident-managem...@ietf.org; n...@irtf.org; 'Davis, Nigel' ; 'Ops Area WG' Subject: A new draft on Network Incident Terminology Be aware: This is an external email. All, At the side meeting in Prague, Nigel and I committed to putting together a first stab at a terminology set for network incidents. We have now posted a -00 draft. The intentions here are: * To provide a starting point for discussions of the terminology * To give something that can be edited and made correct * To end up with a set of terms that we can agree upon and use in all of our work We would be shocked if we have got this right on our first pass. We are sure that there will be many opinions, and we welcome suggestions for edits and proposals for changes. Although this email is circulated quite widely (including OPSAWG, NMRG, and NMOP (still masquerading as NETMO)), we believe that this work will end up in NMOP (if the WG is ever formed) and so we suggest that all responses and discussions be directed exclusively to the NETMO mailing list. Looking forward to a fruitful debate, Nigel and Adrian === Internet-Draft draft-davis-nmop-incident-terminology-00.txt is now available. Title: Some Key Terms for Incident Management Authors: Nigel Davis Adrian Farrel Name:draft-davis-nmop-incident-terminology-00.txt Pages: 5 Dates: 2024-01-18 Abstract: This document sets out some key terms that are fundamental to a common understanding of Incident Management. The purpose of this document is to bring clarity to discussions and other work related to Incident Management in particular YANG models and management protocols that report, make visible, or manage incidents. The IETF datatracker status page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-davis-nmop-incident-terminology/ There is also an HTML version available at: https://www.ietf.org/archive/id/draft-davis-nmop-incident-terminology-00.html smime.p7s Description: S/MIME Cryptographic Signature ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
Re: [OPSAWG] [mpls] New I-D -> Guidelines for Charactering "OAM" -review
Thank you Loa for your review, context, and comments! Please see inline. On Sat, Jan 20, 2024 at 12:53 AM wrote: > OPSAWG participants, Carlos, Adrian and Greg. > > As one of the co-authors RFC 6291 I agree that it makes sense to update > RFC 6291 in this way. > > In part, this draft is very close to what Greg and I tried to say in a > mail that we sent to some wg's. We saw a DETNET/RAW document that used the > acronyms iOAM and oOAM, and we found that this was too easy to confuse > with e.g. the widely used IOAM. > > We tried to recommend that we should use easily distinguishable acronyms, > I find that Adrian and Carlos do a much better job on this. > > Some notes: > > RFC 6291 is a BCP, which is the target status of this draft. Are there any > problems updating a BCP? > > The target is BCP as well, and a BCP can point to 2 RFCs. > In the introduction, I find: > >Additionally, this document recommends avoiding the creation and use of > extended acronyms for the qualifiers of "OAM". For example, the first > "O" in "OOAM" could mean out-of-band, overlay, or something else. > > If I understand correctly this leaves us with IOAM as an "extended > abbreviation", right? I hope you are planning to change that > abbreviation.. I hope you are not planning to change that. > > The RFC Editor talks about for example "IOAM" as abbreviations if there > are no strong reasons we should follow suit, i.e. avoid acronyms. > This is a good point, and IOAM is the only "OAM acronym" included in https://www.rfc-editor.org/materials/abbrev.expansion.txt I think while keeping the reco, we can acknowledge this pre-existing use. I added some text to this effect, let's see if this works. > > Section 2 in the document discusses "in-band" and "out-of-band", there are > several examples and I agree with the recommendation: > >The guidance in this document is to avoid the terms "*-band" and >instead find finer-granularity descriptive terms. > > However, there a simple search among IETF drafts shows that several > documents have "in-band" in the file name and also use "out-of-band" in > the text. There might be a substantial review required to enforce the > recommendation. Should we ask that the directorates put an instruction for > the directorate reviewers to try to capture this? > Another useful comment -- we feel that laying out and 'enforcing' recommendations going forward is the most effective approach, and indeed there are active I-Ds using "in-band" in the filename. At this point, as this document is also an I-D and not approved, highlighting this issue and suggesting a discussion on the relevant I-Ds as part of OpsDir review would be indeed an approach. Thanks! Carlos. > > The rest of the document seems fine to me. > > /Loa > > > > > Hi Adrian, > > thank you for your kind consideration of my notes. Please find my > follow-up > > notes below tagged by GIM>>. > > Regards, > > Greg > > On Fri, Jan 12, 2024 at 11:25 AM Adrian Farrel > wrote: > >> Hi Greg, > >> Thanks for your thoughtful inspection of our draft. > >> Carlos and I wanted to be sure that all of the discussions of this > draft > >> were indexed on one list, and we wanted to avoid multiple copies going > to > >> people who are subscribed to multiple lists. So we asked that > follow-ups > >> went only to OPSAWG. I have moved IPPM, MPLS, SPRING, and DetNet to BCC > on > >> this email. > > GIM>> Thank you. > >> It was certainly not our intent to disparage any work that was being > done > >> in any other working group, and I understand the effort that has gone > into > >> the DetNet OAM Framework to ensure that the terminology is clear and > unencumbered in the DetNet context. > >> Our concern was, however, that different contexts are applying > different > >> definitions of the terms “in-band” and “out-of-band”. Those > definitions are > >> (often) clear and precise, but they are not consistent across contexts. > Thus, a water-tight definition in the DetNet context is not universally > applicable, and a reader coming to DetNet from another context may > bring > >> with them their own understanding of the terms. > > GIM>> Although the wording in the DetNet OAM Framework is indeed > specific > > for DetNet environment, for example, the reference to DetNet service > sub-layer and PREOF, the authors and the WG strived to make the > > definitions > > generic. I believe that we achieved a reasonable level of generality > because the interpretation of "in-band/out-of-band" terminology in RAW > OAM > > was based on our work in DetNet. I believe that it could be a reasonable > way of building common understanding through a discussion of existing > terms > > instead of fork-lifting and trying to invent something different that > has > > not been used by any WG. > >> Our intent, therefore, is to select a finer-grained set of terms that > have > >> universal applicability and that can be selected within a context > without > >> loss of generality. > >
[OPSAWG] draft-ietf-opsawg-ipfix-tcpo-v6eh-08 shepherd review
Dear Med and Benoit, Thanks a lot. The document is very well written and straight forward. As shared previously during the working group, I believe this document is very valuable to network operators since it addresses current issues in the observation of IPv6 headers and TCP options. I have reviewed the document and wrote the initial shepherd review https://datatracker.ietf.org/doc/draft-ietf-opsawg-ipfix-tcpo-v6eh/shepherdwriteup/. I agree with the points from the IPFIX doctor and the Transport area in regards to the comments made to the data type choice for tcpOptionsFull, tcpSharedOptionExID16 and tcpSharedOptionExID32. Mirroring my concerns previously shared in the review of draft-ietf-opsawg-tsvwg-udp-ipfix with udpExpOptionExID and udpUnsafeExpOptionExID. I suggest to change the sentence from "Because some of these limitations cannot be addressed" to "Because some of these issues cannot be addressed" which is used in several occasions in the document. I suggest in section 3.1, to extend the paragraph Regarding "exported in separate ipv6ExtensionHeadersFull IEs" described in Section 3.1, I assume this refers to Section 8 of RFC 7011 (https://datatracker.ietf.org/doc/html/rfc7011#section-8) where If an Information Element is required more than once in a Template, the different occurrences of this Information Element SHOULD follow the logical order of their treatments by the Metering Process. Is described. If yes, I suggest to reference. If not, to clarify the meaning within the document. Here are some nits I found. replace headerss with headers replace octers with octets Otherwise all perfect. Best wishes Thomas smime.p7s Description: S/MIME Cryptographic Signature ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
