Re: [OPSEC] Fwd: New Version Notification for draft-winter-opsec-netconfig-metadata-00.txt
Christian Franke <nobody@nowhere.ws> Fri, 08 April 2016 13:40 UTC
Return-Path: <nobody@nowhere.ws>
X-Original-To: opsec@ietfa.amsl.com
Delivered-To: opsec@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3104012D0FF; Fri, 8 Apr 2016 06:40:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.911
X-Spam-Level:
X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-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 2na0yiz8YZkD; Fri, 8 Apr 2016 06:40:46 -0700 (PDT)
Received: from athena.nowhere.ws (athena.nowhere.ws [146.0.105.76]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6154712D8B3; Fri, 8 Apr 2016 06:40:46 -0700 (PDT)
Received: from [31.133.176.90] (dhcp-b05a.meeting.ietf.org [31.133.176.90]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by athena.nowhere.ws (qmail) with ESMTPSA id C62DFE005; Fri, 8 Apr 2016 13:40:43 +0000 (UTC)
To: Stefan Winter <stefan.winter@restena.lu>, IETF OPSEC <opsec@ietf.org>
References: <20160321092737.6013.75371.idtracker@ietfa.amsl.com> <56EFBF2D.5090904@restena.lu>
From: Christian Franke <nobody@nowhere.ws>
Message-ID: <5707B4D9.9010508@nowhere.ws>
Date: Fri, 08 Apr 2016 10:40:41 -0300
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.7.1
MIME-Version: 1.0
In-Reply-To: <56EFBF2D.5090904@restena.lu>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/opsec/CbQLgDyd83_ifHUnNotgXPUjpD0>
Cc: "opsawg@ietf.org" <opsawg@ietf.org>
Subject: Re: [OPSEC] Fwd: New Version Notification for draft-winter-opsec-netconfig-metadata-00.txt
X-BeenThere: opsec@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: opsec wg mailing list <opsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/opsec>, <mailto:opsec-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/opsec/>
List-Post: <mailto:opsec@ietf.org>
List-Help: <mailto:opsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/opsec>, <mailto:opsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 08 Apr 2016 13:40:58 -0000
On 03/21/2016 06:30 AM, Stefan Winter wrote: > this is the draft corresponding to my agenda slot request from last week. > Name: draft-winter-opsec-netconfig-metadata > Revision: 00 I have just read through your draft. In my opinion, it would be very useful to have a standardized way to provide configuration profiles to users. Looking through the draft and the yang file, I came up with the following notes: Comments on the draft: - it would be useful if subject alt match could be configured for usage with e.g. EAP-TTLS - how would the private key for a client certificate be stored, also in `cert-data`? I don't see another suitable field - which information does `allow-save` apply to? If it applies to the private key of a client certificate, how would public key authentication work without storing it? - can you provide a usecase for the `valid-until` field? - it is not obvious to me how the current model applies to VPN or E-Mail Server connections as named in the draft - it is not clear to me how an anonymous identify for EAP-TTLS or EAP-PEAP would be configured - I think it would be useful to have some consideration, either in this or another document, about how the files procuded according to this model should be processed, i.e. requirements on how their authenticity must be verified, how they should be displayed to the users and in what configuration they should actually result. Yang related: - there is a type leafref which should probably used when referring to config parts by UUID - there are types for ipv4 and ipv6 addresses that should be used instead of string - list IPAddress has dynamic and static as keys, keys need to be unique, so how to enable both dhcpv4 and dhcpv6? Same thing e.g. for DNS -Christian
- [OPSEC] Fwd: New Version Notification for draft-w… Stefan Winter
- Re: [OPSEC] Fwd: New Version Notification for dra… Stefan Winter
- Re: [OPSEC] Fwd: New Version Notification for dra… Christian Franke