Many thanks Michael for the review and useful feedback!
Please find some follow-ups inline.
On Sun, Jan 7, 2024 at 2:54 PM Michael Richardson
wrote:
>
> Carlos Pignataro wrote:
> > We would appreciate feedback and input on this position, which aims
> at
> > updating the guidelines for the "OAM" acronym, with unambiguous
> guidelines
> > for their modifiers.
>
> > Guidelines for Charactering "OAM":
> >
> https://datatracker.ietf.org/doc/draft-pignataro-opsawg-oam-whaaat-question-mark/
>
> > Look forward to input and comments to make this more clear and
> effective!
>
> Thank you for the interesting read.
> What do you want to do with this document?
> You say publish it to update RFC6291, but I wonder if revising 6291 might
> be
> better. In particular, SDN maybe has changed the landscape enough that not
> everyone still has the common understandings.
>
Thank you investing time in review and share feedback!
Our initial intention is to have this document published as a BCP updating
RFC6291 (a BCP), because the two documents are well demarcated in scope
(one about the noun, one about the adjective). RFC6291 stood the test of a
decade+, even without errata.
The more practical approach, considering the above, seems to progress this
document as an RFC and use the same BCP 161 (as RFC6291) -- not sure how to
signal that in the I-D.
Other thoughts?
>
> On this topic, RFC8994, we added qualifications "virtual out-of-band" and
> we
> debated a lot about whether it was in-band or out-of-band!!! Because the
> ACP
> is an overlay network, it is not tied up with the in-band traffic or
> addressing, but it is also not free from depending upon it.
>
And that is, indeed, the issue. On a separate off-list thread, we were
wondering if ICMP is out of band or in band, given different definitions
(in data plane, in packet flow)
Net-net: "there is no band" -- Neo.
And then different discussions and contexts mean different (incompatible)
things for "in-band".
Also RFC 8994 uses the M for Management instead of Maintenance (and this is
sensible to me since it's a management autoconfigured, authenticated,
secure layer, kinda)
for autonomic functions. It also serves as a "virtual out-of-band
channel" for Operations, Administration, and Management (OAM)
communications over a network that provides automatically configured,
>
> Path-Congruent is a nice technically accurate term.
> I'm just sure that congruent is a term that is easy to say. It's very
> grade
> 9 geometry class. ("Congruent triangles")
> Probably it's also the case the native english speakers, if they do not
> know
> the term well, will assume something inaccurate, while non-native speakers
> will go
> look it up.
>
Very open to other suggestions -- we opted for optimizing technical
accuracy in descriptiveness. (Carlos, a non-native English speaker, who
looks up words in his native languages too)
>
> Section 3 also has some nice new terms, and I suspect that they are really
> useful in a number of arenas, including up-coming proof-of-transit work.
>
Once again, indeed! PoT is another clear target in our mind.
>
> Nits:
> * OAM is not expanded in the introduction, and the RFC6191 reference needs
> to
> come earlier.
> * Section 2 starts off talking about history, and then gets into defining
> new
> terms. I thought I was going to learn more about in-band/out-of-band from
> a
> military radio point of view, and/or SS7 vs 2600Hz.
>
Thank you -- all fixed.
We'd welcome a citation from radio and/or SS7 telephony!
Thanks!
Carlos.
>
> --
> Michael Richardson. o O ( IPv6 IøT consulting )
>Sandelman Software Works Inc, Ottawa and Worldwide
>
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg
