Re: [Gen-art] review of draft-ietf-homenet-hncp-09.txt

Jari Arkko <jari.arkko@piuha.net> Thu, 19 November 2015 10:52 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 (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9DDDD1B31E5; Thu, 19 Nov 2015 02:52:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.485
X-Spam-Level:
X-Spam-Status: No, score=-2.485 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.585] autolearn=ham
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 3a9qYu5Zqsm1; Thu, 19 Nov 2015 02:52:36 -0800 (PST)
Received: from p130.piuha.net (p130.piuha.net [IPv6:2a00:1d50:2::130]) by ietfa.amsl.com (Postfix) with ESMTP id 7107A1B31E1; Thu, 19 Nov 2015 02:52:35 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id B72042CC5C; Thu, 19 Nov 2015 12:52:34 +0200 (EET) (envelope-from jari.arkko@piuha.net)
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 rwjvHxxyGEpA; Thu, 19 Nov 2015 12:52:33 +0200 (EET)
Received: from [127.0.0.1] (p130.piuha.net [IPv6:2a00:1d50:2::130]) by p130.piuha.net (Postfix) with ESMTP id 61B7A2CC52; Thu, 19 Nov 2015 12:52:33 +0200 (EET) (envelope-from jari.arkko@piuha.net)
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
Content-Type: multipart/signed; boundary="Apple-Mail=_7F72B7E5-A341-493F-A7DF-C8D08C0FFAD5"; protocol="application/pgp-signature"; micalg=pgp-sha512
X-Pgp-Agent: GPGMail 2.5.1
From: Jari Arkko <jari.arkko@piuha.net>
In-Reply-To: <D2DEC2CD-F51A-4F64-8225-0975D7822F6D@iki.fi>
Date: Thu, 19 Nov 2015 12:52:34 +0200
Message-Id: <E739645F-971A-4963-B571-F3A860CC105A@piuha.net>
References: <201510271200.t9RC0PfB015736@givry.fdupont.fr> <D2DEC2CD-F51A-4F64-8225-0975D7822F6D@iki.fi>
To: Markus Stenberg <markus.stenberg@iki.fi>, Francis Dupont <Francis.Dupont@fdupont.fr>
X-Mailer: Apple Mail (2.1878.6)
Archived-At: <http://mailarchive.ietf.org/arch/msg/gen-art/hs3f-uUfE_8lGZ0xAMDweWG9F-o>
Cc: draft-ietf-homenet-hncp.all@ietf.org, General Area Review Team <gen-art@ietf.org>
Subject: Re: [Gen-art] review of draft-ietf-homenet-hncp-09.txt
X-BeenThere: gen-art@ietf.org
X-Mailman-Version: 2.1.15
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: <https://mailarchive.ietf.org/arch/browse/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: Thu, 19 Nov 2015 10:52:37 -0000

Francis, many thanks for your detailed review! Markus et al: thank you for making edits.

I have balloted no-obj for this document on today’s IESG telechat.

Jari

On 13 Nov 2015, at 11:30, Markus Stenberg <markus.stenberg@iki.fi> wrote:

> First of all, thanks for the review.
> 
> Steven Barth already incorporated some of the comments but did not reply, so I am here to provide inline answers to the rest.
> The ‘fixed’ things are addressed in git staged version (to-be -10; we are waiting for further IESG-caused reviews before publishing).
> 
> On 27.10.2015, at 14.00, Francis Dupont <Francis.Dupont@fdupont.fr> wrote:
>> Nits/editorial comments:
>> - ToC page 3 and D page 38: Acknowledgements -> Acknowledgments
>> (BTW usually the Acknowledgments section is a section, i.e., not
>>  an appendix)
>> 
>> - 1 page 3: please introduce the HNCP abbrev
>> 
>> - 1 page 4: lease introduce the DNCP abbrev
>> 
>> - 5.1 page 9: please add the title of RFC 6092
>> 
>> - 6.2 page 12: Announcements of individual external connections may consist
>> (ambiguous “may": please change it for a synonym or a MAY)
> 
> Fixed.
> 
>> - 7.1 page 19: there are new (i.e., other than 4861 or 3315) ways
>> to build not-temporary IPv6 addresses. Perhaps wording should be
>> updated to include them? In doubt please contact Fernando Gont
>> who is (co-)author of most of them.
> 
> I am not sure how this is relevant. At least RFC7217 is essentially just 4861 with slightly different address bits (which are irrelevant to us; all we care is someone is doing something based on A-bit being set to 1).
> 
> We do not define host behavior, and router behavior is the same regardless; either you send RAs with A/M bits, or you do not.
> 
>> - 9 page 21: (=DTLS) -> (i.e., DTLS) or something more written...
>> 
>> - 9 page 22: the Managed PSK TLV must generate -> MUST?
>> 
>> - 9 page 22 last paragraph: this should be submitted to the security
>> directorate to check if it is secured (IMHO it is) or if there is
>> a better solution.
> 
> I am not sure what this refers to. Looking at -09 on datatracker, last paragraph of page 22 is:
> 
>   An External Connection TLV is a container TLV used to gather network
>   configuration information associated with a single external
>   connection (
> Section 6.2
> ) to be shared across the HNCP network.  A
>   node MAY publish an arbitrary number of instances of this TLV to
>   share the desired number of external connections.  Upon reception,
> 
>> - 10.1 page 22 and many other places: I deeply dislike the way open
>> fields are displayed in your ASCII art.
> 
> What would be your preference be? We did not get push-back for using same format in DNCP so ideally we would like to stay consistent.
> 
>> - 10.2.1.1 page 25: I have many concerns about "DNS Zone":
>> * first it should be a DNS domain (note the term zone has a specific
>>   meaning for DNS)
>> * it should be not compressed
>> * it should be terminated by . (coded as an empty label).
>> For the last 2 points 10.6 page 29 has them so a reference is enough.
> 
> Hm, attempted to correct it bit in upcoming version and cut-n-pasted the two extra requirements from 10.6 here (as well as as to 10.5) as we usually get flak for too many references.
> 
>> - 10.5 pages 28 and 29: 3 should -> SHOULD?
> 
> Fixed.
> 
>> - 12.1 page 33: (for your info) there is a secure DHCPv6 I-D under
>> IESG review which should bring more security to DHCP (at least far
>> better than current "authentication" which is both poor as a security
>> point of view and deployed nowhere...
> 
> I doubt it will ever be deployed anywhere in volume as it requires provisioning on both ends of the connection; however, I will be happy to be proven wrong.
> (If you have non-zeroconfiguration setup on both ends of the link, you do not need interface classification either. Zeroconfiguration + security is  .. hard.)
> 
> Cheers,
> 
> -Markus
> _______________________________________________
> Gen-art mailing list
> Gen-art@ietf.org
> https://www.ietf.org/mailman/listinfo/gen-art