All of lore.kernel.org
 help / color / mirror / Atom feed
From: Stefan Schmidt <stefan@osg.samsung.com>
To: Alexander Aring <alex.aring@gmail.com>,
	Simon Vincent <simon.vincent@xsilon.com>
Cc: linux-wpan@vger.kernel.org
Subject: Re: The 802.15.4 Security Layer
Date: Fri, 26 Jun 2015 11:45:32 +0200	[thread overview]
Message-ID: <558D1F3C.8050105@osg.samsung.com> (raw)
In-Reply-To: <20150626093218.GA5074@omega>

Hello.

On 26/06/15 11:32, Alexander Aring wrote:
> On Fri, Jun 26, 2015 at 09:56:36AM +0100, Simon Vincent wrote:
>> Ok yes this makes sense.
>>
>> Let me know if there is any bits I can help on.
>>
> I added more stuff into the branch [0], fix some embarrassingly mistakes.
>
> Yesterday I talked with Phoebe about "very simple to use" usecase for
> the userspace application.
>
> In the discussion we end with the idea to have an userspace application
> for load/store the security mib.
>
> Phoebe said it should be something like what iptables do:
>
> Like "ip6tables-save" and "ip6tables-restore".
>
> This will simple save the actual mib in a file and restore them from file,
> these files should contain the same file format for representing the mib.
> Later there should be also the possibility to change the mib during
> runtime while a mib is already loaded, but at first the save/restore
> sounds the most use case. You can still manipulate the mib security
> structure in the configuration file which represents the mib, but need
> to run a completely restore afterwards.
>
>
> Maybe we can start a discussion about the "file format" which represents
> the mib. This should be some simple format. Not xml/json which
> adds library dependencies.
>
I'm still not 100% sold on the idea that we only want to allow the whole 
sec mib to be loaded and saved and not single properties. Having the 
option to set/get single mib sec properties would be useful and in line 
with all the other properties we handle in iwpan right now.

What I capture from your and Phoebe's mails is that you want to have one 
policy file with all options in them to avoid broken configurations and 
problems to debug this, right?
We still would need logic inside iwpan to detect and ignore these 
invalid configs. We could use the same logic when setting single properties.

Don't get me wrong I'm fine having one file with all options in it I 
just think that having the possibility to set them individually might 
aloy be a benefit.Maybe I over engineer it. Don't know.

Coming back to the file format. I like the plain ini format for such 
cases. Its' plain text but still has some strcutre and key value pairs. 
A realy benefit imho is that it is also easy to read and modified by humans.

regards
Stefan Schmidt


  reply	other threads:[~2015-06-26  9:45 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-06-18 12:31 The 802.15.4 Security Layer Alexander Aring
2015-06-18 15:42 ` Stefan Schmidt
2015-06-18 15:58   ` Simon Vincent
2015-06-18 19:43     ` Stefan Schmidt
2015-06-23 15:34       ` Simon Vincent
2015-06-23 16:00         ` Simon Vincent
2015-06-24 10:00         ` Alexander Aring
2015-06-24 14:01           ` Alexander Aring
2015-06-26  8:56             ` Simon Vincent
2015-06-26  9:32               ` Alexander Aring
2015-06-26  9:45                 ` Stefan Schmidt [this message]
2015-06-26  9:58                   ` Alexander Aring
2015-06-26 10:14                     ` Stefan Schmidt
2015-06-26 10:24                       ` Alexander Aring
2015-06-26 11:20                         ` Alexander Aring
2015-06-21 21:12 ` Alexander Aring
2015-06-22 12:33   ` Phoebe Buckheister
2015-06-23 11:03     ` Alexander Aring
2015-06-23 12:46       ` Phoebe Buckheister

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=558D1F3C.8050105@osg.samsung.com \
    --to=stefan@osg.samsung.com \
    --cc=alex.aring@gmail.com \
    --cc=linux-wpan@vger.kernel.org \
    --cc=simon.vincent@xsilon.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.