[Rift] Fwd: Final pass on readability/normative ...

Tony Przygienda <tonysietf@gmail.com> Wed, 29 January 2020 08:36 UTC

Return-Path: <tonysietf@gmail.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 01B15120241 for <rift@ietfa.amsl.com>; Wed, 29 Jan 2020 00:36:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.997
X-Spam-Level:
X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 HkCK2MkKlSdt for <rift@ietfa.amsl.com>; Wed, 29 Jan 2020 00:36:15 -0800 (PST)
Received: from mail-io1-xd34.google.com (mail-io1-xd34.google.com [IPv6:2607:f8b0:4864:20::d34]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E1E4F12022D for <rift@ietf.org>; Wed, 29 Jan 2020 00:36:14 -0800 (PST)
Received: by mail-io1-xd34.google.com with SMTP id n21so17641754ioo.10 for <rift@ietf.org>; Wed, 29 Jan 2020 00:36:14 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=AtG2OoEhtXx1F3UVyxqawUcyLJMVQ3pdkxxMw1S8P5c=; b=iLNSMCc+j+FpOr3FppAvbrJTRtYqQkUiJliHQwQwHvdbgTiT5ycgGvEfFZ+NgsT8fR JGe2thiNMabeLsG9AW1+BpF1hlGGGl8BQuu/pBpTYB7kej6BifmwNAc6+05NcoC8Wr+9 iqXtw7FqEwIqh2dw6rPGNqg+W7Md2NzRqlDbmnTSd+/mPTk/dsKTwo0NZuoFnuGymya6 Jh42E0co0rtmuVL/admX1yisRl8D01lmChJaA6IcABRqAAOIr97ZafUFW4e8JeCYpr3Q 0txvQyQMtlWFjsPXhEJy3nS1m4lINDj4f1Pgf0pHptRDIHWFanLYXOErpyGXLOeCYIEO UI5A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=AtG2OoEhtXx1F3UVyxqawUcyLJMVQ3pdkxxMw1S8P5c=; b=bYTDA1HusnUQ0Jv1HR67LzlB+56EQoEgxyfrerADlvudK6WWxVLGny/X7ns8ncfjIz cyPK6Gpk7+G3M9TgeSeRVqg0JUE+87n8vTqWLgUDLGmeFoqKbwMCatvKD3CQtdkWdLXr tlh1Vn2bbS3Wpss6rrrLeHAFak7Fj27jYGAIpsHawUNsYQMs9iOTFkc+gC9yilwd8jJR 3hVC61VPA6/Ut9sdip8lkYTlKIlqpglskWChSrH+DeHlJ64uh8VafiWUDMgGmOpIFZcn W0ZQ3K+G2Z2eMnbQjGJIatPAAByWtP4xHa4Fgs3VCsOBax9zaOA+Ir88rnBUIH6ZZa6b aaMQ==
X-Gm-Message-State: APjAAAUwbfjCYzNfFqRKO8CUFZFDHQrtXPNEvzRnUzm5EybJ+6lXac5w 1hTtjlwFD7LP4sOC+UCaMyOeq6tfNEN4TQnIyZK1sg==
X-Google-Smtp-Source: APXvYqx0aV0XR2VOME1Ok9BgZ8PQBiHTyytpnMxYxvQUgLfNLws2h7aSfnEpwZNzSH7HHwWm8upviXPgxLlaYiGLrUE=
X-Received: by 2002:a02:c78f:: with SMTP id n15mr21342135jao.100.1580286972599; Wed, 29 Jan 2020 00:36:12 -0800 (PST)
MIME-Version: 1.0
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> <MN2PR11MB3565EAA5EE6B1433B686625FD80F0@MN2PR11MB3565.namprd11.prod.outlook.com> <CA+wi2hMPssd=Mqpy+QrMnsDdHFmejyEWSj4uSGo3RddEgoaZ5Q@mail.gmail.com>
In-Reply-To: <CA+wi2hMPssd=Mqpy+QrMnsDdHFmejyEWSj4uSGo3RddEgoaZ5Q@mail.gmail.com>
From: Tony Przygienda <tonysietf@gmail.com>
Date: Wed, 29 Jan 2020 00:34:58 -0800
Message-ID: <CA+wi2hMrVjQ1jW_suZuuuNdVU7dT1j___2T40sF-n4VrFN7T7A@mail.gmail.com>
To: rift@ietf.org
Content-Type: multipart/alternative; boundary="000000000000a52069059d433b54"
Archived-At: <https://mailarchive.ietf.org/arch/msg/rift/sYOud7rHTHnlH67ZlSNWMG8cVEU>
Subject: [Rift] Fwd: 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:36:19 -0000

forgot to cc: the list

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




On Thu, Jan 23, 2020 at 1:53 AM Pascal Thubert (pthubert) <
pthubert@cisco.com> 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.
>
>
>
>
>
>    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,
>

done


>
>
>
>
> 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.
>

done

>
>
>
>
> prefix South TIEs
>
> ->
>
> Prefix South TIEs
>

done


>
>
>
>
> In table 3 “flood always” is subject to the flooding relay procedure.
> 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.*

"


>
>
>
>
> 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.
>
>
>
>
>

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



> 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.
>
> “
>

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 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.
>

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


>
>
>
>
>
>
> “
>
> 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.
>
> “
>

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.*

"


>
>
> 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.
>

ack


>
>
>
> 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?
>

ack, you corect, scanned whole doc for "CAN" and replaced with "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.
>

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.


> ”
>
>
>
> Note that it might be simpler that a node syncs TIRE/TIDE with its FRs
> 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.


>
>
>
>
> 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.
>
>
>
>
>

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.
>
>
>
> Take care,
>

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' <tonysietf@gmail.com>
> *Cc:* rift@ietf.org
> *Subject:* RE: [Rift] Final pass on readability/normative ...
>
>
>
> 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 <rift-bounces@ietf.org> *On Behalf Of *Tony Przygienda
> *Sent:* dimanche 8 décembre 2019 22:21
> *To:* 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
>