Re: [netmod] schema mount and YANG library

[Lou Berger <[e-mail]>]

On January 16, 2018 8:24:42 AM Martin Bjorklund <[e-mail]> wrote:

> Lou Berger <[e-mail]> wrote:
>> Lada,
>>
>>
>> On January 16, 2018 7:07:15 AM Ladislav Lhotka <[e-mail]> wrote:
>>
>> > On Tue, 2018-01-16 at 06:30 -0500, Lou Berger wrote:
>> >> Lada,
>> >>
>> >> It sounds like you are proposing in (1) a fairly significant change in
>> >> the
>> >> direction of the draft and in (2) a basic approach that has been
>> >
>> > It is no change in direction, just a simplification of the
>> > schema-describing
>> > state data. Given the recent developments in 7895bis it makes no sense
>> > to me to
>> > have two "schema" lists if we can have just one.
>> >
>>
>> Managing transition is hard. It's also highlights why Yang Library
>> this needs to be at least equally discussed in this group.
>>
>> I will talk with my co-chairs and perhaps the ADs to get their opinion
>> on making such a change this point in the process.
>>
>>
>> >>
>> >> rejectected by the WG multiple times.  FWIW there are drafts already
>> >> with
>> >
>> > No at all. The first and last time I proposed this was on 15 December
>> > 2017:
>> >
>> > https://www.ietf.org/mail-archive/web/netmod/current/msg19753.html
>> >
>>
>> Oh, I certainly would call you proposing that the schema for inline be
>> part of the rest of the schema Mount module well before that. I'm sure
>> I can dig up mail / slides it really necessary...
>
> I don't think this has been proposed before.  All previous proposals
> were basically variants on what is now "use-schema", which works fine
> when all instances have the same schema.  This new proposal solves the
> issue with different schemas in different instances.
>

I thought the previous proposals that as well, so don't see material 
difference - at least from the usage standpoint. I also don't see why the 
previous arguments that resulted in consensus for using Yang Library 
underneath the an in line Mount Point don't apply.

Lou

>> > The only reply was from you. To me, it is the cleanest solution of the
>> > inline
>> > case. Of course, I am open to technical objections.
>> >
>>
>> I'm sure I can find material on this as well....
>
> Ok.
>
>
> /martin
>
>
>>
>> Lou
>>
>> > If it's not clear what I mean, I can make up some examples.
>> >
>> > Lada
>> >
>> >
>> >> the iesg that will need to be returned to their WGs if either change
>> >> is made.
>> >>
>> >> Martin,
>> >>
>> >> Do share Lada's view?
>> >>
>> >> Lou
>> >>
>> >>
>> >> On January 16, 2018 2:14:42 AM Ladislav Lhotka <[e-mail]> wrote:
>> >>
>> >> > Hi Lou,
>> >> >
>> >> > in my view, we should do the following two (significant) changes:
>> >> >
>> >> > 1. Instead of borrowing a grouping from ietf-yang-library and having a
>> >> > parallel
>> >> > list of mounted schemas, we should keep *all* mounted schemas directly
>> >> > in
>> >> > the
>> >> > YANG library and refer to them from schema-mounts structures. Juergen
>> >> > suggested
>> >> > this change and it is IMO the right thing to do.
>> >> >
>> >> > 2. Define a metadata annotation (e.g. @schema-ref) that would be
>> >> > required
>> >> > for
>> >> > inline mount point instances and specify the inline-mounted schema
>> >> > also by
>> >> > referring to a schema specified in YANG library.
>> >> >
>> >> > The advantage of #2 is that an annotation can be attached equally well
>> >> > to
>> >> > both
>> >> > state an configuration data. So, instead of papering over the issue
>> >> > that
>> >> > YANG
>> >> > library (state data) cannot appear in configuration datastores, we can
>> >> > use
>> >> > this
>> >> > general and straightforward approach. This also allows for defining
>> >> > different
>> >> > mounted schemas for instances of the same mount point in different
>> >> > datastores.
>> >> >
>> >> > I strongly believe that these changes (along with the new YANG library
>> >> > schema
>> >> > and NMDA) make for a simple and elegant datastore architecture in
>> >> > which
>> >> > schema
>> >> > mount would be an optional feature.
>> >> >
>> >> > Lada
>> >> >
>> >> >
>> >> >
>> >> > On Mon, 2018-01-15 at 16:20 -0500, Lou Berger wrote:
>> >> > > Lada/Martin,
>> >> > >
>> >> > > I don't believe we reached closure on this discussion.  The open
>> >> > > issues
>> >> > > relate to proposed new text (slightly modified):
>> >> > >
>> >> > > at the end of the section [3.2] adding a new paragraph along the
>> >> > > lines of:
>> >> > >
>> >> > >    The use of mount points does not impact the nature of the
>> >> > >    mounted data or in which data store information is made
>> >> > >    available. For example, mounted YANG Library modules define
>> >> > >    only operational state data and, as such, the information in
>> >> > >    these modules is available from operational data stores using
>> >> > >    the appropriate protocol operations.  It is also worth
>> >> > >    noting that the Schema Mount module itself parallels the
>> >> > >    YANG Library module and only defines operational state data.
>> >> > >
>> >> > > Is this change acceptable?
>> >> > >
>> >> > > What other issues related to SM are outstanding?
>> >> > >
>> >> > > Thank you,
>> >> > >
>> >> > > Lou
>> >> > >
>> >> > > On 12/19/2017 8:26 AM, Ladislav Lhotka wrote:
>> >> > > > On Tue, 2017-12-19 at 07:49 -0500, Lou Berger wrote:
>> >> > > > > On 12/19/2017 7:36 AM, Ladislav Lhotka wrote:
>> >> > > > > > On Tue, 2017-12-19 at 06:43 -0500, Lou Berger wrote:
>> >> > > > > > > Hi Lada,
>> >> > > > > > >
>> >> > > > > > > On 12/19/2017 6:23 AM, Ladislav Lhotka wrote:
>> >> > > > > > > > On Tue, 2017-12-19 at 06:20 -0500, Lou Berger wrote:
>> >> > > > > > > > > Lada,
>> >> > > > > > > > >
>> >> > > > > > > > >
>> >> > > > > > > > > On December 19, 2017 1:12:35 AM Ladislav Lhotka
>> >> > > > > > > > > <[e-mail]
>> >> > > > > > > > > >
>> >> > > > > > > > > wrote:
>> >> > > > > > > > >
>> >> > > > > > > > > > On Mon, 2017-12-18 at 15:30 -0500, Lou Berger wrote:
>> >> > > > > > > > > > > lada,
>> >> > > > > > > > > > >
>> >> > > > > > > > > > >      See below.
>> >> > > > > > > > > > >
>> >> > > > > > > > > > >
>> >> > > > > > > > > > > On 12/15/2017 8:59 AM, Ladislav Lhotka wrote:
>> >> > > > > > > > > > > > Hi,
>> >> > > > > > > > > > > >
>> >> > > > > > > > > > > > unfortunately, using an action for querying embedded
>> >> > > > > > > > > > > > YANG
>> >> > > > > > > > > > > > library
>> >> > > > > > > > > > > > data
>> >> > > > > > > > > > > > (needed for the "inline" case of schema mount)
>> >> > > > > > > > > > > > doesn't
>> >> > > > > > > > > > > > work
>> >> > > > > > > > > > > > either
>> >> > > > > > > > > > > > because now under NMDA actions can be used only on
>> >> > > > > > > > > > > > instances
>> >> > > > > > > > > > > > in
>> >> > > > > > > > > > > > the
>> >> > > > > > > > > > > > <operational> datastore.
>> >> > > > > > > > > > >
>> >> > > > > > > > > > > but the inline/embedded library would (only) be present
>> >> > > > > > > > > > > in
>> >> > > > > > > > > > > the
>> >> > > > > > > > > > > in
>> >> > > > > > > > > > > the
>> >> > > > > > > > > > > operational datastore, so what's the issue?
>> >> > > > > > > > > >
>> >> > > > > > > > > > Well, the issue is described in my initial mail of this
>> >> > > > > > > > > > thread:
>> >> > > > > > > > > > the
>> >> > > > > > > > > > current
>> >> > > > > > > > > > text
>> >> > > > > > > > > > requires that every instance of an inline mount point
>> >> > > > > > > > > > contains
>> >> > > > > > > > > > the
>> >> > > > > > > > > > embedded
>> >> > > > > > > > > > YANG library. Tha latter is state data, so the above
>> >> > > > > > > > > > requirement
>> >> > > > > > > > > > cannot
>> >> > > > > > > > > > be
>> >> > > > > > > > > > satisfied if the mount point instance is in a
>> >> > > > > > > > > > configuration
>> >> > > > > > > > > > datastore.
>> >> > > > > > > > > >
>> >> > > > > > > > >
>> >> > > > > > > > > That's not how I read the intent of the current text.  I
>> >> > > > > > > > > don't
>> >> > > > > > > > > see
>> >> > > > > > > > > SM
>> >> > > > > > > > > impacting which data stores information is presented.  Just
>> >> > > > > > > > > like
>> >> > > > > > > > > use
>> >> > > > > > > > > of
>> >> > > > > > > > > scheme mount doesn't transform RO configuration information
>> >> > > > > > > > > into
>> >> > > > > > > > > operational information.  I sent you a couple of sentences
>> >> > > > > > > > > clarifying
>> >> > > > > > > > > this
>> >> > > > > > > > > at one point, I'll dig up the proposed text and resend.
>> >> > > > > > > >
>> >> > > > > > > > Please do, this has to be discussed in the WG mailing list.
>> >> > > > > > >
>> >> > > > > > > Agreed - that's why I asked to start this thread!
>> >> > > > > > >
>> >> > > > > > > Here's the original proposal:
>> >> > > > > > >
>> >> > > > > > >    How about at the end of the section [3.2] adding a new
>> >> > > > > > >    paragraph along the lines of:
>> >> > > > > > >
>> >> > > > > > >    It is important to note that both YANG Library and Schema
>> >> > > > > > >    Mount Modules contain only operational state data. As such,
>> >> > > > > >
>> >> > > > > > s/contain/define/
>> >> > > > > >
>> >> > > > > > >    the information in these modules should be retrieved by
>> >> > > > > > >    clients from operational data stores using the appropriate
>> >> > > > > >
>> >> > > > > > This is based on two assumptions:
>> >> > > > > >
>> >> > > > > > 1. For every configuration datastore there is a corresponding
>> >> > > > > > operational
>> >> > > > > > datastore.
>> >> > > > >
>> >> > > > > well the text is revised below.  In any case, "these modules"
>> >> > > > > refers
>> >> > > > > to
>> >> > > > > yang library, and yes, I'm assuming YL is always and only in
>> >> > > > > operational.  If the revised text below isn't clear s/these/YANG
>> >> > > > > Library/
>> >> > > > > -
>> >> > > >
>> >> > > > The thing is that we have the top-level YANG library in
>> >> > > > <operational>,
>> >> > > > and
>> >> > > > then
>> >> > > > embedded YANG libraries scattered inside inline mount point
>> >> > > > instances.
>> >> > > >
>> >> > > > > > 2. For every mount point instance in any configuration datastore
>> >> > > > > > there
>> >> > > > > > is a
>> >> > > > > > corresponding mount point instance (with the same path) in an
>> >> > > > > > operational
>> >> > > > > > datastore.
>> >> > > > > >
>> >> > > > > > I think that neither of these has to be true in general.
>> >> > > > >
>> >> > > > > agreed in general, but for inline, where YL is required, it must be
>> >> > > > > true.
>> >> > > >
>> >> > > > How do you know? I provided an example in Singapore where a mount
>> >> > > > point
>> >> > > > instance
>> >> > > > in <intended> is a part of pre-provisioned data (for non-existent
>> >> > > > hardware).
>> >> > > > Then, according to the NMDA rules there is no corresponding instance
>> >> > > > in
>> >> > > > <operational>, hence no place where the embedded YANG library can be
>> >> > > > placed.
>> >> > > > (I can easily provide a concrete example if needed).
>> >> > > >
>> >> > > >
>> >> > > > Dean replied that this cannot happen, so it seems there are some
>> >> > > > assumptions
>> >> > > > how
>> >> > > > the inline method of schema mount may be applied. If so, these
>> >> > > > assumptions
>> >> > > > have
>> >> > > > to be explicitly stated.
>> >> > > >
>> >> > > > > > >    protocol operations.
>> >> > > > > >
>> >> > > > > > In contrast, the substance of my proposal with metadata
>> >> > > > > > annotations
>> >> > > > > > is
>> >> > > > > > to be
>> >> > > > > > able to retrieve all schemas from a well-known location in *the*
>> >> > > > > > <operational>
>> >> > > > > > datastore, namely from the top-level YANG library.
>> >> > > > >
>> >> > > > > What about a schema that is based on dll that contains modules that
>> >> > > > > isn't loaded until a mount point is instantiated -- this is
>> >> > > > > certainly
>> >> > > > > a
>> >> > > > > valid approach for supporting LNEs, but would be precluded in this
>> >> > > > > approach.  I really don't think a top level approach works for all
>> >> > > > > inline (managed) types of mounts.
>> >> > > >
>> >> > > > It isn't precluded: when the mount point is instantiated (no matter
>> >> > > > which
>> >> > > > datastore it is in), the server adds the schema as a new entry to the
>> >> > > > "schema"
>> >> > > > list in the top level YANG library (with a unique key), and annotates
>> >> > > > the
>> >> > > > mount
>> >> > > > point instance with a leafref pointing to that key. So different
>> >> > > > instances
>> >> > > > of
>> >> > > > the same mount point can have different schemas.
>> >> > > >
>> >> > > > > > > Given this discussion, we can generalize it further to:
>> >> > > > > > >
>> >> > > > > > >    The use of mount points does not impact the nature of the
>> >> > > > > > >    mounted data or in which data store information is made
>> >> > > > > > >    available. For example, mounted YANG Library modules contain
>> >> > > > > > >    only operational state data and, as such, the information in
>> >> > > > > > >    these modules is available from operational data stores
>> >> > > > > > >    using
>> >> > > > > > >    the appropriate protocol operations.
>> >> > > > > >
>> >> > > > > > The whole question here is whether and how we can locate the
>> >> > > > > > schema
>> >> > > > > > for
>> >> > > > > > an
>> >> > > > > > inline mount point in any configuration datastore.
>> >> > > > >
>> >> > > > > Why is a mounted YL different than a top level YL?  What works for
>> >> > > > > and
>> >> > > >
>> >> > > > It is not different, but it can be only in an operational datastores,
>> >> > > > and so
>> >> > > > for
>> >> > > > mount point instances inside configuration datastores we need a way
>> >> > > > how
>> >> > > > to
>> >> > > > locate the schema for that mount point, because it cannot be found
>> >> > > > directly
>> >> > > > under the mount point instance (as the current text assumes).
>> >> > > >
>> >> > > > > is sufficient for the normal case of YL shouldn't be impacted or
>> >> > > > > modified by SM -- at least that's how I thought we've been talking
>> >> > > > > about
>> >> > > > > since SM was started.  Again, we never made any special provisions
>> >> > > > > for
>> >> > > > > any other rw/ro/state data, assuming top level YL is not handled as
>> >> > > > > metadata, why start now?
>> >> > > > >
>> >> > > > > I'm getting the impression that your argument may be more about if
>> >> > > > > YL
>> >> > > > > should be treated as something other than operational data, is this
>> >> > > > > wrong?
>> >> > > >
>> >> > > > This is wrong. My argument is that there should be only one top-level
>> >> > > > YANG
>> >> > > > library (state data) and each inline mount point instance just points
>> >> > > > to
>> >> > > > a
>> >> > > > schema inside it by means of a metadata annotation attached to the
>> >> > > > mount
>> >> > > > point
>> >> > > > (in any datastore).
>> >> > > >
>> >> > > > Lada
>> >> > > >
>> >> > > > > Thanks,
>> >> > > > > Lou
>> >> > > > >
>> >> > > > > > Lada
>> >> > > > > >
>> >> > > > > > > Lou
>> >> > > > > > >
>> >> > > > > > > > Lada
>> >> > > > > > > >
>> >> > > > > > > > > Lou
>> >> > > > > > > > > > > > However, a good alternative seems to be a metadata
>> >> > > > > > > > > > > > annotation
>> >> > > > > > > > > > > > along
>> >> > > > > > > > > > > > the
>> >> > > > > > > > > > > > lines of RFC 7952, for example with the alternative B
>> >> > > > > > > > > > > > of
>> >> > > > > > > > > > > > the
>> >> > > > > > > > > > > > newly
>> >> > > > > > > > > > > > proposed YANG library schema:
>> >> > > > > > > > > > > >
>> >> > > > > > > > > > > >       md:annotation schema-ref {
>> >> > > > > > > > > > > >         type leafref {
>> >> > > > > > > > > > > >           path "/yanglib:yang-
>> >> > > > > > > > > > > > library/yanglib:schema/yanglib:name";
>> >> > > > > > > > > > > >         }
>> >> > > > > > > > > > > >       }
>> >> > > > > > > > > > > >
>> >> > > > > > > > > > > > In other words, all inline mounted schemas would be
>> >> > > > > > > > > > > > included
>> >> > > > > > > > > > > > in
>> >> > > > > > > > > > > > the
>> >> > > > > > > > > > > > top-level YANG library, and mount point instances in
>> >> > > > > > > > > > > > all
>> >> > > > > > > > > > > > datastores
>> >> > > > > > > > > > > > would be annotated with leafref pointing to the
>> >> > > > > > > > > > > > actual
>> >> > > > > > > > > > > > schema.
>> >> > > > > > > > > > > >
>> >> > > > > > > > > > > > Unlike regular state data, it is IMO no problem to
>> >> > > > > > > > > > > > permit
>> >> > > > > > > > > > > > such
>> >> > > > > > > > > > > > annotations in configuration datastores.
>> >> > > > > > > > > > > >
>> >> > > > > > > > > > > > Opinions?
>> >> > > > > > > > > > >
>> >> > > > > > > > > > > I'm not sure this will work for all architectures of
>> >> > > > > > > > > > > LNEs
>> >> > > > > > > > > > > as
>> >> > > > > > > > > > > well
>> >> > > > > > > > > > > as
>> >> > > > > > > > > > > other possible future use cases.  In short, this seems
>> >> > > > > > > > > > > *very*
>> >> > > > > > > > > > > restrictive.
>> >> > > > > > > > > >
>> >> > > > > > > > > > I don't understand, IMO it is not restrictive at
>> >> > > > > > > > > > all. What
>> >> > > > > > > > > > kind
>> >> > > > > > > > > > of
>> >> > > > > > > > > > restrictions
>> >> > > > > > > > > > do you see?
>> >> > > > > > > > > >
>> >> > > > > > > > > > Lada
>> >> > > > > > > > > >
>> >> > > > > > > > > > > Lou
>> >> > > > > > > > > > >
>> >> > > > > > > > > > > > Thanks, Lada
>> >> > > > > > > > > > > >
>> >> > > > > > > > > > > > Ladislav Lhotka <[e-mail]> writes:
>> >> > > > > > > > > > > >
>> >> > > > > > > > > > > > > Hi,
>> >> > > > > > > > > > > > >
>> >> > > > > > > > > > > > > the following text in sec. 3.2 of schema-mount-08
>> >> > > > > > > > > > > > > is
>> >> > > > > > > > > > > > > wrong
>> >> > > > > > > > > > > > > for
>> >> > > > > > > > > > > > > traditional
>> >> > > > > > > > > > > > > datastores, and even more so for NDMA:
>> >> > > > > > > > > > > > >
>> >> > > > > > > > > > > > >     In case 1 ["inline"], the mounted schema is
>> >> > > > > > > > > > > > > determined
>> >> > > > > > > > > > > > > at
>> >> > > > > > > > > > > > > run
>> >> > > > > > > > > > > > > time:
>> >> > > > > > > > > > > > > every
>> >> > > > > > > > > > > > >     instance of the mount point that exists in the
>> >> > > > > > > > > > > > > parent
>> >> > > > > > > > > > > > > tree
>> >> > > > > > > > > > > > > MUST
>> >> > > > > > > > > > > > >     contain a copy of YANG library data [RFC7895]
>> >> > > > > > > > > > > > >     that
>> >> > > > > > > > > > > > > defines
>> >> > > > > > > > > > > > > the
>> >> > > > > > > > > > > > >     mounted schema exactly as for a top-level data
>> >> > > > > > > > > > > > > model.  A
>> >> > > > > > > > > > > > > client
>> >> > > > > > > > > > > > > is
>> >> > > > > > > > > > > > >     expected to retrieve this data from the
>> >> > > > > > > > > > > > >     instance
>> >> > > > > > > > > > > > > tree,
>> >> > > > > > > > > > > > > possibly
>> >> > > > > > > > > > > > > after
>> >> > > > > > > > > > > > >     creating the mount point.  Instances of the
>> >> > > > > > > > > > > > >     same
>> >> > > > > > > > > > > > > mount
>> >> > > > > > > > > > > > > point
>> >> > > > > > > > > > > > > MAY
>> >> > > > > > > > > > > > > use
>> >> > > > > > > > > > > > >     different mounted schemas.
>> >> > > > > > > > > > > > >
>> >> > > > > > > > > > > > > An instance of the mount point in any
>> >> > > > > > > > > > > > > *configuration*
>> >> > > > > > > > > > > > > datastores
>> >> > > > > > > > > > > > > cannot
>> >> > > > > > > > > > > > > contain
>> >> > > > > > > > > > > > > YANG library (being state data), and so the MUST
>> >> > > > > > > > > > > > > cannot
>> >> > > > > > > > > > > > > hold.
>> >> > > > > > > > > > > > >
>> >> > > > > > > > > > > > > It is not clear to me how to repair this without
>> >> > > > > > > > > > > > > considerable
>> >> > > > > > > > > > > > > complications
>> >> > > > > > > > > > > > > and/or a lot of handwaving. There is actually one
>> >> > > > > > > > > > > > > good
>> >> > > > > > > > > > > > > solution
>> >> > > > > > > > > > > > > but it
>> >> > > > > > > > > > > > > has
>> >> > > > > > > > > > > > > impact on YANG library: the server could provide it
>> >> > > > > > > > > > > > > in
>> >> > > > > > > > > > > > > a
>> >> > > > > > > > > > > > > reply
>> >> > > > > > > > > > > > > to
>> >> > > > > > > > > > > > > an
>> >> > > > > > > > > > > > > operation,
>> >> > > > > > > > > > > > > say "get-yang-library" rather than as state
>> >> > > > > > > > > > > > > data. Then
>> >> > > > > > > > > > > > > everything
>> >> > > > > > > > > > > > > would be
>> >> > > > > > > > > > > > > fine
>> >> > > > > > > > > > > > > - this operation would turn into an action for the
>> >> > > > > > > > > > > > > mount
>> >> > > > > > > > > > > > > point,
>> >> > > > > > > > > > > > > and it
>> >> > > > > > > > > > > > > can
>> >> > > > > > > > > > > > > be
>> >> > > > > > > > > > > > > used equally well for config true and false mount
>> >> > > > > > > > > > > > > points.
>> >> > > > > > > > > > > > >
>> >> > > > > > > > > > > > > So my proposal is to move from YANG library as
>> >> > > > > > > > > > > > > state
>> >> > > > > > > > > > > > > data
>> >> > > > > > > > > > > > > to
>> >> > > > > > > > > > > > > an
>> >> > > > > > > > > > > > > operation.
>> >> > > > > > > > > > > > > It
>> >> > > > > > > > > > > > > could be done along with changing the YANG library
>> >> > > > > > > > > > > > > structure,
>> >> > > > > > > > > > > > > so
>> >> > > > > > > > > > > > > there
>> >> > > > > > > > > > > > > will be
>> >> > > > > > > > > > > > > little extra impact on implementations.
>> >> > > > > > > > > > > > >
>> >> > > > > > > > > > > > > Lada
>> >> > > > > > > > > > > > >
>> >> > > > > > > > > > > > > --
>> >> > > > > > > > > > > > > Ladislav Lhotka
>> >> > > > > > > > > > > > > Head, CZ.NIC Labs
>> >> > > > > > > > > > > > > PGP Key ID: 0xB8F92B08A9F76C67
>> >> > > > > > > > > > > > >
>> >> > > > > > > > > > > > > _______________________________________________
>> >> > > > > > > > > > > > > netmod mailing list
>> >> > > > > > > > > > > > > [e-mail]
>> >> > > > > > > > > > > > > https://www.ietf.org/mailman/listinfo/netmod
>> >> > > > > > > > > > >
>> >> > > > > > > > > > > _______________________________________________
>> >> > > > > > > > > > > netmod mailing list
>> >> > > > > > > > > > > [e-mail]
>> >> > > > > > > > > > > https://www.ietf.org/mailman/listinfo/netmod
>> >> > > > > > > > > >
>> >> > > > > > > > > > --
>> >> > > > > > > > > > Ladislav Lhotka
>> >> > > > > > > > > > Head, CZ.NIC Labs
>> >> > > > > > > > > > PGP Key ID: 0xB8F92B08A9F76C67
>> >> > > > > > > > > >
>> >> > >
>> >> > >
>> >> >
>> >> > --
>> >> > Ladislav Lhotka
>> >> > Head, CZ.NIC Labs
>> >> > PGP Key ID: 0xB8F92B08A9F76C67
>> >> >
>> >>
>> >>
>> > --
>> > Ladislav Lhotka
>> > Head, CZ.NIC Labs
>> > PGP Key ID: 0xB8F92B08A9F76C67
>> >
>>
>>
>