Re: 6man w.g. last call for <draft-ietf-6man-rfc4941bis-05.txt>

Fernando Gont <fernando@gont.com.ar> Wed, 22 January 2020 07:25 UTC

Return-Path: <fernando@gont.com.ar>
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 E5085120052 for <ipv6@ietfa.amsl.com>; Tue, 21 Jan 2020 23:25:47 -0800 (PST)
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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] 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 8heKhEoe6OnW for <ipv6@ietfa.amsl.com>; Tue, 21 Jan 2020 23:25:46 -0800 (PST)
Received: from fgont.go6lab.si (fgont.go6lab.si [91.239.96.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E9EE0120013 for <ipv6@ietf.org>; Tue, 21 Jan 2020 23:25:45 -0800 (PST)
Received: from [192.168.100.103] (unknown [186.183.51.169]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id B02EE82CB8; Wed, 22 Jan 2020 08:25:38 +0100 (CET)
Subject: Re: 6man w.g. last call for <draft-ietf-6man-rfc4941bis-05.txt>
To: Erik Kline <ek.ietf@gmail.com>, Bob Hinden <bob.hinden@gmail.com>
Cc: IPv6 List <ipv6@ietf.org>
References: <20160428004904.25189.43047.idtracker@ietfa.amsl.com> <E52AF52B-6215-4EAE-9978-96CD30D0B403@gmail.com> <CAMGpriUTpyjgeFRRWoWcar_hR_RC2COppFzyqFrtP1qSn1Oe4g@mail.gmail.com>
From: Fernando Gont <fernando@gont.com.ar>
Message-ID: <4a4a0b49-297f-c751-39d8-a9e810b97967@gont.com.ar>
Date: Wed, 22 Jan 2020 03:48:56 -0300
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1
MIME-Version: 1.0
In-Reply-To: <CAMGpriUTpyjgeFRRWoWcar_hR_RC2COppFzyqFrtP1qSn1Oe4g@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/yTB_iCzJrSRpzDWp_T0mojT9L5A>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.29
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, 22 Jan 2020 07:25:48 -0000

On 15/1/20 23:40, Erik Kline wrote:
> S3.2.2: Is SHA-1 still a reasonable recommendation, given recent events?

I'd say "no". So we should just keep the suggestion for SHA-256. (good 
grief!)



> S3.5: Is the specific mention of ethernet required (or is that text just 
> an example)?

It is an example, but it is being overly specific, unnecessarily. HOw 
about if we s/ethernet/network/? Or maybe s/ethernet/link/? (which seems 
more specific and appropriate for this example)



> S3.3/3.5/general: it might be fun to call out that implementations are 
> free to create a temporary address for use by, say, only a single 
> application.  The implementation would need to make sure that only the 
> given application can use the address, that the address is expired if 
> the application terminates/releases the address before default lifetime 
> expires, and may want to make some API available for applications 
> interact with this capability.

While I do agree that being able to generate IPv6 addresses upon 
application request would be a sensible thing to have, if anything, I'd 
probably flag this in the "Future Work" section, since there would be so 
may things that would be left out of *this* spec (including the API)..

(One might also wonder if such addresses would be called "temporary" in 
the first place, since their life is more attached with the app, than 
with "time". I guess one might call them "ephemeral addresses"?)

Thoughts?

Thanks!

Cheers,
-- 
Fernando Gont
e-mail: fernando@gont.com.ar || fgont@si6networks.com
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1