Adrian, Thank you for your careful reply. A few acks/replies are inline below; the only open questions are #1 for Qin and #6 if changes are needed in Section 3.2. The revised files are here (please refresh): https://www.rfc-editor.org/authors/rfc9940.html https://www.rfc-editor.org/authors/rfc9940.txt https://www.rfc-editor.org/authors/rfc9940.pdf https://www.rfc-editor.org/authors/rfc9940.xml
This diff file shows all changes from the approved I-D: https://www.rfc-editor.org/authors/rfc9940-diff.html https://www.rfc-editor.org/authors/rfc9940-rfcdiff.html (side by side) This diff file shows the changes made during AUTH48 thus far: https://www.rfc-editor.org/authors/rfc9940-auth48diff.html https://www.rfc-editor.org/authors/rfc9940-auth48rfcdiff.html (side by side) We will wait to hear from you again and from your coauthors before continuing the publication process. This page shows the AUTH48 status of your document: https://www.rfc-editor.org/auth48/rfc9940 Thank you. Alice Russo RFC Production Center > On Feb 24, 2026, at 4:19 AM, Adrian Farrel <[email protected]> wrote: > > Hi Alice, > > Thanks for the work. > A bit of push-back on some of the suggestions, below, largely because this > document was a fine balancing act of consensus and explanation. But, most of > your points are just sloppy authorship. > > > 1) <!-- [rfced] Authors' Addresses: We see that Qin Wu's affiliation is > listed as Huawei in this document. Please confirm that this is as desired. > We ask because we see that Qin Wu's affiliation is mostly listed as Huawei > after RFC 9000, but as "Huawei Technologies" in RFCs 9005, 9353, 9358, and > 9731. --> > > [AF] I'll let Qin comment, but what I see is that all recent I-Ds list as > "Huawei" and that a few RFCs that have roots in old I-Ds use "Huawei > Technologies". > The weirdness in this document is that Chaode has used "Huawei Technologies" > although he is in a different division of Huawei, so who knows! > > 2) <!-- [rfced] Section 1: Please clarify the meaning of this sentence, > especially how the phrase "and other faults" relates to the rest > of the sentence. > > Original: > The intention of this document is to focus on those events that have a > negative effect on the network's ability to forward traffic according > to expected behavior and so deliver services, the ability to control > and operate the network, and other faults that reduce the quality or > reliability of the delivered service. > > Option A: > The intention of this document is to focus on those events that could > have a negative effect on the network's ability to forward traffic > according to expected behavior and so could negatively affect > delivery of services and the ability to control and operate the > network. Such events could also trigger other faults that would > reduce the quality or reliability of the delivered service. > > Option B: > The intention of this document is to focus on those events that have a > negative effect on the network's ability to forward traffic according to > expected behavior and thus its ability to deliver services, provide the > ability to control and operate the network, and manage faults that would > reduce the quality or reliability of the delivered service. > > Option C: > This document focuses on events that have a negative effect on > traffic forwarding, service delivery, and network management, > especially when managing faults that reduce the quality or reliability > of the delivered service. > --> > > [AF] Yeah, you're right. Too much nesting; too many "and"s. > > Try... > > The intention of this document is to focus on those events that have a > negative effect on the network's ability to forward traffic according > to expected behaviors which may reduce the network's ability to > deliver services. Such events may also impact upon the ability to > control and operate the network. The document also considers other > faults that reduce the quality or reliability of the delivered service. > [AR] updated accordingly, with minor changes as follows. s / impact upon the ability / impact the ability s / which may reduce / that may reduce (due to RPC style -- restrictive "that" and non-restrictive "which" clauses) > 3) <!-- [rfced] Section 3.1: > > a) FYI, we capitalized "layer 3, layer 2, and layer 1" to > "Layer 3, Layer 2, and Layer 1", per more common usage in RFCs > after RFC 6000. > > [AF] OK > > b) Is "intent" the only type of service definition (in which case > "i.e.," ("that is") is correct), or should "i.e.," be "e.g.," ("for > example")? > > Original: > Network Telemetry: This is defined in [RFC9232] and describes the > process of collecting operational network data categorized > according to the network plane (e.g., layer 3, layer 2, and layer > 1) from which it was derived. Data collected through the Network > Telemetry process does not contain any data related to service > definitions (i.e., "intent" per Section 3.1 of [RFC9315]). --> > > [AF] I think id est is correct. > > 4) <!-- [rfced] Section 3.1: Should "network monitoring" be "Network > Monitoring" > in this paragraph, to match other comparable terms mentioned in Sections > 2 and subsequent? Also, we see "through the Network Telemetry process" > in the previous paragraph (i.e., initial capitals applied again after the > term has been defined). > > Original: > Network Monitoring: This is the process of keeping a continuous > record of functions related to a network topology. It involves > tracking various aspects such as traffic patterns, device health, > performance metrics, and overall network behaviour. This approach > differentiates network monitoring from resource or device > monitoring, which focuses on individual components or resources > (Section 3.2). --> > > [AF] I could go either way on this. Happy to capitalise. [AR] updated accordingly. > > 5) <!-- [rfced] Section 3.1: > > a) Does "and to identify" refer to the Network Observability process > or the analysis of the data? > > Original: > Network Observability: This is the process of enabling network > behavioral assessment through analysis of observed operational > network data (logs, alarms, traces, etc.) with the aim of > detecting symptoms of network behavior, and to identify anomalies > and their causes. > > Perhaps (the process): > Network Observability: This is the process of enabling network > behavioral assessment through analysis of observed operational > network data (logs, alarms, traces, etc.); this process aims to > detect symptoms of network behavior and to identify anomalies > and their causes. > > Or possibly: (the analysis): > Network Observability: This is the process of enabling network > behavioral assessment through analysis of observed operational > network data (logs, alarms, traces, etc.); such analysis aims to > detect symptoms of network behavior and to identify anomalies > and their causes. > > [AF] Ouch! > Either s/and to identify/and identifying/ > Or you "Perhaps" option. [AR] updated to 'and identifying'. > > b) May we update this sentence as follows to clarify "and that"? > > Original: > Network Observability begins with information > gathered using Network Monitoring tools and that may be further > enriched with other operational data. > > Perhaps: > Network Observability begins with information > gathered using Network Monitoring tools, then it > may be further enriched with other operational data. --> > > [AF] Hmmm. It is the information that may be further enriched. Perhaps: > Network Observability begins with information > gathered using Network Monitoring tools. That information may be > further enriched with other operational data. > > 6) <!-- [rfced] Section 3.2: For parallelism in the list provided > in this section, we made several updates to the definition > paragraphs (the top-level items). For consistency of style, we went > with sentence fragments instead of complete sentences. Please > review, and let us know any updates. --> > > [AF] Well, hmmm, you have created some non-sentences, I think. For example: > In the context of Network Monitoring, the variation in the > Value of a Characteristic associated with a Resource. > Do we not prefer to write in complete sentences? > But, I do note that the original was culpable of this as well, so hey-ho? [AR] hey-ho, indeed. Happy to revert to original or update each to a complete sentence (which leads to some repetition, e.g., "Foo: A Foo is a lovely thing."). Please let us know your preference. > > I checked the semantics, and I don't think this change is a problem except: > > "Detect". Retaining the sub-bullet would be preferred because it is a > significant difference from the main definition. I'd be happy to s/Hence > also/Also/ in the sub-bullet if that helps. > [AR] updated accordingly. > "Occurrence" I'll be led by you on fine-grain/fine-grained. I thought: > This piece of sand is a fine-grain particle. > This is a handful of fine-grained particles. [AR] If the intended meaning is 'concerned with or using small details' [1], the one instance in this document seems fine: * An Occurrence may be an aggregation or abstraction of multiple fine-grained Events or Changes. [1] This definition is from https://dictionary.cambridge.org/us/dictionary/english/fine-grained because the Merriam-Webster definition is not useful ("characterized by comparatively fine graininess"). > > 7) <!-- [rfced] Sections 3.2 and 4: We see one instance of "network > system" in Section 3.2 but two instances of "Network system" in > Section 4. Because this term isn't specifically defined anywhere, > may we change the "between Network system and Resources" text in > Section 4 to "between a network system and Resources", and may we > change "Network system" in Figure 1 to "Network System"? > > Original: > Resource: An element of a network system. > ... > Note that there is a 1:n relationship between Network > system and Resources, and between Resources and Characteristics: this > is not shown on the figure for clarity. > ... > Network system --> > > [AF] I think 3.2 is right as "network system": it is not a defined term, just > text. > I think Figure 1 stays as "Network system" because lower case in the figure > would look wrong. > The question is only whether the text in 4 should match the figure (as > original) or be normal text (with lower case). > The author chose to match the figure for clarity. > You choose. [AR] I agree with matching the figure. No change made. > > 8) <!-- [rfced] Section 3.2: For consistency of style, we put > "Resource is a recursive concept" under "Resource:" in a <ul>, > as was done for the rest of the definitions in this section with > nested paragraphs. Please let us know if you prefer otherwise. > > Original: > Resource: An element of a network system. > > Resource is a recursive concept so that a Resource may be a > collection of other Resources (for example, a network node > comprises a collection of network interfaces). > > Currently: > Resource: An element of a network system. > > * Resource is a recursive concept so that a Resource may be a > collection of other Resources (for example, a network node > comprises a collection of network interfaces). --> > > [AF] Fine > > 9) <!-- [rfced] Section 3.2: > > a) We see only two instances of single-quoted items in this > document and see double quotes used for all other terms (e.g., > "Value Change"). May we use double quotes instead for these two > items, i.e., change 'Value' to "Value" and 'variable' to "variable" > here? > > [AF] Yes. That was sloppy. Sorry. > > b) We see "metric" used in the text of RFC 9417, which uses "Metric" > only in three definitions and its Figure 1. May we lowercase this > term in this document to match RFC 9417, as it's only used as a term > in this one bullet item? > > Original: > * A Characteristic may be considered to be built on facts (see > 'Value', below) and the contexts and descriptors that identify > and give meaning to the facts. > > * The term "Metric" [RFC9417] is another word for a measurable > Characteristic which may also be thought of as analogous to a > 'variable'. > > Perhaps: > * A Characteristic may be considered to be built on facts (see > "Value", below) and the contexts and descriptors that identify > and give meaning to the facts. > > * The term "metric" [RFC9417] is another word for a measurable > Characteristic, which may also be thought of as analogous to a > "variable". --> > > [AF] Nope. Please leave "Metric" as a definition that this document is > providing. But this could change to: > * The term "Metric" (see "metric" in [RFC9417]) is another word for a > measurable > Characteristic which may also be thought of as analogous to a > "variable". [AR] updated accordingly. > > 10) <!-- [rfced] Sections 3.2 and 4: We see "a count" in Section 3.2 but > "the Count" in Section 4. Should capitalization of this term be made > consistent? If yes, please specify which form is preferred. > > Original: > It may be in the form of a categorization (e.g., high > or low), an integer (e.g., a count or gauge), or a reading of a > continuous variable (e.g., an analog measurement), etc. > ... > Events may be counted, and the Count may > cross a threshold or reach a Relevant Value. --> > > [AF] Ugh. > I think that 3.2 is right. There is no term defined here for "Count" and this > is just a normal word (like "gauge") > In 4, we have the same problem of matching the text to the figure. Using > lower case in the figure would look odd. And so the text uses the same > capitalisation to easily map to the figure. > I'd leave it alone, but can be guided by you. [AR] Agree. Left alone. > > 11) <!-- [rfced] Section 3.2: Is the period (of time) always negligible, > or should "i.e.," be "e.g.," here? > > Original: > Event: The variation in Value of a Characteristic of a Resource at a > distinct moment in time (i.e., the period is negligible). --> > > [AF] Definitely "i.e." because it is explaining what "a distinct moment in > time" means. > > 12) <!-- [rfced] Section 3.2: RFC 8342 uses the lowercase form > "operational state". Because this sentence says "as used in > [RFC8342]", would you prefer to follow usage in RFC 8342 or leave > both "Operational State" and "operational state" as they are in this > paragraph? > > Original: > * This term may be contrasted with "Operational State" as used in > [RFC8342]. For example, the state of a link might be up/down/ > degraded, but the operational state of link would include a > collection of Values of Characteristics of the link. --> > > [AF] Good catch. > Lower case, but retain quote marks. [AR] Updated accordingly. > > 13) <!-- [rfced] Section 3.2: We had trouble following this sentence. > Should "relative to a specific perspective, intent, ..." be > "relative to a specific perspective, with a view to intent, ..." > per text seen twice in Section 4? If not, what do "relative to a > specific perspective" and "and in relation to other Events ..." refer > to? > > Original: > Relevance: Consideration of an Event, State, or Value (through the > application of policy, relative to a specific perspective, intent, > and in relation to other Events, States, and Values) to determine > whether it is of note to the system that controls or manages the > network. --> > > [AF] Sorry. I would blame Nigel, but I edited the text. Try... > Relevance: Consideration of an Event, State, or Value (through the > application of policy, relative to a specific perspective or intent, > and in relation to other Events, States, and Values) to determine > whether it is of note to the system that controls or manages the > network. [AR] updated accordingly. > > 14) <!-- [rfced] Section 3.2: Does "and may be perceived" refer to the > Occurrence or the Resources in this sentence? If "Resources", we > suggest inserting "they". > > Original: > * An Occurrence may occur at any macro or micro scale because > Resources are a recursive concept, and may be perceived > depending on the scope of observation (i.e., according to the > level of Resource recursion that is examined). That is, > Occurrences, themselves are a recursive concept. --> > > [AF] Applies to the occurrence. Could split the sentence as: > s/, and may/. An Occurrence may/ > [AR] updated accordingly. > 15) <!-- [rfced] Section 3.2: We see that > [I-D.ietf-nmop-network-incident-yang] uses (mostly) "network > incident", "customer incident", and "incident management", while > this document uses initial-capitalized forms for these terms. > > Would you (perhaps Qin Wu or Nigel Davis, as coauthors of this > document as well as [I-D.ietf-nmop-network-incident-yang]) like to > suggest that the initial-capitalized forms of these terms also be > used in [I-D.ietf-nmop-network-incident-yang]? We see that this > document is listed in the Informative References of that document. > > Original: > Incident: A (Network) Incident is an undesired Occurrence such as an > unexpected interruption of a network service, degradation of the > quality of a network service, or the below-target performance of a > network service. An Incident results from one or more Problems, > and a Problem may give rise to or contribute to one or more > Incidents. Greater discussion of Network Incident relationships, > including Customer Incidents and Incident management, can be found > in [I-D.ietf-nmop-network-incident-yang]. --> > > [AF] Yeah, let's leave this document as it is, and prod the authors of (the > vastly inferior ;-) draft-ietf-nmop-network-incident-yang [AR] Sounds good. > > 16) <!-- [rfced] Section 4: It seems odd that Figure 6 is mentioned before > Figure 2 appears and before any mention of Figure 3. Would you like > to move Figure 6 so that it appears just after Figure 2? It would > then be renumbered as Figure 3, and the rest of the figures would be > renumbered accordingly. > > Original: > In practice, the Characteristic may vary in an analog manner over > time as shown on the right-hand side of Figure 2. The Value can be > read or reported (i.e., Detected) periodically leading to analog > Values that may be deemed Relevant Values, or may be evaluated over > time as shown in Figure 6. > > ( Contents of Figure 2 ) > > Figure 2: Characteristics and Changes > > Figure 3 shows the workflow progress for Events. As noted above, an > > Perhaps: > In practice, the Characteristic may vary in an analog manner over > time as shown on the right-hand side of Figure 2. The Value can be > read or reported (i.e., Detected) periodically leading to analog > Values that may be deemed Relevant Values, or it may be evaluated > over time as shown in Figure 3. > > ( Contents of Figure 2 ) > > Figure 2: Characteristics and Changes > > ( Contents of Figure 3 ) > > Figure 3: Counts, Thresholds, and Values > > Figure 4 shows the workflow progress for Events. As noted above, an --> > > [AF] Moving Figure 6 would, I think really disrupt all of the exposition of > terms. > Revealing the terms in some kind of sequence was a bit of a challenge. > You could put "or may be evaluated over time as shown in Figure 6." In > parentheses if that helps. [AR] Ack; left as is. > > 17) <!-- [rfced] Figures 2 and 6: We see "Change at a time" and "Change > over time" in Figure 2 but "Change at a Time" and "Change over Time" > in Figure 6. Would you like capitalization to be consistent? > If yes, please specify which style is preferred. > > If you'd like to title case, may we change "Evaluated over > time" in Figure 6 to "Evaluated over Time"? > > Original: > Change at a time Change over time Change over time > ... > | Evaluated | > | over time | > ... > Change at a Time Change over Time --> > > [AF] I don't object to Title case in Figure 2, although I don't think it is > crucial. > Figure 6 is correct in the original because it is not a title, but a thing > that feeds into an arrow on the figure. [AR] Ack; no changes. > > 18) <!-- [rfced] Section 4: This sentence does not parse. If the > suggested text is not correct, please clarify. > > Original: > An Occurrence may be undesirable (a > Fault) and that can cause an Alert to be generated, may be evidence > of a Problem and could directly indicate a Cause. > > Perhaps: > An Occurrence may be undesirable (a > Fault); this can cause an Alert to be generated, may be evidence > of a Problem, and could directly indicate a Cause. --> > > [AF] Sigh ;-) > We have: > An Occurrence > - may be undesirable > - that is, a Fault > - and so might cause an Alert to be generated > - may be evidence of a Problem > - and could directly indicate a Cause. > > So, perhaps: > An Occurrence may be undesirable (a > Fault) which might cause an Alert to be generated. Or an > Occurrence may be evidence of a Problem that could directly > indicate a Cause. [AR] updated as follows: An Occurrence may be undesirable (a Fault), which might cause an Alert to be generated. Or, an Occurrence may be evidence of a Problem and could directly indicate a Cause. (minor changes include "that" -> "and" (to match the outline above) and a comma before "which" due to RPC style -- restrictive "that" and non-restrictive "which" clauses) > > 19) <!-- [rfced] Section 4: Is there a distinction between > "may be deemed a Problem" and "may indicate a Problem", as > they seem to be very close in meaning. Will this sentence be > clear to readers? > > Original: > A Relevant State may be deemed a Problem, or may indicate a > Problem or potential Problem. --> > > [AF] Yeah, closely debated text. > It may, of itself, be a Problem. Or it may indicate that a Problem exists. > We could s/may be deemed/may, itself, be/ > Although I would tend to leave it. > (Note for English speakers: "problem" is not "Problem" :-) [AR] Ack; no changes. > > 20) <!-- [rfced] Section 4: Should "Alarmed state" be "Alarm State" here? We > ask > because we see "an Alarm signifies an undesirable" State" in Section 3.2. > > Original: > An Alarm may be raised as the result of a Problem, and the transition > to an Alarmed state may give rise to an Alert. --> > > [AF] Ha! > s/Alarmed state/alarmed State/ [AR] updated accordingly. > > 21) <!-- [rfced] Section 4: > > a) We see "threshold" but "Threshold Process" in these two > paragraphs. Because "threshold" is not a term defined in this > document, we suggest the lowercase form "threshold process" in > the text, but please advise. > > Original: > Figure 6 shows how thresholds are important in the consideration of > analog Values and Events. The arrows in the figure show how one item > may give rise to or utilize another. The use of threshold-driven > Events and States (and the Alerts that they might give rise to) must > be treated with caution to dampen any "flapping" (so that consistent > States may be observed) and to avoid overwhelming management > processes or systems. Analog Values may be read or notified from the > Resource and could transition a threshold, be deemed Relevant Values, > or evaluated over time. Events may be counted, and the Count may > cross a threshold or reach a Relevant Value. > > The Threshold Process may be implementation-specific and subject to > policies. When a threshold is crossed and any other conditions are > matched, an Event may be determined, and treated like any other > Event. > > [AF] Again, this is me trying to match the text to the items in the figure. > I think it is convenient to make that highlight by using UC. [AR] agree; no change. > > b) We had trouble following the purpose of the comma after > "determined" here. We removed it, per "Specific Changes in Value may > be noticed at a specific time (as digital Changes), Detected, and > treated as Events" seen earlier in this section. If this is > incorrect, please clarify what "may" refers to in this sentence. > > Also, should "conditions" be "Conditions" here, as we see "give rise > to Conditions that are States" in the second paragraph after > Figure 1? > > Original: > When a threshold is crossed and any other conditions are > matched, an Event may be determined, and treated like any other > Event. > > Currently (guessing "may be treated" as opposed to "will be treated" > or otherwise): > When a threshold is crossed and any other conditions are > matched, an Event may be determined and may be treated like any other > Event. --> > > [AF] The comma is a bad edit (was a serial comma, but the list dropped to two > items). Remove it. > Not sure we need the double "may" because inherited from the first one, but > it is OK. > Yup, "Condition" is better. [AR] updated accordingly. > > 22) <!-- [rfced] Acknowledgments: Should Dirk Hugo be listed here as "Dirk > Von > Hugo"? We ask because we see a "Dirk Von Hugo" listed in several post-6000 > RFCs > but not a "Dirk Hugo". Also, we see "Dirk Von Hugo" on > <https://datatracker.ietf.org/person/[email protected]>. > > Original: The authors would like to thank Med Boucadair, Wanting Du, Joe > Clarke, > Javier Antich, Benoit Claise, Christopher Janz, Sherif Mostafa, Kristian > Larsson, Dirk Hugo, Carsten Bormann, Hilarie Orman, Stewart Bryant, Bo Wu, > Paul > Kyzivat, Jouni Korhonen, Reshad Rahman, Rob Wilton, Mahesh Jethanandani, Tim > Bray, Paul Aitken, and Deb Cooley for their helpful comments. --> > > [AF] Oops. Yes, he is https://datatracker.ietf.org/person/Dirk%20Von%20hugo [AR] updated accordingly. > > 23) <!-- [rfced] Please review the "Inclusive Language" portion of the > online Style Guide at > <https://www.rfc-editor.org/styleguide/part2/#inclusive_language>, > and let us know if any changes are needed. Updates of this nature > typically result in more precise language, which is helpful for > readers. > > Note that our script did not flag any words in particular, but this > should still be reviewed as a best practice. --> > > [AF] I checked again. > > > Phew! > > Thanks. > Adrian > -- auth48archive mailing list -- [email protected] To unsubscribe send an email to [email protected]
