IETF Logo Mail Archive

Re: [6lo] AP-ND 22

Benjamin Kaduk <kaduk@mit.edu> Mon, 27 April 2020 03:52 UTC

Return-Path: <kaduk@mit.edu>
X-Original-To: 6lo@ietfa.amsl.com
Delivered-To: 6lo@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4CAFF3A0948; Sun, 26 Apr 2020 20:52:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no
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 DWPu4OF3CxGE; Sun, 26 Apr 2020 20:52:53 -0700 (PDT)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3B0E13A0947; Sun, 26 Apr 2020 20:52:53 -0700 (PDT)
Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 03R3qZZF017571 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sun, 26 Apr 2020 23:52:37 -0400
Date: Sun, 26 Apr 2020 20:52:34 -0700
From: Benjamin Kaduk <kaduk@mit.edu>
To: Abdussalam Baryun <abdussalambaryun@gmail.com>
Cc: "Pascal Thubert (pthubert)" <pthubert=40cisco.com@dmarc.ietf.org>, Rene Struik <rstruik.ext@gmail.com>, Mohit Sethi <mohit.m.sethi@ericsson.com>, Jim Schaad <ietf@augustcellars.com>, "6lo-chairs@ietf.org" <6lo-chairs@ietf.org>, Erik Kline <ek@loon.com>, "Shwetha Bhandari (shwethab)" <shwethab@cisco.com>, "6lo@ietf.org" <6lo@ietf.org>
Message-ID: <20200427035234.GR27494@kduck.mit.edu>
References: <MN2PR11MB3565BD638A8BCEE57216998BD8D00@MN2PR11MB3565.namprd11.prod.outlook.com> <CADnDZ8_0Bms-pGiGnAX6Cz496qhSOaCGNMggpg7fsQM5wn892w@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <CADnDZ8_0Bms-pGiGnAX6Cz496qhSOaCGNMggpg7fsQM5wn892w@mail.gmail.com>
User-Agent: Mutt/1.12.1 (2019-06-15)
Archived-At: <https://mailarchive.ietf.org/arch/msg/6lo/sJSKNtoF3B6YAHVw98nYpXhUoA4>
Subject: Re: [6lo] AP-ND 22
X-BeenThere: 6lo@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Mailing list for the 6lo WG for Internet Area issues in IPv6 over constrained node networks." <6lo.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/6lo>, <mailto:6lo-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/6lo/>
List-Post: <mailto:6lo@ietf.org>
List-Help: <mailto:6lo-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/6lo>, <mailto:6lo-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 27 Apr 2020 03:52:55 -0000

On Sun, Apr 26, 2020 at 09:10:33AM +0200, Abdussalam Baryun wrote:
>   The draft should indicated on top first page that it updates RFC6775,
> 7400, and 8505, it only shows updating RFC8505.

The 6775 case was discussed extensively during IESG Evaluation.
Note that 8505 itself Updates 6775, and the changes in this document affect
only what 8505 does (IIRC).  I'm not sure why you want this document to
update 7400 -- it seems to just be allocating some bits from the "6LoWPAN
capability Bits" registry established by 7400.  (Well, it would be if the
IANA considerations were updated to state that, at least.)  Allocating bits
from a registry is usually not seen to need an Updates relationship.

-Ben

v2.23.0 | Report a Bug | By Email