Re: [Rift] Genart early review of draft-ietf-rift-rift-08

Tony Przygienda <tonysietf@gmail.com> Tue, 29 October 2019 00:55 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 0107E1200C3; Mon, 28 Oct 2019 17:55:24 -0700 (PDT)
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 A24s4PRtbh50; Mon, 28 Oct 2019 17:55:21 -0700 (PDT)
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 28748120047; Mon, 28 Oct 2019 17:55:21 -0700 (PDT)
Received: by mail-io1-xd34.google.com with SMTP id k1so3892853iom.9; Mon, 28 Oct 2019 17:55:21 -0700 (PDT)
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 :cc; bh=lEI3WzSTdxOOUK6bgSoLZl5hgbW82rDRSqVlgESAo20=; b=lCCzrPb3UNe821SeupeqXzn8V96jtmMjKBQBaYRdPHo2Y9AhXahTrgMu/y1Wqs7JO8 TWjukgwb+P48gkIKD6oCW48qkXAJXo2VaOTEP0aKeCejoGeK4AZXFJKg5omI/hy2T/ht SHmDFP8VyrwOLbajB2nzkCH/yniohxTPUt7NHxDcbMc1/ib4lyuT2AN+0ByPEla4Nq5N 5Pq9e8sov5M4ZvwgRIVIwS03/ZvLzq9HjZCqFzT+/JUj80SL4hJiax54QjnVlPoPCR4v IfL4D4WRcGXC/EJZAgg+GkdNnntRWlMgroez82x7jLkH7NzXg5XsCFUGm+3THZdQkWM/ zAoQ==
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:cc; bh=lEI3WzSTdxOOUK6bgSoLZl5hgbW82rDRSqVlgESAo20=; b=iX57dxDBJq9AADjhwlwcGkBQ7F+IA5KzTx+LxalH49tWe10iMD0T+LrN0hChESvhN9 JxiUPb87WAr+no2v7TPTknkEEBX57DiSuy3NinbibmtFtrlnuFJD8BTXhULZpgMsILSc NHiQ7iJUHxPp/sztb9KPVhAVTNdvuhjlKDc06zxXwHljAmqFwPu5wPGwsGLiFaFCled/ DRGHYaldPhjN4kVQlFBkSs1MaIzPRPfkO7dkJ7X8o5hMHowiOaXt679PzVWULzz1hCm8 vkMI/EYJwwi17e5fAgTt9g2hWeLs4a6AR/UFAlJ7TZTp3d/dVvBb/0Xc5ZUEixfh6xy6 p7TQ==
X-Gm-Message-State: APjAAAVRX/HtQutFKmb5H7EeNSUSbkOwsv8MmVj4/EyRpWol3pb46oUO 5ZSPXiok80jneTcWtdKInIzhGnIK+B+edn/XWNI=
X-Google-Smtp-Source: APXvYqxxzEOvcf9VZy5XVxULL2vndORJRb4L5MkOKfuDbr0ri7s9YullNn5SSNDGAANx+5rw9WzJUbK5dNdoiJhKKUc=
X-Received: by 2002:a6b:b54a:: with SMTP id e71mr918289iof.132.1572310520468; Mon, 28 Oct 2019 17:55:20 -0700 (PDT)
MIME-Version: 1.0
References: <157228915192.16080.15649375711620871809@ietfa.amsl.com> <CA+wi2hOJM7F5Xi7oEmh+81EwpzLCW4q-VEXa4UTpNMyYhgjzXQ@mail.gmail.com> <15b2c084-ec76-4b5b-016a-39333867d625@nostrum.com>
In-Reply-To: <15b2c084-ec76-4b5b-016a-39333867d625@nostrum.com>
From: Tony Przygienda <tonysietf@gmail.com>
Date: Mon, 28 Oct 2019 17:54:33 -0700
Message-ID: <CA+wi2hO_9LVvL4OaQB1msQY95wdNEU+cBakVp-3E7SeSoPfFjw@mail.gmail.com>
To: Robert Sparks <rjsparks@nostrum.com>
Cc: gen-art@ietf.org, draft-ietf-rift-rift.all@ietf.org, rift@ietf.org
Content-Type: multipart/alternative; boundary="0000000000000c9b0905960212ee"
Archived-At: <https://mailarchive.ietf.org/arch/msg/rift/iEDO8cQZMxvzHt2RHsQj2SxBEnc>
Subject: Re: [Rift] Genart early review of draft-ietf-rift-rift-08
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: Tue, 29 Oct 2019 00:55:24 -0000

On Mon, Oct 28, 2019 at 2:16 PM Robert Sparks <rjsparks@nostrum.com>; wrote:

>
>
>
>
>>
>> Some high-level points before going into a document-order set of comments:
>>
>> ** The IANA considerations section does not provide a clear set of
>> instructions
>> for IANA to follow.
>>
>
> Ok, could you be a little bit more specific
>
> You can get AD help here. See section 2.2 of
> https://datatracker.ietf.org/doc/rfc8126/.
>
> 9.2 is where I am concerned.
>
> Please add an explicit statement that you are asking IANA to create a new
> top-level registry named RIFT with the following subregistries under it.
>

yes, no problem.


>
>
>
>>
>> The nested numbered lists in section 5.2.3.9 are perhaps not the best
>> tool for
>> describing the algorithms you want to convey. On page 46, steps 4.3.3 and
>> 4.4
>> are comments, not actions. Numbering them as you number actions is
>> confusing.
>>
>
> any better suggestions? (I will move from numbering to number.latin.other
> and so on). This is
> an old technique in protocol specs to allow implementors to discuss very,
> very precise statement
> and their meaning (e.g. ISIS spec is all written like that). Otherwise
> people start to talk about
> "4th line in the algorithm X" which is far more confusing.
>
> number.latin.other will help.
>

ok, thanks

>
> rfc2txt does not have a mechanism to "skip numbering for this item" when
> genreeating
> lists unless I'm oblivious to it so I'm limited by the tools IETF provides
> to render documents.
>
> Do you mean xml2rfc when you say rfc2txt?
>

yes, correct. sorry.


>
>
>
>>
>> It's particularly unclear what you are trying to achive with the
>> "DirectionMaxValue" registry entry defined in 9.2.11.1 Are you trying to
>> say
>> the registry is not allowed any more values? If so, just say that in the
>> instructions to IANA. I don't see where the codepoint is used by the
>> protocol,
>> so I suggest it not be added to the registry.
>>
>
> implementation specific basically. Can be removed but allows in
> implementation to
> use the codepoint to scale arrays for example.
>
> If the registry takes
>
> DirectionMaxValue
>
>
> for e.g. version 3.0 schema this value could move. Alternately we could split a registry
> _per schema version_ but that seems a huge proliferation and replication.
>
>
> I'm agnostic either way and would like to hear an opinion here
>
> I'll punt this to the group/AD.
>

ack


>
>
>
>>
>> Also in Appendix A, I question the sentence "The >: relationship is
>> symmetric
>> but not transitive". Symmetric says "if A>:B then  B>:A".
>>
>
> yes, symmetric means "if A>:B then  B>:A" precisely what you say and the
> relation holds.
>
> non transitive means obviously that
>
> A>:B and B>:C does NOT imply A>:C
>
> Obvious example of the 3-bit arithmetic is
>
> 4 >: 2 & 2 >: 0 does NOT follow in 4 >: 0
>
> I will reread. 4 >: 2 and 2 >: 4 surprises me.
>

oh, sorry, that's the objection, I thought you objected to transitive and
focused on that. yes, you're correct, it's not symmetric, I was blind and
implied

4 >: 2  <=>  2 <: 4

which is not symmetry of course. I will correct.


>