Re: [Gen-art] Gen-ART Telechat review of draft-ietf-lisp-lcaf-17
Dino Farinacci <farinacci@gmail.com> Fri, 14 October 2016 12:04 UTC
Return-Path: <farinacci@gmail.com>
X-Original-To: gen-art@ietfa.amsl.com
Delivered-To: gen-art@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3D5512972D; Fri, 14 Oct 2016 05:04:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level:
X-Spam-Status: No, score=-2.7 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-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 8IMhLOjqeYee; Fri, 14 Oct 2016 05:03:56 -0700 (PDT)
Received: from mail-qk0-x22e.google.com (mail-qk0-x22e.google.com [IPv6:2607:f8b0:400d:c09::22e]) (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 55ED212972E; Fri, 14 Oct 2016 05:03:51 -0700 (PDT)
Received: by mail-qk0-x22e.google.com with SMTP id o68so190128077qkf.3; Fri, 14 Oct 2016 05:03:51 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=louacImAlOuhG9D6+VKHgQRWmFbp8H3fqiPB1I09u3A=; b=v2612IBn1r/UEV1CgyJCLug8mFfSjZsremJBz5UDuHBuvFhNxYUt6je0T8/RNJi9tk pGWHmDd8HcpzFbx2w6uMi/UQunDu5xAvkMa2omCzFG9+FIVcv8sKwf82kS7cB+tAwiKC igsWi31qhOgiP9r4Y2EQRcpvu/Eds+b6kAi1V6HvzeWuF6fVwVpMigVDDfp0GcXmeg+X +gvfoSOcvbasV8BBpXjrLyieFnr98AefVvIZLFYfByCJGac1QO+sKbAN3HPKY/21nIYW Nrp0lPcstyWQVYWhMroQ4WXuBfr8uF7WpdLoYa6vLrUiXNCbF4ri/5FgQ9oA3qnIhqcd 77bQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=louacImAlOuhG9D6+VKHgQRWmFbp8H3fqiPB1I09u3A=; b=ha617s37WZhWRC1ImLETH3++B6syr+g3Nx4M0oX/slakM57jyOWmKoEXF2k9Hkct5e XI0vkYMAikh0FHlVAHVMcPvhyRHGF7lb9kXAKeB1QACiIEJKjJfgjQttGPpMEplCbuf7 vy1xPwunEQisN05ZJj6/9HA7SgVy8DZ9zPuk0T6hcCedcBR5O7HLOQ4cuUfXbq83uFXu LcXdmrLC8hk+GVCONp1kqi37Rr9mmJMVORUTO7kAW2MtpjRy9fGcTdyu3m0I6WHQhCwf n89u/tfvnRZQZAzn4iRlzfk6oCGhwdOsApkqNCvPNa6WlrMzNh1Kgvxkkp63oFSpCx22 /Wpw==
X-Gm-Message-State: AA6/9RlbA7f7+pEE0Ufr0SpsIEBC/OeFzFtEo72ifmQy/AaZun8hqvIUm8Pl4xcd06bHVw==
X-Received: by 10.194.142.116 with SMTP id rv20mr1806720wjb.184.1476446630407; Fri, 14 Oct 2016 05:03:50 -0700 (PDT)
Received: from [10.12.7.153] ([37.205.61.206]) by smtp.gmail.com with ESMTPSA id g9sm31405101wjk.25.2016.10.14.05.03.47 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 14 Oct 2016 05:03:48 -0700 (PDT)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 10.0 \(3226\))
From: Dino Farinacci <farinacci@gmail.com>
In-Reply-To: <019901d22563$fa24ee40$ee6ecac0$@akayla.com>
Date: Fri, 14 Oct 2016 03:31:34 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <109D05AE-B21F-4F5C-AF07-F5CEBB571E26@gmail.com>
References: <013901d22511$d471b860$7d552920$@akayla.com> <1FDB9633-7186-4786-96FE-4F75745F12B3@gmail.com> <019901d22563$fa24ee40$ee6ecac0$@akayla.com>
To: Peter Yee <peter@akayla.com>
X-Mailer: Apple Mail (2.3226)
Archived-At: <https://mailarchive.ietf.org/arch/msg/gen-art/_vl3dNkOHy2FkS9Olg8RthBIHBA>
Cc: gen-art@ietf.org, draft-ietf-lisp-lcaf@ietf.org, ietf@ietf.org
Subject: Re: [Gen-art] Gen-ART Telechat review of draft-ietf-lisp-lcaf-17
X-BeenThere: gen-art@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "GEN-ART: General Area Review Team" <gen-art.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/gen-art>, <mailto:gen-art-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/gen-art/>
List-Post: <mailto:gen-art@ietf.org>
List-Help: <mailto:gen-art-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/gen-art>, <mailto:gen-art-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 14 Oct 2016 12:04:01 -0000
Thanks for your second round of comments Peter. See comments inline. > Page 6, Rsvd2 definition: the definition both says "reserved for future use" > and then says some types actually use it. That sounds like present use. > And to generically say that it should be sent as zero and ignored, but then > to give uses (such as Type 2) for it is confusing. I suggest rethinking > the wording here. I have fixed this and received multiple comemnts on this from various people. > Page 6, Length definition: there's mention of a "Reserved" field that's > included in the minimum length of 8 bytes that are not part of the length > value. Since there are actually Rsvd1 and Rsvd2 fields in the generic > version of the LCAF and sometimes even Rsvd3 and Rsvd4 fields when using > specific Types, it might be better to spell out which reserved fields (Rsvd1 > and Rsvd2) are meant here rather than giving the field a summary name that > doesn't actually appear in the format. This is also important because any > Rsvd3 and Rsvd4 fields are included in the Length field, so using a generic > "Reserved" description is ambiguous at best. Should be fixed now. > Page 13, RTR RLOC Address definition, 4th sentence: The ability to determine > the number of RTRs encoded by looking at the value of the LCAF length > doesn't seem feasible. 3 IPv4 RTR RLOCs will produce the same LCAF Length > as 1 IPv6 RTR RLOC. Fixed now. > Page 13, RTR RLOC Address definition, 5th sentence: this sentence gives two > means to indicate that there RTR field values. What's the point of having > two different means of doing so? This just seems to introduce complexity > and increase the chance for implementations that may not handle both schemes > correctly. One scheme ought to suffice. I prefer the Length field method > since it requires fewer bytes transmitted, but either works. An implementation must be prepared to find the RTR RLOC address entry with an AFI=0. So either the length includes all bytes up to and including the “Private ETR RLOC Address” field which basically encodes no “RTR RLOC Address” more efficiently or it does include an AFI=0 for the “RTR RLOC Address” entry. Since an AFI can be a value of 0 in any LISP message, we have to document the two ways to encode “no RLOC addresses”. > Nits: > > Page 5, Type definition: change the comma to a semicolon. > > Page 8, Usage, 1st sentence: change the second "a" to "an". > > Page 9, AS Number definition: insert "to" before "either". > > Page 13, RTR RLOC Address definition, 3rd sentence: change "these" to > "this". > > Page 14, section 4.5, 2nd paragraph: change "it's" to "its". > > Page 15, Source/Subnet Address and Group Address definitions: delete an > extra space before "is" in each definition. > > Page 16, Strict bit (S) definition, 1st sentence: change "Rencap" to > "Reencap". > > Page 18, Key Count definition, 2nd sentence: change "the" to "of". > > Page 18, AFI = x definition: insert two spaces before the second sentence. > > Page 24, section 4.10.3, 1st paragraph: delete "where it is delimited by > length 'n' of the LCAF Length encoding" > > Page 26, 1st paragraph after Length2 definition: change "AFI-encoded" to > "AFI encoded". My apologies for suggesting a blind find-and-replace in the > previous review. Obviously that was wrong here. Made changes for above. > Page 27, section 5.1, Length value n definition: I'm not sure what qualifies > as "8-byte Application Data fields", but there appear to be 12 bytes before > the AFI and that's reflected in the Length field in the figure. So the > local and remote port ranges are the 8-byte Application Data fields? This > comes back to my minor issue with how Length values are described in the > text and in the figures. Please clarify what's meant here. I don’t find any reference in document -17 to "8-byte Application Data fields”. > Page 29, Key Field Num definition: change "the the" to "the". > > Page 32, section 5.5, 1st paragraph, 2nd sentence: insert "the" before > "key”. Made these changes too. Thanks. Dino
- [Gen-art] Gen-ART Telechat review of draft-ietf-l… Peter Yee
- Re: [Gen-art] Gen-ART Telechat review of draft-ie… Jari Arkko
- Re: [Gen-art] Gen-ART Telechat review of draft-ie… Dino Farinacci