Re: [6lo] Ben Campbell's No Objection on draft-ietf-6lo-rfc6775-update-17: (with COMMENT)

Ben Campbell <ben@nostrum.com> Wed, 04 April 2018 15:07 UTC

Return-Path: <ben@nostrum.com>
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 15CC912D72F; Wed, 4 Apr 2018 08:07:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.89
X-Spam-Level:
X-Spam-Status: No, score=-1.89 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] autolearn=ham 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 CT1kxrzldADq; Wed, 4 Apr 2018 08:07:16 -0700 (PDT)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 BD4CC126FB3; Wed, 4 Apr 2018 08:07:16 -0700 (PDT)
Received: from [10.0.1.91] (cpe-66-25-7-22.tx.res.rr.com [66.25.7.22]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id w34F7BPK003045 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Wed, 4 Apr 2018 10:07:12 -0500 (CDT) (envelope-from ben@nostrum.com)
X-Authentication-Warning: raven.nostrum.com: Host cpe-66-25-7-22.tx.res.rr.com [66.25.7.22] claimed to be [10.0.1.91]
From: Ben Campbell <ben@nostrum.com>
Message-Id: <7604C322-AEC9-4A0A-953E-4FE7188249D0@nostrum.com>
Content-Type: multipart/signed; boundary="Apple-Mail=_799D186A-5074-4A67-9445-0BC4FA41DB7A"; protocol="application/pgp-signature"; micalg="pgp-sha512"
Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\))
Date: Wed, 04 Apr 2018 10:07:10 -0500
In-Reply-To: <CB38E612-AFD4-44E4-AB0A-1AE4F58553DE@cisco.com>
Cc: Adrian Farrel <adrian@olddog.co.uk>, "dthaler@microsoft.com" <dthaler@microsoft.com>, The IESG <iesg@ietf.org>, "draft-ietf-6lo-rfc6775-update@ietf.org" <draft-ietf-6lo-rfc6775-update@ietf.org>, Gabriel Montenegro <Gabriel.Montenegro@microsoft.com>, "6lo-chairs@ietf.org" <6lo-chairs@ietf.org>, "6lo@ietf.org" <6lo@ietf.org>
To: "Pascal Thubert (pthubert)" <pthubert@cisco.com>
References: <152280747362.24073.12482880754689636320.idtracker@ietfa.amsl.com> <CB38E612-AFD4-44E4-AB0A-1AE4F58553DE@cisco.com>
X-Mailer: Apple Mail (2.3445.6.18)
Archived-At: <https://mailarchive.ietf.org/arch/msg/6lo/qvs6Ge4fHdq1exzD3wIbPS1lzqs>
Subject: Re: [6lo] Ben Campbell's No Objection on draft-ietf-6lo-rfc6775-update-17: (with COMMENT)
X-BeenThere: 6lo@ietf.org
X-Mailman-Version: 2.1.22
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: Wed, 04 Apr 2018 15:07:19 -0000


> On Apr 4, 2018, at 1:23 AM, Pascal Thubert (pthubert) <pthubert@cisco.com> wrote:
> 
> Hello Ben;
> 
> The down reference issues were added as part of the IESG review; the refs were informative before but it was pointed that since they were referenced in the terminology this made them normative. CC’ing Adrian.
> 
> Can we live with it?
> 

Theoretically any normative downrefs should have been mentioned in the IETF last call announcement. Since these were added after LC, it’s up to Suresh to decide whether the LC needs to be repeated. (I don’t necessarily think it does; I’m just pointing out the fact that they exist.)

> The MUST in section 3 is also the result of of IESG review; we debated it with Dave and Warren but I guess there is no strong opinion so another proposal would be welcome. CC’ing Dave. Would you suggest an alternate wording?

The issue is that the MUST seems to observe the natural state of the world; operators must do this or their networks won’t work. It is not a new imperative created by this draft. I suggest simply changing the MUST to a lower case “must”.

> 
> Cheers,
> 
> Pascal
> 
>> Le 4 avr. 2018 à 04:04, Ben Campbell <ben@nostrum.com> a écrit :
>> 
>> Ben Campbell has entered the following ballot position for
>> draft-ietf-6lo-rfc6775-update-17: No Objection
>> 
>> When responding, please keep the subject line intact and reply to all
>> email addresses included in the To and CC lines. (Feel free to cut this
>> introductory paragraph, however.)
>> 
>> 
>> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
>> for more information about IESG DISCUSS and COMMENT positions.
>> 
>> 
>> The document, along with other ballot positions, can be found here:
>> https://datatracker.ietf.org/doc/draft-ietf-6lo-rfc6775-update/
>> 
>> 
>> 
>> ----------------------------------------------------------------------
>> COMMENT:
>> ----------------------------------------------------------------------
>> 
>> §3, last paragraph: The MUST seems like a statement of fact.
>> 
>> §12.1: There are normative downrefs to RFC 4919, RFC 6606, RFC 7102, RFC 7228
>> that were not mentioned in the IETF LC announcement, nor are they in the
>> downref registry.
>> 
>>