Re: [OPSAWG] New I-D -> Guidelines for Charactering "OAM"

[Carlos Pignataro <[e-mail]>]

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 <[e-mail]>
wrote:

>
> Carlos Pignataro <[e-mail]> 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 <[e-mail]>   . o O ( IPv6 IøT consulting )
>            Sandelman Software Works Inc, Ottawa and Worldwide
>