IETF Logo Mail Archive

Re: Adam Roach's No Objection on draft-ietf-6man-rfc6434-bis-08: (with COMMENT)

Adam Roach <adam@nostrum.com> Wed, 11 July 2018 20:44 UTC

Return-Path: <adam@nostrum.com>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 06B23130EB9; Wed, 11 Jul 2018 13:44:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.878
X-Spam-Level:
X-Spam-Status: No, score=-1.878 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, 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 UjwWHwRJmAQO; Wed, 11 Jul 2018 13:44:12 -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 A5D7B1292AD; Wed, 11 Jul 2018 13:44:10 -0700 (PDT)
Received: from [IPv6:2607:fb90:44aa:b118:5981:814c:87d4:49b2] ([172.58.105.103]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id w6BKi8Xk083035 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Wed, 11 Jul 2018 15:44:09 -0500 (CDT) (envelope-from adam@nostrum.com)
X-Authentication-Warning: raven.nostrum.com: Host [172.58.105.103] claimed to be [IPv6:2607:fb90:44aa:b118:5981:814c:87d4:49b2]
Content-Type: multipart/alternative; boundary="Apple-Mail-C09A0317-F3AD-4B46-BC0B-AFC7889FA7E5"
Mime-Version: 1.0 (1.0)
Subject: Re: Adam Roach's No Objection on draft-ietf-6man-rfc6434-bis-08: (with COMMENT)
From: Adam Roach <adam@nostrum.com>
X-Mailer: iPhone Mail (15F79)
In-Reply-To: <CAOSSMjXUUeqx0AfLiiWgEzpr2d-xx+8_SxS7gDXECte5RnKzNg@mail.gmail.com>
Date: Wed, 11 Jul 2018 15:44:03 -0500
Cc: Bob Hinden <bob.hinden@gmail.com>, 6man-chairs@ietf.org, 6man WG <ipv6@ietf.org>, iesg@ietf.org, draft-ietf-6man-rfc6434-bis@ietf.org
Content-Transfer-Encoding: 7bit
Message-Id: <00F629E7-4DFD-460F-A73F-1B50244E41FE@nostrum.com>
References: <153057934734.16104.13071075275784411625.idtracker@ietfa.amsl.com> <CAOSSMjXUUeqx0AfLiiWgEzpr2d-xx+8_SxS7gDXECte5RnKzNg@mail.gmail.com>
To: Timothy Winters <twinters@iol.unh.edu>
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/vy1wPm1nfwQjOowjD8vzZqlWMJ8>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.27
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 11 Jul 2018 20:44:22 -0000

Thanks! Your proposed text for 8.4 seems good to me. 

/a

> On Jul 11, 2018, at 15:34, Timothy Winters <twinters@iol.unh.edu> wrote:
> 
> Hi Adam,
> 
> Thanks for taking the time to comment.   We have updated the boiler plate as suggested for draft 09.   As for Section 8.4, there was some working group discussion about this topic the suggestion in the last sentence is the guidance that working group came to.
> 
> "To maximize interoperability in such environments, hosts would need to implement multiple configuration mechanisms to ensure interoperability."
> 
> ~Tim
>> On Mon, Jul 2, 2018 at 8:55 PM Adam Roach <adam@nostrum.com> wrote:
>> 
>> The document, along with other ballot positions, can be found here:
>> https://datatracker.ietf.org/doc/draft-ietf-6man-rfc6434-bis/
>> 
>> 
>> 
>> ----------------------------------------------------------------------
>> COMMENT:
>> ----------------------------------------------------------------------
>> 
>> Thanks for the work everyone put into updating this document. I have a couple of
>> minor comments.
>> 
>> ---------------------------------------------------------------------------
>> 
>> §2:
>> >  The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
>> >  "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
>> >  document are to be interpreted as described in RFC 2119 [RFC2119].
>> 
>> Please update this to the boilerplate in RFC 8174.
>> 
>> The document's use of capitalized versus non-capitalized versions of these terms
>> appears to be inconsistent. In many cases, lowercase forms appear to be used
>> when reiterating behavior that has been normatively specified in other
>> documents, which seems correct. In other places, the selection of uppercase
>> keywords appears to be fairly arbitrary (e.g., §5.3 uses a mix of "MAY" and
>> "should"). Consider doing a pass to ensure that the use of normative language is
>> consistent.
>> 
>> ---------------------------------------------------------------------------
>> 
>> With the removal of its final paragraph, §8.4 appears to only describe general
>> principles, and doesn't seem to contain any actionable requirements anymore. As
>> an implementor, I don't know what I would do to conform with its contents.
>> Consider adding concrete implementor guidance, or removing the section.
>> 
>> 
>> --------------------------------------------------------------------
>> IETF IPv6 working group mailing list
>> ipv6@ietf.org
>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>> --------------------------------------------------------------------

v2.23.0 | Report a Bug | By Email