Subject: Re: [Rift] Final pass on readability/normative ...

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Tue, 7 Jan 2020 15:57:10 +0000

Hello Tony:

As promised:

      Superspine/Aggregation or Spine/Edge Levels:  Traditional names in
      5-stages folded Clos for Level 2, 1 and 0 respectively.  Level 0
      is often called leaf as well.  We normalize this language to talk
      about leafs, spines and top-of-fabric (ToF).

I believe we should reword this, maybe as below:

      Superspine vs. Aggregation or Spine vs. Edge or Leaf:  Traditional level
      names in  5-stages folded Clos for Level 2, 1 and 0 respectively.  We
      normalize this language to talk about top-of-fabric (ToF), top-of-pod (ToP)
      and leaves.

   De-aggregation/Disaggregation:  Process in which a node decides to
      advertise certain prefixes it received in North TIEs to prevent
      black-holing and suboptimal routing upon link failures.

Suggestion:

   De-aggregation/Disaggregation:  Process in which a node decides to
      advertise more specific prefixes Southwards, either positively to
      attract the corresponding traffic, or negatively to repel it.
      Disaggregation is performed to prevent black-holing and suboptimal
      routing to the more specific prefixes.

   Bandwidth Adjusted Distance (BAD):  This is an acronym for Bandwidth
      Adjusted Distance.  Each RIFT node calculates the amount of
      northbound bandwidth available towards a node compared to other
      nodes at the same level and modifies the default route distance
      accordingly to allow for the lower level to adjust their load
      balancing towards spines.

Removing the first sentence:

   Bandwidth Adjusted Distance (BAD):  Each RIFT node calculates the
      amount of northbound bandwidth available towards a node compared
      to other nodes at the same level and modifies the default route distance
      accordingly to allow for the lower level to adjust their load
      balancing towards spines.

   North SPF (N-SPF):  A reachability calculation that is progressing
      northbound, as example SPF that is using South Node TIEs only.

I think it is confusing to call the northbound computation a SPF since it is a 1 hop calculation. Relates to the next point:

   We present here a detailed outline of a protocol optimized for
   Routing in Fat Trees (RIFT) that in most abstract terms has many
   properties of a modified link-state protocol
   [RFC2328<https://tools.ietf.org/html/rfc2328>][ISO10589-Second-Edition] when "pointing north" and distance
   vector [RFC4271<https://tools.ietf.org/html/rfc4271>] protocol when "pointing south".  While this is an
   unusual combination, it does quite naturally exhibit the desirable
   properties we seek.

I’d replace "pointing north" with computing southbound routes and reciprocally for "pointing south" with computing northbound routes.

PoD-ToP
->
ToP
(twice)

|H<
  ->
|o<

LIEs SHOULD be sent with a TTL of 1
->
LIEs SHOULD be sent with an IPv4 Time to Live (TTL) / IPv6 Hop Limit (HL) of 1

(same addition suggested in 4.2.3.1 for LIE)

Nodes in the spine are configured with "any" PoD which has the same
   value "undefined" PoD hence we will talk about "undefined/any" PoD.
   This information is propagated in the LIEs exchanged.

“Nodes in the spine” is unclear; do you mean ToF nodes? My understanding is that: ToF nodes MUST be configured with “undefined”, ToP MUST NOT be configured with “undefined”, and a leaf node MAY be configured with “undefined”, in which case the leaf node learns from its ToP parents. (If I’m correct) maybe we should say just that?

This will not affect the correctness of the protocol expect preventing detection of certain miscabling cases.
-> s/expect/except/
This will not affect the correctness of the protocol except preventing detection of certain miscabling cases.

normally the top spines in a PoD
->
normally the ToP nodes

4.2.2.1.  LIE FSM

Maybe listing the states in after the first sentence would be useful for the reader? Also introduce HAL, HALS and HAT acronyms before using them?
Also, the terms “lie” and “cleanup” are found in lowercase, maybe change all relevant to uppercase

“More precisely, a spine node represents two different”
Should we remove “spine” from  the sentence? Or define it?
Same goes for the use of “Spine xxx”, should we call them ToP xxx?

4.2.3.  Topology Exchange (TIE Exchange)

Maybe indicate that TIEs are exchanged only in 3-ways?

Suggestion to add an “instance nb” to the TIE so we can build multiple RIBs like in RPL over a same topology, e.g.; to serve different tenants.

More tomorrow, starting at 4.2.3.3.1.5

All the best

pascal

From: RIFT <[email-masked]<mailto:[email-masked]>> On Behalf Of Tony Przygienda
Sent: dimanche 8 décembre 2019 22:21
To: [email-masked]<mailto:[email-masked]>
Subject: [Rift] Final pass on readability/normative ...

Only IESG outstanding reviewer's comments on the spec are @ this point in time improving general readability & fine comb on normative captions (plus going to format -v3 with pictures is up to me)

I have some volunteers already that are starting on reading sections & polishing, I'm calling here for more ;-) If you'd like to review a section for readability & check normative language please contact me and I'll synchronize. Resolution is X.Y or X.Y.Z section with exception of small stuff like Examples maybe.

On offer honorable mention in the acknowledgements section ;-)

Idea would be to have a -10 (hopefully last one) with pictures & review incorporated before next IETF.

thanks

-- tony

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Thu, 23 Jan 2020 09:52:10 +0000

Hi again Tony

More below, restarting page 54. Note that I am a PC user. On a iphone, the message I already sent appears to disappear after the line though it can be expended. Note that both this and the previous comment sets are pretty long and please make sure you see it all.

   Every North TIE is flooded northbound, providing a node at a given
   level with the complete topology of the Clos or Fat Tree network
   underneath it,

-> (unless we define that under is south, which is OK with me, you may want to change as below)

   Every North TIE is flooded northbound, providing a node at a given
   level with the complete topology of the Clos or Fat Tree network
   that is reachable southwards of it,

may be
   routed directly towards the node advertising that prefix rather than
   sending the packet to a node at a higher level.

->

will be
   routed directly towards one of the southward neighbors advertising that prefix rather than
   sending the packet to a node at a higher level.

prefix South TIEs
->
Prefix South TIEs

In table 3 “flood always” is subject to the flooding relay procedure. Should we have an (*) to mention that ?
Also it would help to express in the TIE, TIDE and TIRE definitions that the TIE may be reflooded but TIRE and TIDE that are sent are only self-generated, never forwarded.
The current way of saying that they are like ISIS CSCP / PSNP forces the reader to get knowledge of ISIS and that should not be needed.

P. 57 4.2.3.7
What you mean by purging may be obvious for many but it wouldn’t hurt to add text, like:

<new>
When a destination exit the network, residual stale routes may exist in the network till there lifetime expire.
</new>
  RIFT does not purge information that has been distributed by the
   protocol.  Purging mechanisms in other routing protocols have proven
   to be complex and fragile over many years of experience.  Abundant
   amounts of memory are available today even on low-end platforms.  The
   information will age out and all computations will deliver correct
   results if a node leaves the network due to the new information
   distributed by its adjacent nodes.

4.2.3.8.  Southbound Default Route Origination

“Southbound Default Route” reads weird since the route is Northwards. What about:

4.2.3.8.  Default Route Southbound Advertisement

About:
“
   A node originating a southbound default route MUST install a default
   discard route if it did not compute a default route during N-SPF.
“
->
“
   A node originating a southbound advertisement of a default route MUST install a default
   discard route if it did not compute a default route during N-SPF. “

Worth noting (should we add text?):

- This applies also to a smaller prefix that aggregate the fabric if the fabric is not connected to the Internet
- A leaf may advertise a default route northwards. That route has precedence over the discard route.
- A ToF that loses connectivity to the all the leaves  advertising a default route northwards must stop advertising the default route.

“
A node SHOULD send out LIEs that grant flood repeater status
       before LIEs that revoke it on flood repeater set changes to
       prevent transient behavior where the full coverage of grand
       parents is not guaranteed.

“
This one is hard to swallow. What about:
“
Upon a change of the flood repeater set, a
A node SHOULD send out LIEs that grant flood repeater status to
the nodes that are promoted to that status before it sends LIEs
that revoke the status to the nodes that are demoted. This is
done to  prevent transient behavior where the full coverage of
grand parents is not guaranteed.
“

4.  A node receiving a TIE originated by a node for which it is not a
       flood repeater does NOT re-flood such TIEs to its neighbors
       except for rules in Paragraph 6

note sure what “does NOT” mean in terms of BCP 14

4.   A node receiving a TIE originated by a node for which it is not a
       flood repeater SHOULD NOT re-flood such TIEs to its neighbors
       except for rules in Paragraph 6. Re-flooding may saturate the
       fabric to no avail.

5.  The indication of flood reduction capability MUST be carried in
       the node TIEs and CAN be used to optimize the algorithm to
       account for nodes that will flood regardless.

CAN is not listed in BCP 14. Why not MAY?

  6.  A node generates TIDEs as usual but when receiving TIREs or TIDEs
       resulting in requests for a TIE of which the newest received copy
       came on an adjacency where the node was not flood repeater it
       SHOULD ignore such requests on first and first request ONLY.

Same goes for ONLY.

   6.  A node generates TIDEs as usual but when receiving TIREs or TIDEs
       resulting in requests for a TIE of which the newest received copy
       came on an adjacency where the node was not flood repeater it
       SHOULD ignore such requests on first and first request ONLY.

Maybe
“
SHOULD ignore such requests on the first request and only on the first request.
”

Note that it might be simpler that a node syncs TIRE/TIDE with its FRs before it attempts to do so with others.

Need a global change to remove “super-spine”.
In particular in the text below a 3 level is assumed, but we could do 4 or more, couldn’t we?

   More difficult is a condition where a node floods a TIE north towards
   a super-spine, then its spine reboots, in fact partitioning
   superspine from it directly and then the node itself reboots.

   ->

   More difficult is a condition where a node (e.g., a leaf) floods a TIE north towards
   a grand-parent (e.g., a ToF node), then its parent (e.g., a ToP node) reboots, isolating
   the node from the grand-parent level, and then the node itself reboots.

With this I reached 4.2.4. I’ll try the review that section soon.

Take care,

Pascal

From: Pascal Thubert (pthubert)
Sent: mardi 7 janvier 2020 16:57
To: 'Tony Przygienda' <[email-masked]>
Cc: [email-masked]
Subject: RE: [Rift] Final pass on readability/normative ...

Hello Tony:

As promised:

Suggestion:

PoD-ToP
->
ToP
(twice)

|H<
  ->
|o<

4.2.2.1.  LIE FSM

All the best

pascal

thanks

-- tony

---

From: Tony Przygienda <[email-masked]>
Date: Tue, 28 Jan 2020 20:47:38 -0800

Answers inline.

Also, to hono(u)r the English idiom, I belatedly replaced "leafs"
everywhere to "leaves" as to not leave (as you know me, pun fully expected
and intended) us exposed to grammar nit-picking ;-)

>       normalize this language to talk about top-of-fabric (ToF),

ack

>       routing to the more specific prefixes.

ack

>       balancing towards spines.

ack

> I think it is confusing to call the northbound computation a SPF since it
> is a 1 hop calculation. Relates to the next point:
>
>
>
>
>
>
>
>    [RFC2328 <https://tools.ietf.org/html/rfc2328>][ISO10589-Second-Edition]
> when "pointing north" and distance
>
>    vector [RFC4271 <https://tools.ietf.org/html/rfc4271>] protocol when
> "pointing south".  While this is an
>
> I’d replace "pointing north" with computing southbound routes and
> reciprocally for "pointing south" with computing northbound routes.
>

done

> (twice)

too tedious to find the places. better you do yourself

> |o<

ack

> (same addition suggested in 4.2.3.1 for LIE)

ack

>
>
> “Nodes in the spine” is unclear; do you mean ToF nodes? My understanding
> is that: ToF nodes MUST be configured with “undefined”, ToP MUST NOT be
> configured with “undefined”, and a leaf node MAY be configured with
> “undefined”, in which case the leaf node learns from its ToP parents. (If
> I’m correct) maybe we should say just that?
>

clarified to

"

*Unless ZTP as described in Section 4.2.7 is used, each node
isprovisioned with the level at which it is operating.  It CAN be
alsoprovisioned with its PoD.  If any of those values is undefined,
thenaccordingly a default level and/or an "undefined" PoD are
assumed.This means that leaves do not need to be configured at all if
initialconfiguration values are all left at "undefined" value.  Nodes
aboveToP MUST remain at "any" PoD value which has the same value
as"undefined" PoD.  This information is propagated in the
LIEsexchanged.*

"

> detection of certain miscabling cases.

ack

> normally the top spines in a PoD

done

>
>
>
>
> 4.2.2.1.  LIE FSM
>
>
>
> Maybe listing the states in after the first sentence would be useful for
> the reader? Also introduce HAL, HALS and HAT acronyms before using them?
>

Yes, good suggestion on states, added that. moved some sections to make a
clearer, more fluid LIE intro. massaged everything into one way of writing
as one-way, two-way, three-way.

HALS/HAT is all definedi n the ZTP section where it belongs more logically.
Someone reading LIE will get too overloaded with too many acronyms too
early.

> Same goes for the use of “Spine xxx”, should we call them ToP xxx?

nothing needs to be done, "Spine" is in the glossary and well defined.

> Maybe indicate that TIEs are exchanged only in 3-ways?

yes, added in LIE.  A very mild possible loophole was present and I added.
"

*A node SHOULD NOT send out any topology information elements if
theadjacancy is not in a "three-way" state.  No further tightening
ofthis rule is possible due to possible link buffering and
re-orderingof LIEs and TIEs/TIDEs/TIREs.A node MUST drop any received
TIEs/TIDEs/TIREs unless it is in three-way state.*

"

It was not a security loophole, normally the nonces would prevent from any
flooding
attack under 3-way state but the addition helps to prevent "loose"
implementations.

>
>
>
>
>
>
>
>
> Suggestion to add an “instance nb” to the TIE so we can build multiple
> RIBs like in RPL over a same topology, e.g.; to serve different tenants.
>

unnecessary, all included. ;-)  4.3.9 already says

*"*

*Multiplexing of LIEs can be achieved byeither choosing varying
multicast addresses or portson the same address.*
"

Multi-instance just runs on differnt multicast addresses and/or LIE ports
and TIE reception port is advertised anyway in the LIE. Hence nothing more
than UDP de-mux is needed to run multiple instances. Not a theory, I happen
to have seen a nice multi-instance implementation already operating ;-)

Multiple RIBs is a rathole, that leads immediatly into VPN land and
multkple RIBs/demux can be implemented in so many ways we'll never find a
common language. Every routing stack (and they've been a couple) I worked
on had a different architecture to deal with multkple RIBs (if they had one
;-)

> *From:* RIFT <[email-masked]> *On Behalf Of *Tony Przygienda
> *Sent:* dimanche 8 décembre 2019 22:21
> *To:* [email-masked]
> *Subject:* [Rift] Final pass on readability/normative ...
>
>
>
> Only IESG outstanding reviewer's comments on the spec are @ this point in
> time improving general readability & fine comb on normative captions (plus
> going to format -v3 with pictures is up to me)
>
>
>
> I have some volunteers already that are starting on reading sections &
> polishing, I'm calling here for more ;-) If you'd like to review a section
> for readability & check normative language please contact me and I'll
> synchronize. Resolution is X.Y or X.Y.Z section with exception of small
> stuff like Examples maybe.
>
>
>

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Wed, 29 Jan 2020 08:26:58 +0000

All good, Tony, many thanks.

From: Tony Przygienda <[email-masked]>
Sent: mercredi 29 janvier 2020 05:48
To: Pascal Thubert (pthubert) <[email-masked]>
Cc: [email-masked]
Subject: Re: [Rift] Final pass on readability/normative ...

Answers inline.

Also, to hono(u)r the English idiom, I belatedly replaced "leafs" everywhere to "leaves" as to not leave (as you know me, pun fully expected and intended) us exposed to grammar nit-picking ;-)

On Tue, Jan 7, 2020 at 7:57 AM Pascal Thubert (pthubert) <[email-masked]<mailto:[email-masked]>> wrote:
Hello Tony:

As promised:

ack

Suggestion:

ack

ack

done

PoD-ToP
->
ToP
(twice)

|H<
  ->
|o<

ack

ack

clarified to

"

Unless ZTP as described in Section 4.2.7 is used, each node is
provisioned with the level at which it is operating.  It CAN be also
provisioned with its PoD.  If any of those values is undefined, then
accordingly a default level and/or an "undefined" PoD are assumed.
This means that leaves do not need to be configured at all if initial
configuration values are all left at "undefined" value.  Nodes above
ToP MUST remain at "any" PoD value which has the same value as
"undefined" PoD.  This information is propagated in the LIEs
exchanged.
"

ack

done

4.2.2.1.  LIE FSM

Yes, good suggestion on states, added that. moved some sections to make a clearer, more fluid LIE intro. massaged everything into one way of writing as one-way, two-way, three-way.

HALS/HAT is all definedi n the ZTP section where it belongs more logically. Someone reading LIE will get too overloaded with too many acronyms too early.

A node SHOULD NOT send out any topology information elements if the
adjacancy is not in a "three-way" state.  No further tightening of
this rule is possible due to possible link buffering and re-ordering
of LIEs and TIEs/TIDEs/TIREs.

A node MUST drop any received TIEs/TIDEs/TIREs unless it is in three-
way state.
"

It was not a security loophole, normally the nonces would prevent from any flooding
attack under 3-way state but the addition helps to prevent "loose" implementations.

"

Multiplexing of LIEs can be achieved by
either choosing varying multicast addresses or ports
on the same address.
"

Multi-instance just runs on differnt multicast addresses and/or LIE ports and TIE reception port is advertised anyway in the LIE. Hence nothing more than UDP de-mux is needed to run multiple instances. Not a theory, I happen to have seen a nice multi-instance implementation already operating ;-)

Multiple RIBs is a rathole, that leads immediatly into VPN land and multkple RIBs/demux can be implemented in so many ways we'll never find a common language. Every routing stack (and they've been a couple) I worked on had a different architecture to deal with multkple RIBs (if they had one ;-)

All the best

pascal

thanks

-- tony

---

From: Tony Przygienda <[email-masked]>
Date: Wed, 29 Jan 2020 00:34:58 -0800

forgot to cc: the list

---------- Forwarded message ---------
From: Tony Przygienda <[email-masked]>
Date: Tue, Jan 28, 2020 at 11:44 PM
Subject: Re: [Rift] Final pass on readability/normative ...
To: Pascal Thubert (pthubert) <[email-masked]>

On Thu, Jan 23, 2020 at 1:53 AM Pascal Thubert (pthubert) <
[email-masked]> wrote:

> Hi again Tony
>
>
>
> More below, restarting page 54. Note that I am a PC user. On a iphone, the
> message I already sent appears to disappear after the line though it can be
> expended. Note that both this and the previous comment sets are pretty long
> and please make sure you see it all.
>
>
>
>
>

done

done

done

> Should we have an (*) to mention that ?

you mean as in flooding queues/TIDE/TIRE rules? "flood" means here
obviouosly using "flooding procedures" I think but suggest a language if
you think we can improve on that.

> Also it would help to express in the TIE, TIDE and TIRE definitions that
> the TIE may be reflooded but TIRE and TIDE that are sent are only
> self-generated, never forwarded.
>
> The current way of saying that they are like ISIS CSCP / PSNP forces the
> reader to get knowledge of ISIS and that should not be needed.
>

 yes, that's a good suggestion, added

"

*TIDEs and TIREs MUST NOT be re-flooded the way TIEs of other nodesare
are MUST be always generated by the node itself and cross only tothe
neighboring node.*

"

>    distributed by its adjacent nodes.

extended the section by this and added bits more clarification on purging.

>    discard route if it did not compute a default route during N-SPF.

well, there are also northbound default possible if the fabric uses a
different internal prefix (quite common) so we can't monopolize the term. I
don't know why it's confusing to you. It's a route sent in S-TIEs and we
call the others also southbound prefixes. It would be worse to call it
"nortbound deafult" but send it in S-TIEs IMO. Right now the only
counter-intuitive (i.e. direction changing) piece in RIFT spec is that if
you run northbound SPF you extend prefix S-TIEs and vice-versa. That cannot
be helped.

I thought about that stuff quite a bit when choosing original language,
conceptual framework and I still believe it's the least of all evils.

> - A ToF that loses connectivity to the all the leaves  advertising a
> default route northwards must stop advertising the default route.
>

yes and no. points are worth mentioning but you're only partially correct.
Section 6.4 quickly mentions that you can "use soemthing else than dfault
for fabric default" but the full treatement is necessary in the "4.10 TODO"
section of rift-applicability which we can attack if you have time. To
quickly correct here only what you say and give first approx

0. I though origianlly of defining a "fabric default route" vs. a normal
default route but it wuold have made language much more complicated. Vast
majority of people use fabric underlay with overlay and the internet
default is only in overlay so I considered the disctinction unnecessary.
when we talk about RIFT default it's by osmosis most people understand it's
a "underlay default" vs. "internet overlay default" ;-)
1. yes, you will in case of no overlay almost certainly choose a local
fabric prefix instead of default if you want ot put internet default in
from the leaves
1.5 look @ the model route prefs. Discard MUST be always most preffered,
that's pretty deep routing stuff that has nothing to do with RIFT but is
important to prevent looping. Strictly speaking Discard is actually not
even a preference but any route with a 'discard' next-hop but since we talk
about default discards in the spec it is better to emphasize that such a
route MUST tie-break best to stop loops (I mean here transient loops
obviously since @ full convergence RIFT doesn't loop but given today's
silicon speeds even fairly short ones or burst of unreaqchables can be
produced real-real quick so it's better to do it that way).
2. any "internet default" route does NOT take precedence over discard so
you canot run "fabric default" as 0/0 and inject internet default from the
leaves. Stuff will get discarded @ the ToF level and it should since
otherwise you could produce beautifully partitioned fabric given e'thing
will not go north but immediately "turn back south" in the same PoD
confusing "internet default" with "fabric default". so if you'd like from
the leaf to inject an "internet dfault" at 0/0 you have to choose a private
addressing space for the fabric and then it's clear what's happening.
3. the text for fabric default route origination in section 4.2.3.8 is
very, very precise when you should originate a fabric default.

injecting internet default from the leaf without overlay gets really
interseting in multi-plane fabric but the currect spec handles that as well
if you read it carefully ;-)

so, in short, no changes but you're welcoem to gel that into first version
of 4.10 section in applicability draft

> grand parents is not guaranteed.

yeah, good simplification of lawyering argot we had here ;-) Polished a bit

"

*2.  Upon a change of the flood repeater set, a node SHOULD send out
 LIEs that grant flood repeater status to newly promoted nodes
before it sends LIEs that revoke the status to the nodes that    have
been newly demoted.  This is done to prevent transient    behavior
where the full coverage of grandparents is not    guaranteed.  Such a
condition is sometimes unavoidable in case of    lost LIEs but it will
correct itself though at possible transient    hit in flooding
propagation speeds.*

"

ack

> CAN is not listed in BCP 14. Why not MAY?

ack, you corect, scanned whole doc for "CAN" and replaced with "MAY"

> SHOULD ignore such requests on the first request and only on the first

ack, did that. changed other ONLY (2 in the spec) to "MAY/MUST exclusively"
but not sure that really improves the spec albeit it pays the RFC2119
piper.

> before it attempts to do so with others.

the node below does not tell nodes above anyting about it being a FR or not
since that is an interface property so that's not feasible in first
approximation already.

>    the node from the grand-parent level, and then the node itself reboots.

ack, rewrote

"

*   More difficult is a condition where a node (e.g. a leaf) floods a
TIE   north towards its grandparent, then its parent reboots, in fact
 partitioning the grandparent from leaf directly and then the leaf
itself reboots.  That can leave the grandparent holding the "primary
copy" of the leaf's TIE.  Normally this condition is resolved easily
by the leaf re-originating its TIE with a higher sequence number than
 it sees in northbound TIEs, here however, when the parent comes back
 it won't be able to obtain leaf's North TIE from the grandparent
easily and with that the leaf may not issue the TIE with a higher
sequence number that can reach the granparent for a long time.
Flooding procedures are extended to deal with the problem by the
means of special clauses that override the database of a lower level
with headers of newer TIEs seen in TIDEs coming from the north.*

"

no other uses of superspine anymore

> With this I reached 4.2.4. I’ll try the review that section soon.

ok, super. Once you done with 4.2.4 I will publish -10 ince I got from
other reviewers e'thing by now. I will also issue another call for
reviewers to review remaining sections. We have good parts covered but more
to go still.

>
>
> Pascal
>
>
>
>
>
> *From:* Pascal Thubert (pthubert)
> *Sent:* mardi 7 janvier 2020 16:57
> *To:* 'Tony Przygienda' <[email-masked]>
> *Cc:* [email-masked]
> *Subject:* RE: [Rift] Final pass on readability/normative ...
>
>
>
> Hello Tony:
>
>
>
> As promised:
>
>
>
>
>