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

[Lynne Bartholomew <[e-mail]>]

Hi, Toerless and Alvaro.

Apologies -- it appears that we might need to make updates in two places, but we're not sure how best to do so.  Please specify, using "OLD" and "NEW" text:

OLD:
<current text>
...
<current text>

NEW:
<new text>
...
<new text>

Thank you!

RFC Editor/lb


> On Sep 9, 2022, at 1:17 PM, Alvaro Retana <[e-mail]> wrote:
> 
> On September 9, 2022 at 2:50:56 PM, Toerless Eckert wrote:
> 
> 
> Toerless:
> 
> Hi!
> 
>> 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...
> 
> That works for me.
> 
> Thanks!
> 
> Alvaro.
> 
>> On Sep 9, 2022, at 11:50 AM, Toerless Eckert <[e-mail]> wrote:
>> 
>> 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]
>> 
>