Re: [auth48] AUTH48: RFC-to-be 9262 <draft-ietf-bier-te-arch-13> for your review

[Toerless Eckert <[e-mail]>]

And of course, this is whats suposed to happen when i react quickly ;-),
i immediately change my mind.

Given how we explicitly define the "underlay" i think we can for BIER-TE
specifically call the topology the "underlay" topology. But given how
that would end up being a more strict term than "native" which is more loosely,
i may want to add some sentence about hybridge underlay/overlay topologies...

This of course does not change the overall problem of us not having a strategy
to change/avoid native in the future, so i would still appreciate if there
was somoe more strategic approach to the problem of replacing widely used
technical terms.

Cheers
    Toerless

On Fri, Sep 09, 2022 at 08:19:12PM +0200, Toerless Eckert wrote:
> Hi Lynne, Alvaro, *
> 
> a) Sorry for not having replied to the last set of questions, i got half through it
> and pulled into something with strict deadlines, should be avble to get back in the next days.
> 
> b) Wrt to replacing "native". I hereby reject to change the use of the word "native",
> and encourage you to use whatever form of escalation you feel is appropriate for this,
> whether it is simply overruling me or whatever process we have.
> 
> Reasoning: Simply looking at fairly recent 1000 RFC8xxx.txt, there are
> 113 RFC that have 487 instances of "native foobar", where foobar is a wide range of 
> IETF terms, ranging from topology, IP, multicast, MPLS, protocol, frame, etc. pp.
> And the rfc9xxx.txt series is similar.
> 
> I do not want to take responsibility of individually coming up with a non-widely-used,
> randomnly picked up replacement term for one single RFC, when native is so widely used,
> and therefore has such a high utility for our documents.
> 
> I think replacing the use of that term if it needs to be done anyhow (which i don't think)
> has to be done by broader consensus or executive decision making. And by introducing some
> mechanism to create similar consistency in terminology that we now have through the word
> native.
> 
> I am for example sure that Andrew would be happy to make an executive decision 
> (if he is entitled to) to not use native anymore in IETF documents given all the horrible
>  stories about how the use of the word native in any social context is highly problematic
> in Africa, but I certainly do not want to make any such decision, and i don't think it is appropriate
> to make this word change during AUTH48.
> 
> So, please escalate ccordingly, because this is already the second RFC in which this
> concern was raised, and we need to come to some conclusion of how to proceed.
> 
> I am happy to open a thread on [e-mail] or whereever you think is appropriate
> to bring this topic to a wider audience.
> 
> Cheers
>     toerless
> 
> On Fri, Sep 09, 2022 at 10:26:33AM -0700, Lynne Bartholomew wrote:
> > Hi, Alvaro and Toerless.
> > 
> > Toerless, please review Alvaro's notes below, and advise.
> > 
> > Thank you!
> > 
> > RFC Editor/lb
> > 
> > > On Aug 31, 2022, at 7:01 AM, Alvaro Retana <[e-mail]> wrote:
> > > 
> > > On August 30, 2022 at 2:35:55 PM, Lynne Bartholomew wrote:
> > >>> On Aug 26, 2022, at 11:23 AM, Toerless Eckert wrote:
> > > 
> > > 
> > > Lynne/Toerless:
> > > 
> > > Hi!
> > > 
> > > 
> > > I've been thinking about this point:
> > > 
> > >>> (64) [rfced] Please review the "Inclusive Language" portion of the
> > >>> online Style Guide at ,
> > >>> and let us know if any changes are needed. Aside from "native", our script
> > >>> did not identify problematic terms.
> > >>> 
> > >>> I could not find on those URLs a place where "native" was listed as
> > >>> problematic, where/what is the script you are using ?
> > > 
> > > I looked at several external references and found some discussions
> > > mostly about using "native" to refer to specific groups of people, and
> > > how to correctly do that.  But that doesn't apply here since the text
> > > is not referring to people.
> > > 
> > > 
> > > There are two places where "native" is used in the draft:
> > > 
> > >    If the BIER-TE topology represents (a subset of) the underlying
> > >    (Layer 2) topology of the network as shown in the first example, this
> > >    may be called a "native" BIER-TE topology.  A topology consisting
> > >    only of "forward_routed()" adjacencies as shown in the second example
> > >    may be called an "overlay" BIER-TE topology.  A BIER-TE topology with
> > >    both forward_connected() and forward_routed() adjacencies may be
> > >    called a "hybrid" BIER-TE topology.
> > > 
> > >    ...
> > > 
> > >    1.  Determine the desired BIER-TE topology for BIER-TE subdomains:
> > >        the native and/or overlay adjacencies that are assigned to
> > >        BPs.  Topology discovery is discussed in Section 3.2.1.1, and
> > >        the various aspects of the BIER-TE controller's determinations
> > >        regarding the topology are discussed throughout Section 5.
> > > 
> > > 
> > > 
> > > I agree with Toerless that there's no common well-known one-word
> > > replacement for "native".  The computing related term that is often
> > > suggested is "built-in", but that doesn't fit here.
> > > 
> > > 
> > > OTOH, I wonder if we can come up with an alternative based on the
> > > context, especially because there are only two occurrences and the
> > > second one refers to the definition of the first.
> > > 
> > > The differentiation between "native", "overlay", and "hybrid"
> > > topologies is the type of adjacencies: a "native topology" only has
> > > forward_connected() adjacencies.  I think we can call this type of
> > > topology a "connected topology" without any loss of meaning while
> > > reinforcing the adjacency concepts.
> > > 
> > > Please consider this replacement.
> > > 
> > > Thanks!
> > > 
> > > Alvaro.
> > > 
> 
> -- 
> ---
> [e-mail]

-- 
---
[e-mail]