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

[Toerless Eckert <[e-mail]>]

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]