Re: [Rift] Final pass on readability/normative ...
"Pascal Thubert (pthubert)" <pthubert@cisco.com> Wed, 29 January 2020 08:27 UTC
Return-Path: <pthubert@cisco.com>
X-Original-To: rift@ietfa.amsl.com
Delivered-To: rift@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5357412022A for <rift@ietfa.amsl.com>; Wed, 29 Jan 2020 00:27:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.497
X-Spam-Level:
X-Spam-Status: No, score=-14.497 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=d6iewly2; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=zvB5VoR1
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WrCDw0KrX5jL for <rift@ietfa.amsl.com>; Wed, 29 Jan 2020 00:27:09 -0800 (PST)
Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7ABDB120142 for <rift@ietf.org>; Wed, 29 Jan 2020 00:27:09 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=86674; q=dns/txt; s=iport; t=1580286429; x=1581496029; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=2nBkx2/rPLGzJiiJfDvF+zguH6Gaqt1ABihWbZp3x/w=; b=d6iewly2NbbJLByji4jYM75SVfMsz+7khOlcE2oj7U5WaWa3uYdHziEv B8ZVCa2T15KiXXEk8LhgScet2RJlrPu6Wk5qSijLNbNhOzQCo67JPafnE r8Ju0yVHQ9uJkTkMzHh+EMH5pHz8aSwAcNf+cfH4Meg0EFwmpHmWC0cwb I=;
IronPort-PHdr: 9a23:H36aThJSNivZtqw7/dmcpTVXNCE6p7X5OBIU4ZM7irVIN76u5InmIFeBvKd2lFGcW4Ld5roEkOfQv636EU04qZea+DFnEtRXUgMdz8AfngguGsmAXFXnLOPgYjYmNM9DT1RiuXq8NBsdFQ==
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0ABCgCLQDFe/5pdJa1gBhwBAQEBAQcBAREBBAQBAYF7gSUvJCwFbA9JIAQLKoQUg0YDixiCX4lhji6CUgNUCQEBAQwBAR8OAgEBhEACF4IQJDgTAgMNAQEEAQEBAgEFBG2FNwyFXgEBAQEDEhEEBhMBATIFAQ8CAQgRAQMBASEBBgMCAgIfERQDBggCBA4FCBqDBYF9TQMuAQIMoUACgTmIYnV/M4J/AQEFhQ8NC4IMAwaBOIUehDeCSRqBQT+BEAFHUX1+PoIbSQEBA4E6GBAkBwmCWjKCLJBVhV4jiVKOcEQKgjmHQopMhESCSIgKkCqXRIIkkAUCBAIEBQIOAQEFgWkigVhwFYMnUBgNjh0REoNQhRSFP3SBKYpKgkIBAQ
X-IronPort-AV: E=Sophos;i="5.70,377,1574121600"; d="scan'208,217";a="711812305"
Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 29 Jan 2020 08:27:07 +0000
Received: from XCH-ALN-008.cisco.com (xch-aln-008.cisco.com [173.36.7.18]) by rcdn-core-3.cisco.com (8.15.2/8.15.2) with ESMTPS id 00T8R7PX024997 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 29 Jan 2020 08:27:07 GMT
Received: from xhs-rcd-001.cisco.com (173.37.227.246) by XCH-ALN-008.cisco.com (173.36.7.18) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Wed, 29 Jan 2020 02:27:07 -0600
Received: from xhs-rtp-001.cisco.com (64.101.210.228) by xhs-rcd-001.cisco.com (173.37.227.246) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Wed, 29 Jan 2020 02:27:06 -0600
Received: from NAM10-MW2-obe.outbound.protection.outlook.com (64.101.32.56) by xhs-rtp-001.cisco.com (64.101.210.228) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Wed, 29 Jan 2020 03:27:05 -0500
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=i4Nvcy1c0sptJlBXPGUh0ucNsehN1TJ/OAjaL9KOWY5cSKaQDi1V3SCO6WotCY5hs0opO/SToduC8PH/3EkO06ROtNRuS4MYPODvciqsQh2rGWeBBU0janOI1jhnSG+cCTB9It4/eCC2fb1ONXiAdpvs698Aaj0Vji3suhAGvmUw3IBQpKiGnoGF8J81j4iT1zqjHomgryh/+eNddUssQSPgT0tpaY0U47wM/3o6tfhlOL16vvaHnYWcYm8XMZzdcZHHn1CkTghj9HwH+/EJ9i1VAbYhBz0HKAe2awgaWPa+k6IbYycqNm2uQjUNRQZU+YBgBPQGsZSSEZ0VppV/Dw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=2nBkx2/rPLGzJiiJfDvF+zguH6Gaqt1ABihWbZp3x/w=; b=ZxEnyVe8t9n1W/lSTB7hLqR8E76PRwXq6CPrbdokPmByJvRCidxjXcuBP1/AchROtftBIHy8tprZFooUGD1VkLHo1wwRNJW8q6li3d/ChJe6lQlLBBp7lPGBDOlm3BHvIbUvPYgGvh+gfWCjGcpmNTj/5ci5No7qfoAuAkK1jDbHS6KxTmMKgYRJytpWtDxavIufgtOSw+k8Z6efGR9MCP0AtTsH8bUj7ow7wtnDJnuR1eHA/2V2S7T9tDV9IwGOC01NUK4N5DddYlAf5n33bw6ZInj84FWRxbPMlYIdmp9AhS9NItAItl6Q+q0O1STPDCg2bJRqNG6z9MwMRWZjGw==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=2nBkx2/rPLGzJiiJfDvF+zguH6Gaqt1ABihWbZp3x/w=; b=zvB5VoR10+IAeefimXJTsGFc84vMAJEV+8RgE8QjPMdL66OmBCTRlRd9LcXfYZyNWv6GhnNFEvOzxZVc7VRWzG4zedwaGo38BzzC0+vnyUjvFuyiWKlPN1lM3BMN5MIdwEgM3bVajqcZy9NFcns9VVXM4ThH/x33D8gZmYnl/5M=
Received: from MN2PR11MB3565.namprd11.prod.outlook.com (20.178.250.159) by MN2PR11MB3725.namprd11.prod.outlook.com (20.178.254.87) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2665.23; Wed, 29 Jan 2020 08:27:03 +0000
Received: from MN2PR11MB3565.namprd11.prod.outlook.com ([fe80::fd76:1534:4f9a:452a]) by MN2PR11MB3565.namprd11.prod.outlook.com ([fe80::fd76:1534:4f9a:452a%3]) with mapi id 15.20.2665.026; Wed, 29 Jan 2020 08:27:03 +0000
From: "Pascal Thubert (pthubert)" <pthubert@cisco.com>
To: Tony Przygienda <tonysietf@gmail.com>
CC: "rift@ietf.org" <rift@ietf.org>
Thread-Topic: [Rift] Final pass on readability/normative ...
Thread-Index: AQHVrlkD26MeEFPSo0Kd+sHHMEpUmKexXyYAgA5HkoCAAAWGIIAfrrRQgCIG0gCAADy/MA==
Date: Wed, 29 Jan 2020 08:26:58 +0000
Deferred-Delivery: Wed, 29 Jan 2020 08:26:18 +0000
Message-ID: <MN2PR11MB35650430239BB66A31027B11D8050@MN2PR11MB3565.namprd11.prod.outlook.com>
References: <CA+wi2hPV7GvA7unqded=WYf2DDm0CnWCx0ygGjD2G2JpNwJhTg@mail.gmail.com> <MN2PR11MB356573C857961433E29D35FAD8580@MN2PR11MB3565.namprd11.prod.outlook.com> <CA+wi2hP-C4LtO1T0t=vON6Wv55PS_DU9JrtUrsnBFMw+hR5qaA@mail.gmail.com> <BYAPR11MB3558E4A0178B5CC92D20D6D2D8530@BYAPR11MB3558.namprd11.prod.outlook.com> <MN2PR11MB356571D181C7130CC84A5E37D83F0@MN2PR11MB3565.namprd11.prod.outlook.com> <CA+wi2hNMzLwWBkKjSiWxg9TCDw1K1_COwAHWq4mi_9rThyM8=Q@mail.gmail.com>
In-Reply-To: <CA+wi2hNMzLwWBkKjSiWxg9TCDw1K1_COwAHWq4mi_9rThyM8=Q@mail.gmail.com>
Accept-Language: fr-FR, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=pthubert@cisco.com;
x-originating-ip: [2a01:cb1d:4ec:2200:5dc4:fdad:718a:9d74]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 5d37bb5f-ba3b-42da-a983-08d7a49504a4
x-ms-traffictypediagnostic: MN2PR11MB3725:
x-microsoft-antispam-prvs: <MN2PR11MB3725ECFF12D0D387CC43C77AD8050@MN2PR11MB3725.namprd11.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:8882;
x-forefront-prvs: 02973C87BC
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(376002)(396003)(136003)(39860400002)(366004)(346002)(199004)(189003)(55016002)(9686003)(53546011)(8936002)(71200400001)(6506007)(2906002)(52536014)(81166006)(81156014)(4326008)(8676002)(186003)(7696005)(6666004)(5660300002)(86362001)(478600001)(66574012)(64756008)(66946007)(66446008)(66476007)(33656002)(76116006)(66556008)(316002)(6916009)(21314003)(559001)(579004); DIR:OUT; SFP:1101; SCL:1; SRVR:MN2PR11MB3725; H:MN2PR11MB3565.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1;
received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: 1NwjIQ6rsk2ra9Una962KPNt5BD/kI5h5BPoTo8lyndSeUTf660la1pqAbYdtroP1V68CD4x/ODe39+UtxF1E6EPshZlrYm6YOl9RBOTk9Xdlz7b0cF33hoV3/0673YJTcVwgG2Bz7BdpxItGagFFT8lVfB8E+KmBHTAgYINwDktL7uNhXC1XHhtw9NqDF7rtE+hqj0eavKRFr9m4bjyv3KEKtkiqJtVWsvtFHWDTqWdnx/HW01cguFBOqyd/TDGIpku1tFF5HwEWAqTFBaYIqsE+11uIrhStVH7rTMYesKRkQhE6NYtrcONBcaHnbyb7GbiRyNew3X563ZLfndhrR+W/xjDz8OeUbDW5xSxLglmeUtS2GFTYajm+sAEHTUmK8+xRTdJjRQDqF3tIRmiTfmzLb3nNKGkqWn9eXBtaS2bo6AsVQiou4HXXwV7dMW8Tgagc/xxeWIfKPBagrRc1hfX3DAB7yqVRqsCztp+bEn8nlSB3sFXafrD+ce5VAeyLBtyAH9bYX2iKBO9VIL5/DYOQ7BHHPXzf4iK6fFkdC4kW3z0yp0zqsBZPeXNL6Qb
x-ms-exchange-antispam-messagedata: HJxokouK3hZNXtdyViPv7amb05VDnGE2aR8j+6IrHcze8aXEFWAQmQiMlkSRiLgogBiPeK2Ib6bAwe7EQyTMudXLznQLc/0nWjE5oNKuV/yX283oV7eNcYwqkGoO3SBsSKw7IhX6ZnZO/rpSe8/XayN58GozV7TbQu30Kg45zY5HpKMt9I+rBnPwasCskTtDK3T7sDf+qIohyGF788ksqg==
x-ms-exchange-transport-forked: True
Content-Type: multipart/alternative; boundary="_000_MN2PR11MB35650430239BB66A31027B11D8050MN2PR11MB3565namp_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 5d37bb5f-ba3b-42da-a983-08d7a49504a4
X-MS-Exchange-CrossTenant-originalarrivaltime: 29 Jan 2020 08:27:02.9697 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: UELUDmRizDet5cwa6GeET7o6VPSCwfmuy98VwzQIa52p940QBPOsjamt4kXluDCy0OhWhTHgo9z09cXl8IwY+w==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR11MB3725
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.36.7.18, xch-aln-008.cisco.com
X-Outbound-Node: rcdn-core-3.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/rift/WhqWV13X3F0SzIE7m7gBPPlb9u4>
Subject: Re: [Rift] Final pass on readability/normative ...
X-BeenThere: rift@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Discussion of Routing in Fat Trees <rift.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rift>, <mailto:rift-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rift/>
List-Post: <mailto:rift@ietf.org>
List-Help: <mailto:rift-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rift>, <mailto:rift-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 29 Jan 2020 08:27:12 -0000
All good, Tony, many thanks. From: Tony Przygienda <tonysietf@gmail.com> Sent: mercredi 29 janvier 2020 05:48 To: Pascal Thubert (pthubert) <pthubert@cisco.com> Cc: rift@ietf.org 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) <pthubert@cisco.com<mailto:pthubert@cisco.com>> wrote: 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. ack 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. ack 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. ack 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. done PoD-ToP -> ToP (twice) too tedious to find the places. better you do yourself |H< -> |o< ack 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) ack 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? 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. " 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. ack normally the top spines in a PoD -> normally the ToP nodes 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? Also, the terms “lie” and “cleanup” are found in lowercase, maybe change all relevant to uppercase 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. “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? nothing needs to be done, "Spine" is in the glossary and well defined. 4.2.3. Topology Exchange (TIE Exchange) 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 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. 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 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 ;-) More tomorrow, starting at 4.2.3.3.1.5 All the best pascal From: RIFT <rift-bounces@ietf.org<mailto:rift-bounces@ietf.org>> On Behalf Of Tony Przygienda Sent: dimanche 8 décembre 2019 22:21 To: rift@ietf.org<mailto:rift@ietf.org> 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
- Re: [Rift] Final pass on readability/normative ... Pascal Thubert (pthubert)
- [Rift] Final pass on readability/normative ... Tony Przygienda
- Re: [Rift] Final pass on readability/normative ... Tony Przygienda
- Re: [Rift] Final pass on readability/normative ... Pascal Thubert (pthubert)
- Re: [Rift] Final pass on readability/normative ... Tony Przygienda
- Re: [Rift] Final pass on readability/normative ... Pascal Thubert (pthubert)
- [Rift] Fwd: Final pass on readability/normative .… Tony Przygienda