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 mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/opsec

Reply via email to