Re: [Gen-art] Gen-ART review of draft-ietf-mpls-gach-adv-06
Jari Arkko <jari.arkko@piuha.net> Wed, 27 March 2013 07:22 UTC
Return-Path: <jari.arkko@piuha.net>
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 4EAC621F8FFC for <gen-art@ietfa.amsl.com>; Wed, 27 Mar 2013 00:22:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.654
X-Spam-Level:
X-Spam-Status: No, score=-102.654 tagged_above=-999 required=5 tests=[AWL=-0.055, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qxwbJcePKR5M for <gen-art@ietfa.amsl.com>; Wed, 27 Mar 2013 00:22:46 -0700 (PDT)
Received: from p130.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by ietfa.amsl.com (Postfix) with ESMTP id 565C021F8FF9 for <gen-art@ietf.org>; Wed, 27 Mar 2013 00:22:45 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id A1AE32CC55; Wed, 27 Mar 2013 09:22:44 +0200 (EET)
X-Virus-Scanned: amavisd-new at piuha.net
Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JyOS7d7X86zi; Wed, 27 Mar 2013 09:22:43 +0200 (EET)
Received: from [127.0.0.1] (p130.piuha.net [IPv6:2001:14b8:400::130]) by p130.piuha.net (Postfix) with ESMTP id 959892CC4A; Wed, 27 Mar 2013 09:22:43 +0200 (EET)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\))
From: Jari Arkko <jari.arkko@piuha.net>
In-Reply-To: <CABkgnnXOcDRkp=6e8aDdhTbk+s=hkR2wCkXoJcWGn8sjrRi2cg@mail.gmail.com>
Date: Wed, 27 Mar 2013 09:22:43 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <5F2E6810-A5F9-4FD1-8D24-667FCDFB6618@piuha.net>
References: <CABkgnnW-53MVHZaW4QweqBjrPGCrP=fCNQ+LJdaG__ePh2tn1A@mail.gmail.com> <CABkgnnXOcDRkp=6e8aDdhTbk+s=hkR2wCkXoJcWGn8sjrRi2cg@mail.gmail.com>
To: Martin Thomson <martin.thomson@gmail.com>
X-Mailer: Apple Mail (2.1503)
Cc: "Bocci, Matthew (Matthew)" <matthew.bocci@alcatel-lucent.com>, "gen-art@ietf.org" <gen-art@ietf.org>, danfrost@cisco.com, draft-ietf-mpls-gach-adv.all@tools.ietf.org, stbryant@cisco.com
Subject: Re: [Gen-art] Gen-ART review of draft-ietf-mpls-gach-adv-06
X-BeenThere: gen-art@ietf.org
X-Mailman-Version: 2.1.12
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: <http://www.ietf.org/mail-archive/web/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: Wed, 27 Mar 2013 07:22:52 -0000
Thank you for the review, Martin! The issue with replication of RFC 2104 has been raised as a Discuss by other ADs. That will get resolved. But do the authors or chairs have responses for the other things in Martin's review? Jari On Mar 10, 2013, at 7:52 PM, Martin Thomson <martin.thomson@gmail.com> wrote: > I sent the following review a few weeks back. I just wanted to make sure that it didn't get accidentally stored in /dev/null. > > > On 15 February 2013 14:33, Martin Thomson <martin.thomson@gmail.com> wrote: > I am the assigned Gen-ART reviewer for this draft. For background on > Gen-ART, please see the FAQ at > > <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>. > > Please resolve these comments along with any other Last Call comments > you may receive. > > Document: draft-ietf-mpls-gach-adv-06 > Reviewer: Martin Thomson > Review Date: 2013-02-15 > IETF LC End Date: 2013-02-27 > IESG Telechat date: (if known) > > Summary: The document is almost ready for publication as proposed > standard. There is a major issue that should be easy to resolve. > > Major issues: > > Section 6.3 duplicates the description of HMAC provided in RFC 2104. > That is likely to cause a bug. > > If you reference RFC 2104, then the only requirement is a clear > specification for what message is input to the HMAC. Currently, this > is buried. It is unclear if the input includes the G-ACh header > defined in RFC 5586 (it doesn't need to, but this needs to be made > explicit). > > Filling the authentication part with 0x878FE1F3 seems unnecessary busy > work, but it's harmless as long as the hash function produces a > multiple of 32 bits of output. > > Minor issues: > > To avoid forward compatibility issues, reserved fields should come > with guidance that says: "Implementations of this protocol version > MUST set reserved fields to all zero bits when sending and ignore any > value when receiving messages." > > In Section 4.4, how does the duration interact with the lifetime? > What happens when the duration is longer than lifetime such that the > TLV is expunged before the duration is up? > > Section 5.2 states: > [...] If one > of the received TLV objects has the same Type as a previously > received TLV then the data from the new object SHALL replace the data > associated with that Type unless the X specification dictates a > different behavior. > > This leads to different retention characteristics depending on some > arbitrary application-specific requirements. It also complicates > implementations. Is there a strong motivation for the "unless the X > specification dictates a different behavior" part of this statement? > > If this behaviour is desirable, a note regarding what happens to the > composed TLV when some of the values that contribute to it might > expire might be necessary. > > Regarding the last paragraph of Section 6.3: > This also means that the use of hash functions with larger > output sizes will increase the size of the GAP message as > transmitted on the wire. > > If you want to prevent hash truncation, then use 'MUST'. Personally, > I see no reason to do so. It's a good way to get smaller messages, > with a corresponding reduction in the strength of the assurance > provided. > > Nits: > > Section 3 could use some subheadings to aid navigation (and referencing). > > Section 3 describes the size of fields only through ASCII-art. It's a > fairly simple thing to add a bit count to the description of each > field. That includes the reserved fields, which have no descriptions. > > I like the text in the editors note on page 8. Why is it not the > actual text already? > > Sections 4.2 and 4.3 could probably use a note that notes that > retention of these TLVs doesn't make any sense. These could be sent > with zero lifetime, except that if these are sent along with the > Source Address TLV, that's not possible... unless you send multiple > application data blocks for the same application. Is that possible? > > _______________________________________________ > Gen-art mailing list > Gen-art@ietf.org > https://www.ietf.org/mailman/listinfo/gen-art
- [Gen-art] Gen-ART review of draft-ietf-mpls-gach-… Martin Thomson
- Re: [Gen-art] Gen-ART review of draft-ietf-mpls-g… Martin Thomson
- Re: [Gen-art] Gen-ART review of draft-ietf-mpls-g… Jari Arkko
- Re: [Gen-art] Gen-ART review of draft-ietf-mpls-g… Stewart Bryant
- Re: [Gen-art] Gen-ART review of draft-ietf-mpls-g… Martin Thomson
- Re: [Gen-art] Gen-ART review of draft-ietf-mpls-g… Stewart Bryant
- Re: [Gen-art] Gen-ART review of draft-ietf-mpls-g… Stewart Bryant
- Re: [Gen-art] Gen-ART review of draft-ietf-mpls-g… Martin Thomson
- Re: [Gen-art] Gen-ART review of draft-ietf-mpls-g… Stewart Bryant
- Re: [Gen-art] Gen-ART review of draft-ietf-mpls-g… Stewart Bryant
- Re: [Gen-art] Gen-ART review of draft-ietf-mpls-g… Stewart Bryant