Re: [Gen-art] Genart last call review of draft-ietf-lisp-rfc8113bis-01

Brian E Carpenter <> Wed, 19 December 2018 03:48 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 8D69912F1A5; Tue, 18 Dec 2018 19:48:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Status: No, score=-2 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_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id iwQeajdNX-rh; Tue, 18 Dec 2018 19:48:10 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4864:20::62b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 427171276D0; Tue, 18 Dec 2018 19:48:10 -0800 (PST)
Received: by with SMTP id e11so8169059plt.11; Tue, 18 Dec 2018 19:48:10 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=1ixcLii9gE4L3kDWy4zUqQBjXQX9+ytxUPe0nXvYvJQ=; b=GxBWlvSW0JPKIdZPDIOhzzAJYh8yk08uNcSjZsUbNWxBeg5E50IQUwIhCUMx7snPc6 YkY+H4l4HdKxfBjLAb3UyC0NW67KMkpjbWVlV7DWPpGrbDmssmMrP3zUo8A8rNaCZ/FD uGr9pu2iAEcsnSQXHOSAFPlyyyD7R46BYj9Fu4GE9/+1nnUX1nm7ImcbRyrnyhanpWjZ uyuXcyvbfcXbNWIZ50iIrG+S+5sCKu899xuqcl+CDbqoXD03DpYHIsJe6Nwt6JFYQgmC b2cSq2sXo2gBENrO+FbEt5Sud36fcGC5UxdysmBPWbXI2CPk0qEBOxT8dS7L0WehOZj3 O1xQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=1ixcLii9gE4L3kDWy4zUqQBjXQX9+ytxUPe0nXvYvJQ=; b=U7N2I8sP26u8CF665rOZjTmFRgzM2v+LdjAnUHJHJHmBTqJuG7og5LGMiTp7/wpP7a 5VxKmoc5mBe1OsqcyHlFQJQQYAWlvbaBDx2SJAlkTTmYQH5DyKX3B8kK6xsCG5PuB/bX fXFI16j0+0OkDBglBGXNh9Y/XG+ouvs9KiskQpQWx6ZVaU0PZmKYH1c59t1AiopKy6AB obqjfdDFKdGlZgJgbZeG6+1MM/tzjIFAnYAThCJWAv0YBgaS7iDNC7LTf1ioOf9RjIOa XkR0jnju5fehI22QDa3AV8l+nlGwv6daeAez0tpM6+Ww1G4zF1HfZa/nKvsPfgl+Td8s 89ig==
X-Gm-Message-State: AA+aEWZ4alWqoF+nwM+zILuY6xfytkahaSC5A9QCUy1lXaJfvTKytdCR V+n2cgeefjrLYZ/oP6Fxp7FMI4CQXhg=
X-Google-Smtp-Source: AFSGD/UP28MQ4IF3srMb7nQIa2E24+kV72M4aAu9lFuGrwOeGxzAuDD4enGh3ALDIe9aZDWAUImhAQ==
X-Received: by 2002:a17:902:8d8e:: with SMTP id v14mr18722496plo.133.1545191289266; Tue, 18 Dec 2018 19:48:09 -0800 (PST)
Received: from [] ([]) by with ESMTPSA id b27sm23614810pfh.113.2018. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 18 Dec 2018 19:48:08 -0800 (PST)
To: "Joel M. Halpern" <>,
References: <> <>
From: Brian E Carpenter <>
Message-ID: <>
Date: Wed, 19 Dec 2018 16:48:02 +1300
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.3.3
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: <>
Subject: Re: [Gen-art] Genart last call review of draft-ietf-lisp-rfc8113bis-01
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "GEN-ART: General Area Review Team" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 19 Dec 2018 03:48:12 -0000

On 2018-12-19 15:46, Joel M. Halpern wrote:
> This is part of the package to move the coherent set of base LISP specs 
> to PS.
> The reason we did this rather than folding it into 6830bis / 6833bis is 
> that we had originally simply cited 8113, and then realized that needed 
> to move to PS along with everything else.  It seemed (and is) simpler to 
> do it separately rather than to further modify 6830bis / 6933bis.
> As for why it updates 6833bis, that is because one of the cahnges in 
> moving the set to PS was to improve the split as to which information 
> belonged in which document.

OK, but I still don't find it logical The text doesn't explain which part of
6833bis is impacted, and normally these days we require such an explanation.
And if there is an impact, you're missing the opportunity of fixing the error
or gap in 6833bis, so the reader of 6833bis will be none the wiser unless
you insert a reference to 8113bis.

On the other hand, if there is no error or gap, you don't need "Updates:"
at all. (Unfortunately, we don't have an "Extends:" header.)


> Yours,
> Joel
> On 12/18/18 9:25 PM, Brian Carpenter wrote:
>> Reviewer: Brian Carpenter
>> Review result: Ready with Issues
>> Gen-ART Last Call review of draft-ietf-lisp-rfc8113bis-01
>> I am the assigned Gen-ART reviewer for this draft. The General Area
>> Review Team (Gen-ART) reviews all IETF documents being processed
>> by the IESG for the IETF Chair.  Please treat these comments just
>> like any other last call comments.
>> For more information, please see the FAQ at
>> <>.
>> Document: draft-ietf-lisp-rfc8113bis-01.txt
>> Reviewer: Brian Carpenter
>> Review Date: 2018-12-19
>> IETF LC End Date: 2018-12-27
>> IESG Telechat date:
>> Summary: Ready with issues
>> --------
>> Comments:
>> ---------
>> I note that this is being raised from Experimental to the standards track.
>> Presumably that depends on the base LISP spec becoming PS.
>> Minor issues:
>> -------------
>> "This document updates I-D.ietf-lisp-rfc6833bis." The text doesn't
>> explain which text is updated. This is in contrast to RFC8113, which
>> explains clearly how it updates RFC6830 (*not* RFC6833). Why doesn't
>> this draft claim to update rfc6830bis? I'm going to assume that
>> is an error.
>> In fact, why wasn't the definition of the LISP Packet Types registry
>> moved into the base spec (rfc6830bis)? That is where it belongs.
>> Since rfc6830bis (and rfc6833bis) are still under IESG review, anything
>> in them that needs updating should be updated! The fact is that rfc8113bis
>> extends rfc6830bis, which is not the same thing as "updates".
>> If the WG thinks that implementers of 6830bis need to read 8113bis,
>> there should be a normative reference in 6830bis to 8113bis.