Subject: [netmod] Last Call draft-ietf-netmod-system-mgmt-05 (20130320)

From: David Kessens <[email-masked]>
Date: Tue, 5 Mar 2013 16:05:39 -0800

Hi,

I would hereby like to start a Last Call for:

http://tools.ietf.org/html/draft-ietf-netmod-system-mgmt-05

Please indicate your support by Wed March 20, 2013. Or alternatively, let us
know in the same timeframe whether there are still issues that need to be
resolved.

Thanks!

David Kessens
co-chair netmod wg
---

---

From: "Lange, Jeffrey K (GE Energy Management)" <[email-masked]>
Date: Wed, 6 Mar 2013 13:30:30 +0000

This references:

[I-D.lange-netmod-iana-timezones]
              Lange, J., "IANA Timezone Database YANG Module",
              draft-lange-netmod-iana-timezones-01 (work in progress),
              June 2012.

Which technically "expired" Does something need to happen to bring this back from the grave? Or is this OK?

-Jeff

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of David Kessens
> Sent: Tuesday, March 05, 2013 7:06 PM
> To: [email-masked]
> Subject: [netmod] Last Call draft-ietf-netmod-system-mgmt-05 (20130320)
> 
> 
> Hi,
> 
> _______________________________________________
> netmod mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netmod

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 6 Mar 2013 14:42:54 +0100

> Which technically "expired" Does something need to happen to bring this back from the grave? Or is this OK?

I think this is not perfect but OK for now. The document is still
available here:

http://tools.ietf.org/html/draft-lange-netmod-iana-timezones-01

/js 

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>

---

From: Per Hedeland <[email-masked]>
Date: Wed, 06 Mar 2013 15:02:30 +0100

Hi,

I have reviewed this draft, and have comments only on the crypt-hash
typedef and its use for the password leaf in the user list. The only
issue that I think really *needs* to be resolved is that the Wikipedia
link is wrong, referencing crypt(1) rather than crypt(3) - i.e.

OLD:
          Wikipedia: http://en.wikipedia.org/wiki/Crypt_(Unix)

NEW:
          Wikipedia: http://en.wikipedia.org/wiki/Crypt_(C)

Other than that I have some questions that may or may not need to be
addressed:

1. Is it a problem that there is no "real" specification of the
algorithms used for the hashing? I.e. not MD5/SHA, but how they are
applied. As far as I can see, the IEEE 1003.1-2008 reference that
"looks" like it may be to a spec says basically just

   The algorithm is implementation-defined.

and

   The values returned by this function need not be portable among
   XSI-conformant systems.

Of course there are "reference implementations" of the algorithms in at
least FreeBSD libc and glibc. Should (could) these be referenced
somehow?

2. If "implementation-defined" is the answer to 1, is there any point in
specifying the formats at all? Obviously a NETCONF client can not in
general configure a pre-hashed password in this case.

3. The "reference implementations" of type 5 and 6 allow for an
additional 'rounds' parameter with a value in the range
1000 .. 999999999 (default is 5000), i.e. the "hashed value" can be e.g.
"$5$rounds=10000$saltstringsaltst$3xv.VbSHBb41AL9AvLeujZkZRBAwqFMz2.".
This is not allowed by the pattern in the typedef - should it be?

4. Should there be some text about how a server chooses between the
algorithms when hashing a cleartext password (assuming it supports more
than one, of course)?

--Per Hedeland

---

From: Phil Shafer <[email-masked]>
Date: Wed, 6 Mar 2013 15:08:17 -0500

Here are some additional comments on the draft:
    
2.1: having location as an opaque field renders it useless for
automation.  In JUNOS, our [system location] contains:

        attribute country-code {
            help "Two-letter country code";
            type string; 
        }
        attribute postal-code {
            help "Zip code or postal code";
            type string;
        }
        attribute npa-nxx {
            help "First six digits of phone number (area code plus exchange)";
            type string;
        }
        attribute latitude {
            help "Latitude in degree format";
            type string;
        }
        attribute longitude {
            help "Longitude in degree format";
            type string;
        }
        attribute altitude {
            help "Feet above (or below) sea level";
            type int; 
        }
        attribute lata {
            help "Long-distance service area";
            type string;
        }
        attribute vcoord {
            help "Bellcore vertical coordinate";
            type string;
        }
        attribute hcoord {
            help "Bellcore horizontal coordinate";
            type string;
        }
        attribute building {
            help "Building name";
            type string;
        }

        attribute floor {
            help "Floor of the building";
            type int;
        }

        attribute rack {
            help "Rack number";
            type uint;
        }

These were the requirements from our customers >10 years ago and seem
to be enough for everyone.  (Okay, altitude was my addition.....)

Fix: add additional fields.

2.3 says publickey and password are both required, but this need
not be true.  I've been turning off ssh passwords on my public boxes
to keep the script kiddies at bay.

RADIUS is also mentioned as a "need", but there are many others
(tacplus, skey, etc).

Fix: don't call out specific technology requirements.

3.1: Is "name" the DNS name of the device?  Can we say that, either
here or in the description?  "administratively assigned system name"
doesn't mean much to the average reader.

3.2: Why have use-ntp?  Why not have [system ntp] a purpose container?

You list ntp-server (nuke the leading "ntp-"), but not peers or boot
servers.  You are missing authentication keys, source address,
version, polling interval constraints (min and max), broadcast server
and client info, and multicast client info.

re: enabled: would be good to make a generic means for this, so we
don't need to put this knob on every container.

3.3: In JUNOS, we call out the local domain explicitly, distinct from
the domain search path.  This is similar to the "domain" and "search"
fields in BSD's resolv.conf.

3.4: Should RADIUS config be in a distinct module, augmenting this
one?  Using a feature work, but skey, tacplus, etc need config also.
Are we saying that RADIUS is the only modern/needed one?

3.5: The user-authentication-order must says:

            must '(. = "sys:radius" and ../../radius/server) or'
               + '(. != "sys:radius")' {

which is '. != "sys:radius" || ../../radius/server', right?

Passwords without the leading $ are old-school style.  Support them?

In the same vein, JUNOS uses $9$ for obfuscating secret data to avoid
allowing over-the-shoulder password stealing.  It's only obfuscation,
but is still useful for secrets that we need in plain text later and
cannot use just the hash.  Similar with systems that use a single
"master password" to encrypt secret data.

What is an ssh key's name?  Just a user-defined handle?  Why not use
the complete ssh key as the key?

Why is ssh key data binary?

Users require both authentication and authorization.  In JUNOS,
we put this under a container under "system" named "login" with two
lists, "users" and "classes".  The login class can be used to
constrict (or expand) the user's permissions, as well as setting time
of day restrictions, source address restrictions, and cosmetic bits
like displaying alarms or help text at login time on the CLI.

3.6: Consider making <reboot> a leaf under a single <shutdown>
operation, ala the BSD shutdown command.

Why are the shutdown operations "deny-all"?

Thanks,
 Phil

---

From: Andy Bierman <[email-masked]>
Date: Wed, 6 Mar 2013 12:50:18 -0800

> Fix: add additional fields.

The system leaf is intended to be the same value as sysLocation from SNMP.

Not sure about all these new feature requests that could have come up
any time in the 15 months since draft-00 came out.  The WG will have
to go through
them 1 by 1 I guess.

Andy

---

From: Martin Bjorklund <[email-masked]>
Date: Wed, 06 Mar 2013 23:17:34 +0100 (CET)

Hi Phil,

First of all, thank you very much for your review!

> Fix: add additional fields.

This (or parts of it) was discussed in the thread starting with
http://www.ietf.org/mail-archive/web/netmod/current/msg07065.html.

I guess no real conclusion was made in this thread.

> not be true.

Note that section 2 is Objectives - this text just says that the data
model must support both publickey and password.

> I've been turning off ssh passwords on my public boxes

Again, this is the design objective.  I agree there are other
mechanism, see more below.

> here or in the description?

No, it doesn't have to be the "DNS name of the device" (whatever that
is...).

> "administratively assigned system name"

This text is copied from RFC 3418 (sysName) (which is also
referenced).

> 3.2: Why have use-ntp?  Why not have [system ntp] a purpose container?

As long as we don't have active/inactive (see Kent's draft), we'll see
these kinds of leafs.

> You list ntp-server (nuke the leading "ntp-")

Agreed, will fix.

> but not peers or boot

We had more earlier, but have been going back and forth.  See for
example
http://www.ietf.org/mail-archive/web/netmod/current/msg06529.html for
some comments.

> fields in BSD's resolv.conf.

In an earlier version of this model we had:

           The 'domain' keyword of /etc/resolv.conf is not supported,
           since it is equivalent to 'search' with a single domain.

> Are we saying that RADIUS is the only modern/needed one?

RADIUS is the only ietf standards track of the ones you mention.

We could put this in a separate module, in order to get a cleaner
separation, but then you could argue that we should do that with
everything else (ntp, dns, ...) as well, and then this module won't
contain much.

The current approach is pragmatic; we put in some generally useful
parameters, and then the model can be augmented with additional
stuff.

> which is '. != "sys:radius" || ../../radius/server', right?

Yes, will fix!

> Passwords without the leading $ are old-school style.  Support them?

Actually, they are not supported.  The pattern is:

      pattern "$0$.*|$(1|5|6)$[a-zA-Z0-9./]{2,16}$.*";

> "master password" to encrypt secret data.

Yes, we have something similar (for encrypted data).  But note that
this type is called crypt-hash, and it should be used for this
purpose.  If you need obfuscated or encrypted data, use another type.

> What is an ssh key's name?  Just a user-defined handle?

Yes.

> Why not use

It is a bit bulky.

> Why is ssh key data binary?

B/c it can contain any octets.  Note that the textual representation
is base64 encoded, which happens to be a common way to represent ssh
keys.

> like displaying alarms or help text at login time on the CLI.

Authorization is handled by RFC 6536 (nacm).

> Why are the shutdown operations "deny-all"?

It is nacm:default-deny-all.  It means that you need an authorization
rule in order to reboot/shutdown the device.

/martin

---

From: Benoit Claise <[email-masked]>
Date: Thu, 07 Mar 2013 10:34:45 +0100

> http://tools.ietf.org/html/draft-lange-netmod-iana-timezones-01
Actually, the reference should be the netmod document.
     http://tools.ietf.org/html/draft-ietf-netmod-iana-timezones-00.
Now, the expiration issue is the same, as it expired on January 10, 2013

Regards, Benoit

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 07 Mar 2013 10:42:45 +0100 (CET)

> Now, the expiration issue is the same, as it expired on January 10,

It seems we will publish a new version of the systems draft after
WGLC; at this time we can also publish a new version of
draft-ietf-netmod-iana-timezones and update the reference.

/martin

---

From: Per Hedeland <[email-masked]>
Date: Thu, 07 Mar 2013 17:58:01 +0100

> Phil Shafer <[email-masked]> wrote:
[snip]
> http://www.ietf.org/mail-archive/web/netmod/current/msg06529.html for

Yes - and if we are attempting to specify a standard for configuration
of the "NTP reference implementation" (which I don't think we should),
there are of course a huge number of other knobs that could be
considered "missing", I don't know why the particular list above would
be selected. The reference implementation's "peer" directive is covered
by the association-type here though (the ref.impl combines the "address"
and "association-type" items into a single directive). I'm guessing that
"boot server" (not a concept used by the ref.impl AFAIK) is something
that is supposed to be used by the (deprecated) 'ntpdate' program or the
like, I can't see any reason to have separate config for that.

>            since it is equivalent to 'search' with a single domain.

And in BSD's (also in others I believe) resolv.conf, "domain" and
"search" are mutually exclusive - AFAIK "domain" is retained only for
backward compatibility, it used to imply a search list until that was
found to be a security problem, and "search" was introduced to make it
possible to specify the search list explicitly.

>       pattern "$0$.*|$(1|5|6)$[a-zA-Z0-9./]{2,16}$.*";

I guess the question is whether we should support the original *nix
DES-based password type, to which my answer is a definite "no". It was
considered insufficiently resistant to brute-force attacks already back
in 1995 when the MD5 type was created (and nowadays the creator of the
MD5 type advices against *its* use for the same reason).

--Per

---

From: Phil Shafer <[email-masked]>
Date: Thu, 7 Mar 2013 15:09:25 -0500

>This text is copied from RFC 3418 (sysName) (which is also

Sure, but we don't need to quote the dead sea scrolls ;^)
We need a description that is useful to the modern reader,
not something with Old Testament language.

>As long as we don't have active/inactive (see Kent's draft), we'll see

How about the semi-standard "enable" at least?

>http://www.ietf.org/mail-archive/web/netmod/current/msg06529.html for

If you only model the pasts of NTP that you think are useful,
then someone has to make another model containing the rest of
the ntp model, which seems poor style.

>           since it is equivalent to 'search' with a single domain.

I'd add those words back, since they at least let the reader know
it was intentional.

>is base64 encoded, which happens to be a common way to represent ssh

So the key-data is only the encoded bits?  What do you do with the
comment?

Thanks,
 Phil

---

From: Andy Bierman <[email-masked]>
Date: Thu, 7 Mar 2013 12:23:33 -0800

Hi,

> How about the semi-standard "enable" at least?

What is the semi-standard "enable"?
You mean a leaf?  I prefer a grouping with an enabled leaf
that each module uses (instead of cut-and-paste).
I prefer leafs over XML attributes because YANG must/when
expressions cannot see these flags unless they are leafs
in the config.

> the ntp model, which seems poor style.

We went back and forth on this and many other issues
and we intentionally minimized the set of parameters.
Perhaps the NTP WG should create a data model to configure
every possible parameter, but not the NETMOD WG.

Andy

---

From: Phil Shafer <[email-masked]>
Date: Thu, 7 Mar 2013 15:24:26 -0500

>like, I can't see any reason to have separate config for that.

My config is based on ntp.org's ntp.conf:

     server address [key key | autokey] [burst] [iburst] [version version]
             [prefer] [minpoll minpoll] [maxpoll maxpoll]

     peer address [key key | autokey] [version version] [prefer] [minpoll
             minpoll] [maxpoll maxpoll]

     broadcast address [key key | autokey] [version version] [prefer] [minpoll
             minpoll] [ttl ttl]

     manycastclient address [key key | autokey] [version version] [prefer]
             [minpoll minpoll] [maxpoll maxpoll] [ttl ttl]

but yes, there are lots of the more rare options (statistics,
discard, etc) that we omit.

>possible to specify the search list explicitly.

You're right.  We no longer use it if search is set.

Thanks,
 Phil

---

From: Phil Shafer <[email-masked]>
Date: Thu, 7 Mar 2013 15:47:22 -0500

>What is the semi-standard "enable"?

I thought other drafts use "enable" instead of "use-xxx", but
checking shows both "enable" and "enabled".  It defaults to true,
which means it will only be set to "false" (explicitly anyway) so
it's really more of a "disable" knob.  ('leaf disable { type empty; }'?)

>that each module uses (instead of cut-and-paste).

That would be fine, and that "grouping enable" could be in a standard
module to everyone could include it, if that's what you're after.
As it is, the names vary, the placement varies (e.g. radius cannot
be disabled, nor can specific ntp servers), and it makes must/when
expressions fragile and/or complex.

It would be nice to have a single, simple means of enabling and
disabling config hierarchies.

>every possible parameter, but not the NETMOD WG.

Perhaps this should be captured in the document so the reader
understands that you are not fully modeling these technologies,
but only aiming for the more commonly used features.

Thanks,
 Phil

---

From: David Kessens <[email-masked]>
Date: Thu, 7 Mar 2013 13:28:51 -0800

Phil,

> the ntp model, which seems poor style.

The intention of the system model was to cover 90% of cases. More specific
data models can be worked on later. It's a judgement call what is 90% and what
is the other 10%, but it surely is not needed to support every
option/feature under the sun.

David Kessens
---

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 07 Mar 2013 22:31:51 +0100 (CET)

David Kessens <[email-masked]> wrote:
> The intention of the system model was to cover 90% of cases.

Right; and to further clarify - 90% of the *use cases*, not 90% of the
potential parameters.

/martin

---

From: Martin Bjorklund <[email-masked]>
Date: Fri, 08 Mar 2013 11:12:24 +0100 (CET)

> it's really more of a "disable" knob.  ('leaf disable { type empty; }'?)

I am all for consistency.

I cannot find other drafts using "enable", and personally I think it
is a bit weird to have a verb in the config.  So I prefer to have "leaf
enabled".

> module to everyone could include it, if that's what you're after.

+1

But where do we put it...?  In 6021bis? (ietf-yang-types).

/martin

---

From: Per Hedeland <[email-masked]>
Date: Fri, 08 Mar 2013 11:54:02 +0100

> My config is based on ntp.org's ntp.conf:

Well, ntp.org provides documentation for the "reference implementation"
- the point I tried to make in the earlier discussion is that there are
viable alternative implementations. Some of them may even be considered
preferrable in some deployments, but they surely do not come with as
many knobs, maybe not even a subset that is identical. I.e. I believe a
standard model should be implementation-independant as far as possible,
and I think the current model mostly fulfills that.

--Per

---

From: Ladislav Lhotka <[email-masked]>
Date: Fri, 08 Mar 2013 16:29:29 +0100

> expressions cannot see these flags unless they are leafs

I agree. Whilst such a meta-flag would be nice, the "collateral damage" would IMO be just too high.

Lada

-- 
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C

---

From: Ladislav Lhotka <[email-masked]>
Date: Fri, 08 Mar 2013 16:48:54 +0100

> it's really more of a "disable" knob.  ('leaf disable { type empty; }'?)

We had this discussion before, see this thread:

http://www.ietf.org/mail-archive/web/netmod/current/msg06032.html

I was, and still am, slightly in favour of <disabled/>. If we end up changing all the "enabled" flags into "uses", we should reconsider the pros and cons of

leaf enabled {
    type boolean;
    default true;
}

versus

leaf disabled {
    type empty;
}

because this leaf will be pretty ubiquitous.

Lada

---

From: Per Hedeland <[email-masked]>
Date: Fri, 08 Mar 2013 16:49:34 +0100

Some potentially reasonable answers to my own questions below...

On 2013-03-06 15:02, Per Hedeland wrote:
> applied.

I don't think so, but perhaps the text could make it clear that there is
more to the implementation than the choice of MD5/SHA-256/SHA-512:

OLD:
         "The crypt-hash type is used to store passwords using
          a hash function.  This type is implemented in various UNIX
          systems as the function crypt(3).

NEW:
         "The crypt-hash type is used to store passwords using
          a hash function.  The algorithms for applying the hash
          function and encoding the result are implemented in
          various UNIX systems as the function crypt(3).

> 2. If "implementation-defined" is the answer to 1, ...

It isn't.

> This is not allowed by the pattern in the typedef - should it be?

I think it should be allowed - the freely available implementations of
the hashing algorithms that are likely to be used in deployment already
support this parameter, and even if it is not currently used for initial
creation of hashed passwords on the relevant Unices, it is a simple way
to increase the computational cost of hashing when needed.

I thus suggest that the pattern be modified as follows, which also
includes a more precise (and perhaps more readable) specification:

OLD:

NEW:
         pattern "$0$.*|" +
                 "$1$[a-zA-Z0-9./]{1,8}$[a-zA-Z0-9./]{22}|" +
                 "$5$(rounds=\d+$)?[a-zA-Z0-9./]{1,16}$[a-zA-Z0-9./]{43}|" +
                 "$6$(rounds=\d+$)?[a-zA-Z0-9./]{1,16}$[a-zA-Z0-9./]{86}";

and

OLD:
         A value of this type matches one of the forms:

            $0$<clear text password>
            $<id>$<salt>$<password hash>

         The '$0$' prefix signals that the value is clear text.  When
         such a value is received by the server, a hash value is
         calculated, and the string '$<id>$<salt>$' is prepended to the
         result, where <salt> is a random 2-16 characters long salt
         used to generate the digest.  This value is stored in the
         configuration data store.

         If a value starting with '$<id>$<salt>$' is received

NEW:
         A value of this type matches one of the forms:

            $0$<clear text password>
            $<id>$<salt>$<password hash>
            $<id>$<parameter>$<salt>$<password hash>

         The '$0$' prefix signals that the value is clear text.  When
         such a value is received by the server, a hash value is
         calculated, and the string '$<id>$<salt>$' or
         $<id>$<parameter>$<salt>$ is prepended to the result.  This
         value is stored in the configuration data store.

         If a value starting with '$<id>$', where <id> is not '0',
         is received

(I.e. I'm dropping the elaboration on <salt>, and not adding anything
for <parameter> - that info has no use anyway if you don't know the
exact algorithm.)

> algorithms when hashing a cleartext password (assuming it supports more

Leaving it out is probably a good enough way of saying "implementation
dependant".

--Per

---

From: Andy Bierman <[email-masked]>
Date: Fri, 8 Mar 2013 07:54:09 -0800

> I agree. Whilst such a meta-flag would be nice, the "collateral damage" would IMO be just too high.

IMO, this is a high priority use-case for must/when.
Machine-readable dependency mappings help automation tools.

Unfortunately, the operator "enabled" property isn't the only use-case.
We get a lot of requests to make false conditional subtrees "come back"
once the condition is true again (when, choice-stmt).  A standard to
do that would really help.

I2RS seems to want subtrees saved for each client application, and
some sort of priority/scheduling algorithm decides which one is active.
The YANG when and choice statements cause the false conditional
nodes to be deleted and forgotten.

The key feature of Kent's draft that we seem to be over-looking is that he
attempts to solve this important CM problem.  We may differ on the details but
whatever we call this feature (operational state?) it is a
high-priority problem.

Andy

---

From: Per Hedeland <[email-masked]>
Date: Fri, 08 Mar 2013 17:51:50 +0100

Prompted by Phil to scrutinize the NTP section in more detail, I'll also
propose the text change below - the existing text is not quite correct,
and I suspect that users may wonder about the point of configuring a
server that the device is not expected to "synchronize with".:-)

OLD:
               enum server {
                 description
                   "Use server association mode.  This device
                   is not expected to synchronize with the
                   configured NTP server.";
               }
               enum peer {
                 description
                   "Use peer association mode.  This device
                    may be expected to synchronize with the
                    configured NTP server.";
               }
               enum pool {
                 description
                   "Use pool association mode.  This device
                    is not expected to synchronize with the
                    configured NTP server.";
               }

NEW:
               enum server {
                 description
                   "Use client association mode.  This device
                    will not provide synchronization to the
                    configured NTP server.";
               }
               enum peer {
                 description
                   "Use symmetric active association mode.
                    This device may provide synchronization
                    to the configured NTP server.";
               }
               enum pool {
                 description
                   "Use client association mode with one or
                    more of the NTP servers found by DNS
                    resolution of the domain name given by
                    the 'address' leaf.  This device will not
                    provide synchronization to the servers.";
               }

--Per

---

From: Andy Bierman <[email-masked]>
Date: Fri, 8 Mar 2013 10:55:16 -0800

Hi,

Thanks for the review and the clarifications.
I don't have any objections to these changes.

In order to save time in Orlando, it would be good to know
what edit requests are considered contentious and which are not.

It would help if people looked over your earlier email and the 1 from Phil,
and send comments to the mailing list.

Andy

---

From: Kent Watsen <[email-masked]>
Date: Sat, 9 Mar 2013 12:06:09 +0000

>expressions cannot see these flags unless they are leafs

Though likely moot, why wouldn't this work?

    when "/system/foobar[@enabled = 'true']"     when "not
/system/foobar[@disabled]"

At least XPath supports selection based on attribute values...

Regardless, the reason why it's likely moot is because I think it'd be
crazy to use must/when expressions to support conditional enablement, but
my perspective assumes what can be disabled is selected by NETCONF-client
(not the data-modeler).

My view (and that implemented by JUNOS) is that conditional enablement is
a cross-cutting feature - it is as if the attribute is implicitly defined
on *every* node in the tree.  It is presumed that config-validation
conceptually occurs after stripping out all the disabled nodes, for
instance via a XLST script.  If we didn't assume these nodes were
conceptually removed from the config before evaluation, then the must/when
expressions would need to be literally everywhere, which doesn't fly.

The other view would restrict what can be disabled to selections chosen by
the original data-modeler - this WG for instance.   However, all examples
to date of how we have used flags to disable nodes have been at the
"feature" level (e.g. use-ntp), but have we considered that maybe the
customer doesn't want to disable the NTP service as a whole, but instead
they want to disable just a specific ntp-server?

To compound things more, my draft attempts to not restrict disabling a
node to a static constant (true/false), but to allow disablement based on
an expression (e.g. temporal).  While it remains to be seen how this is
resolved, it's clear that anything more complex than a static/constant
value would be out of reach for must/when expressions.

Thanks,
Kent

---

From: Kent Watsen <[email-masked]>
Date: Sat, 9 Mar 2013 12:24:02 +0000

Under System Identification, should there be some way to identify the
system's role or operating mode?

Roles might include if the "system" is a logical-system, stack-member,
cluster-member, blade-server, or a blade-server-member.

Operating mode might include if it's configured to run in FIPS-mode or if
it's running a variation of code to meet cryptographic export restrictions.

We found a need to have these attributes returned in our proprietary
<get-system-information> RPC.  Admittedly, some of this could've been
learned through the advertisement of a capability, but our "when"
expressions needed something to act on.  For instance, certain config
nodes are disabled/enabled based on the device's role and/or
operating-mode.

Thanks,
Kent

---

From: Martin Bjorklund <[email-masked]>
Date: Sat, 09 Mar 2013 13:35:16 +0100 (CET)

Kent Watsen <[email-masked]> wrote:
> instance via a XLST script.

Yes, this is the way it must work (and in our implementation of this
it also works this way).  It should be explicitly described in your
draft.

> an expression (e.g. temporal).

I think this is extremely difficult, or maybe impossible, to get to
work right.  It means that at a certain time the system is supposed to
apply some config subtree, but what if the resulting config is invalid
at that time?

/martin

---

From: Andy Bierman <[email-masked]>
Date: Sat, 9 Mar 2013 06:26:26 -0800

Hi,

I really do not want to start reinventing the Entity MIB as
an afterthought -- something to throw into the system module
at the last minute.  We came up with the tree approach after the Chassis MIB
was a total failure because each vendor insisted their model of the system
was the correct one.  A simple "system role" will not be sufficient,
even if you could get agreement on the list of system roles.

Andy

---

From: Andy Bierman <[email-masked]>
Date: Sat, 9 Mar 2013 06:41:36 -0800

Hi,

> At least XPath supports selection based on attribute values...

But YANG does not support XML attributes.
Moving them from persistent elements to persistent attributes doesn't
seem to help solve anything.

> my perspective assumes what can be disabled is selected by NETCONF-client

It is a very common use-case that some sub-tree will only be applicable
if some other feature is enabled.  All the YANG statements are created
by the client.  Changing the enabled knob is no different than changing
the MTU value IMO.

I strongly object to inventing a new expression language for XML
instead of using the XPath standard.

> expressions would need to be literally everywhere, which doesn't fly.

Whether this is done via rules like NACM or whether the rules are cut-and-pasted
into every leaf and parsed that way doesn't change the conceptual design.

> value would be out of reach for must/when expressions.

I think this needs a lot more work to be feasible.
If there is a meta-config on top of the real config, when is is validated,
how is it maintained, and how is it applied to the real config exactly
the same way on all implementations? How to multiple clients resolve
policy (meta-config) editing conflicts?  Is there locking and priority
ownership in the meta-config?  How is that managed?  Without a schema,
how do client developers know how to construct policies the server will accept?
How do validation constraints interact between the meta-config and the
real config?

That's why I prefer to have just use leafs and stick with 1 config.

Andy

---

From: Andy Bierman <[email-masked]>
Date: Sat, 9 Mar 2013 09:23:43 -0800

> But where do we put it...?  In 6021bis? (ietf-yang-types).

Yes to 6021bis, but I prefer a new module called ietf-yang-groupings.

Andy

---

From: Andy Bierman <[email-masked]>
Date: Sat, 9 Mar 2013 09:27:26 -0800

> automation.  In JUNOS, our [system location] contains:

Step 1) I agree with your problem statement.
Schema-defined data is obviously better for automation than ad-hoc strings.

Step 2) I have no objection to adding additional objects if there is
           WG consensus and proper references for all the leafs accepted.

Andy

---

From: Kent Watsen <[email-masked]>
Date: Sat, 9 Mar 2013 20:05:07 +0000

>           WG consensus and proper references for all the leafs accepted.

Is it fair to say the same view applies to my suggestion for system "role"
and "mode" fields?   ;)

Thanks,
Kent

---

From: Kent Watsen <[email-masked]>
Date: Sat, 9 Mar 2013 20:13:49 +0000

>even if you could get agreement on the list of system roles.

I'm put off by the "last minute" reference - does it really matter when
the ideas come in? - some times these things don't come to people right
away and, just because it's "last call" doesn't make them any less
relevant.

Also, I don't see why Entity MIB should be thought of as constraint.
Clearly NETCONF is an attempt to break away from the failed SNMP solution,
so why not think to do better?

FWIW, we defined the "roles" at the top-level, since they were both
universal and dictated the need for the NMS to gather more information,
but left the "modes" as a vendor-extensible field, since the values "fips"
and "export" were clearly arbitraryŠ

Thanks,
Kent

---

From: Andy Bierman <[email-masked]>
Date: Sat, 9 Mar 2013 12:30:45 -0800

Hi,

So you are asking for an ad-hoc admin string and the operator puts
whatever they want there?   Certainly not an ENTITY-MIB replacement.

I don't think any of the new leafs proposed
are that important -- I don't want to restart the clock and
spend 4 or 8 more months agreeing on each leaf
and what exactly they mean.  If none get added that is fine.

But if the WG agrees during WGLC on some leafs, and there is an
external reference
defining each leaf (so we cannot debate that) then that's fine too.

Andy

---

From: Ladislav Lhotka <[email-masked]>
Date: Sun, 10 Mar 2013 07:15:36 -0400

> /system/foobar[@disabled]"

"when" is already broken, and it would get worse with this:

container system {
    list foobar {
        ...
        leaf baz {
            when "ancestor::foobar[@enabled = 'true']";
            ...
        }
    }

Setting @enabled to "false" on a *single* "foobar" entry would invalidate "baz" not only for that entry but for all entries! It is because "when" operates not on the instance document but on the schema.

Lada

---

From: Ladislav Lhotka <[email-masked]>
Date: Sun, 10 Mar 2013 07:24:45 -0400

> apply some config subtree, but what if the resulting config is invalid

As I already wrote, this could IMO be implemented via a server-side cron-like capability, so that a particular *edit* rather than an entire configuration would be applied at specific time(s), with all due checks.

Without further ado I can use cron on the client for the same purpose now, so it would only move the responsibility to the server - with the additional benefit that all clients could also see what has been scheduled by other clients.

Lada

---

From: Phil Shafer <[email-masked]>
Date: Mon, 11 Mar 2013 08:19:55 -0400

David Kessens writes:
>data models can be worked on later.

If this is the intention, the document should spell it out.
It's definitely not obvious.  Even 90% is probably too high
a number, given the massive diversity of networks.

>It's a judgement call what is 90% and what

Too often this turns out to mean anything I use is in the 90%;
anything I don't is in the 10%.   ;^)

Thanks,
 Phil

---

From: Phil Shafer <[email-masked]>
Date: Mon, 11 Mar 2013 08:22:28 -0400

>I agree. Whilst such a meta-flag would be nice, the "collateral damage" would IMO be jus

Please explain what you mean by "collateral damage" in
this arena.  I'm not following.

Thanks,
 Phil

---

From: Phil Shafer <[email-masked]>
Date: Mon, 11 Mar 2013 08:27:00 -0400

>/system/foobar[@disabled]"

The idea should be that since enable/disable is a well-known
item, then must/when expressions should not need to sweat
explicit references to the attribute.  If it's disabled,
then it's considered to be deleted for purposes of validation.

Thanks,
 Phil

---

From: Phil Shafer <[email-masked]>
Date: Mon, 11 Mar 2013 08:29:32 -0400

>But YANG does not support XML attributes.

YANG models metadata in attributes.  enable/disable can
be considered metadata.

>seem to help solve anything.

No, but making this concept a first-class feature of YANG does help
to solve this, since it allows must/when expressions to ignore it.

Thanks,
 Phil

---

From: Ladislav Lhotka <[email-masked]>
Date: Mon, 11 Mar 2013 09:49:25 -0400

> this arena.  I'm not following.

I meant that it would affect existing concepts in YANG, of course depending on the precise semantics of that attribute. must/when was already mentioned, and another question I have is about data model defaults: if a subtree is tagged as disabled, should the server still assume that all default values in that subtree are operationally active?

Lada

---

From: Kent Watsen <[email-masked]>
Date: Mon, 11 Mar 2013 16:35:52 +0000

On 3/11/13 9:49 AM, "Ladislav Lhotka" <[email-masked]> wrote:

>another question I have is about data model defaults: if a subtree is
>tagged as disabled, should the server still assume that all default
>values in that subtree are operationally active?

No, a disabled subtree (e.g. disabled="true" on a parent node) is
conceptually not in the config anymore.   For instance, is XSLT script
could be written filter these nodes out prior to validation.

Is it any different to how we're using explicit "enabled" leaves today?

K.

---

From: Ladislav Lhotka <[email-masked]>
Date: Mon, 11 Mar 2013 13:30:43 -0400

> could be written filter these nodes out prior to validation.

Well, by normal YANG rules, the defaults still apply even if the subtree of a non-presence container in not in config. So this would require additional specification for defaults.

> Is it any different to how we're using explicit "enabled" leaves today?

These leaves have no a priori semantics, they do not make anything *in the configuration* disappear or deactivate.

Lada

---

From: Phil Shafer <[email-masked]>
Date: Mon, 11 Mar 2013 14:20:48 -0400

Ladislav Lhotka writes:
>I meant that it would affect existing concepts in YANG, of course depending on the preci
>se semantics of that attribute. must/when was already mentioned, and another question I 
>have is about data model defaults: if a subtree is tagged as disabled, should the server
> still assume that all default values in that subtree are operationally active?

The inactive configuration subtrees are conceptually not in the
configuration, every validation and implementation (of a config)
decision should ignore them.  This means that must/when as well as
defaults should operate as if the inactive configuration were
deleted.

Thanks,
 Phil

---

From: Ladislav Lhotka <[email-masked]>
Date: Mon, 11 Mar 2013 14:36:20 -0400

> defaults should operate as if the inactive configuration were

Martin told me about their implementation, so it is like commenting out part of the configuration. This should be OK, provided that all validation etc. is done on the resulting config where the tagged parts are removed.

Lada

---

From: Xiang Li <[email-masked]>
Date: Mon, 11 Mar 2013 13:46:14 -0500

>Regardless, the reason why it's likely moot is because I think it'd be 
crazy to use must/when expressions to support conditional enablement, 
but my perspective >assumes what can be disabled is selected by 
NETCONF-client (not the data-modeler)

That makes sense to me...

For example, when I edit a Linux config file, I often comment or 
uncomment certain lines to  quickly change the config. In these case, I  
may not want to
delete the respective lines from the config file since   I may use it in 
the future.

It's my understanding this draft may eventually provide a solution for that.

--Xiang

---

From: Kent Watsen <[email-masked]>
Date: Tue, 12 Mar 2013 12:49:44 +0000

>It's my understanding this draft may eventually provide a solution for

That is correct.

Based on yesterday's meeting and comments, we'll likely split the solution
- one for commenting-out parts of the config tree and the other for
temporal/triggered configŠ

Thanks,
Kent

---

From: Ladislav Lhotka <[email-masked]>
Date: Tue, 19 Mar 2013 14:56:44 +0100

Hi,

I have several comments to the draft:

1. /system/dns/search has the type inet:host - I think this is not correct, it should be inet:domain-name instead.

2. The document should also refer to 6021bis rather than 6021, but maybe this is already planned.

3. The description of /system/platform/nodename says it is "The host name of this system." Wouldn't it be better then to call this leaf "hostname" or "host-name"? Also, is it necessary to have two leaves with names, i.e. this one and also "name"?

In general, I think the document is in a good shape and ready for publication, after resolving the pending issues. 

Lada

---

From: "Alexander Clemm (alex)" <[email-masked]>
Date: Tue, 19 Mar 2013 23:19:23 +0000

Hi,

Here are my comments - very minor in nature.  IMHO the document is in good shape and should move forward to publication.  

Section 1: "This document defines a YANG data model  for the configuration and identification  of the management system of a device."  Is this statement really accurate?  I wonder if this can be slightly rephrased.  It is not _the_ management system that is configured, but a bunch of system management related aspects.  Perhaps rephrase as something like "... for the configuration and identification of general system-management related aspects of a device, such as system time-of-day configuration and monitoring, basic system identification, and user authentication configuration.".  

Section 2.1 "These objects are defined as operational data and intended to be specific to the device vendor".  Consider rephrasing - the objects are not specific to vendors or else they wouldn't be specified here but augmented instead; what is meant are that the values/how the objects are populated is vendor specific.  Consider stating e.g. "... and intended to be populated by the device vendor with values that may be specific to the device vendor."    

Next sentence "... provided such as ..." --> "... provided, such as ..."

General comment on the data model, not sure where to put (e.g. Section 2.2 or 3): Should it be mentioned somewhere that some of the configurable information might also be auto-populated in certain implementations?  For example, an NTP server could also be discovered and the information be automatically populated by the system rather than the user.  

Regards
--- Alex

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of David Kessens
Sent: Tuesday, March 05, 2013 4:06 PM
To: [email-masked]
Subject: [netmod] Last Call draft-ietf-netmod-system-mgmt-05 (20130320)

Hi,

Please indicate your support by Wed March 20, 2013. Or alternatively, let us know in the same timeframe whether there are still issues that need to be resolved.

Thanks!

David Kessens
co-chair netmod wg
---

---

From: "Lisa Huang (yihuan)" <[email-masked]>
Date: Wed, 20 Mar 2013 01:03:01 +0000

Hi,

Here is my comment for typedef crypt-hash. The draft has the following
definition:

typedef crypt-hash {
  type string {
  Description 
  "
  Š.

  $0$<clear text password>

}

"$" is usually used as anchor (or positioning) in regular expression. The
$ (dollar) means look only at the end of the target string, for example,
fox$ will find a match in 'silver fox' since it appears at the end of the
string but not in 'the fox jumped over the moon'.

In the I-D, the pattern is trying to match "$0$<clear text password>" or
"$<id>$<salt>$<password hash>", where "$" is a character in the string. I
run some on line regular expression tool, none of them can validate the
pattern but found adding escape characters before '$' solves the match.

Thanks,

Lisa

>Please indicate your support by Wed March 20, 2013. Or alternatively, let
>us know in the same timeframe whether there are still issues that need to
>be resolved.
>
>Thanks!
>
>David Kessens
>co-chair netmod wg
>---

---

From: Xiang Li <[email-masked]>
Date: Tue, 19 Mar 2013 21:13:00 -0500

> pattern but found adding escape characters before '$' solves the match.

I had the same question a while back. I then found out that the "regular 
string" used
by YANG "pattern"  is defined in:

RFC6020  Normative References

[XSD-TYPES]  http://www.w3.org/TR/2004/REC-xmlschema-2-20041028/#regexs

The regular expression language defined in above doc implicitly anchors 
all regular
expressions at the head and tail.

Further it does not define "$" as a special character. It's a bit 
different than
other regular strings such as Perl in this case.

**

--Xiang

-- 
--
Xiang Li
Web: www.seguesoft.com
Voice:   1 (217) 472-4108 Cell 1 (217) 819-0942

---

From: "Lisa Huang (yihuan)" <[email-masked]>
Date: Wed, 20 Mar 2013 02:51:24 +0000

Thanks for the clarification.

From: Xiang Li <[email-masked]<mailto:[email-masked]>>
Date: Tuesday, March 19, 2013 7:13 PM
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [netmod] Last Call draft-ietf-netmod-system-mgmt-05 (20130320)

Hi,

typedef crypt-hash {
  type string {

  $0$<clear text password>

}

I had the same question a while back. I then found out that the "regular string" used
by YANG "pattern"  is defined in:

The regular expression language defined in above doc implicitly anchors all regular
expressions at the head and tail.

Further it does not define "$" as a special character. It's a bit different than
other regular strings such as Perl in this case.

--Xiang

Thanks,

Lisa

-----Original Message-----
From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf
Of David Kessens
Sent: Tuesday, March 05, 2013 4:06 PM
To: [email-masked]<mailto:[email-masked]>
Subject: [netmod] Last Call draft-ietf-netmod-system-mgmt-05 (20130320)

Hi,

Thanks!

David Kessens
co-chair netmod wg
---
_______________________________________________
netmod mailing list
[email-masked]<mailto:[email-masked]>https://www.ietf.org/mailman/listinfo/netmod
_______________________________________________
netmod mailing list
[email-masked]<mailto:[email-masked]>https://www.ietf.org/mailman/listinfo/netmod

_______________________________________________
netmod mailing list
[email-masked]<mailto:[email-masked]>https://www.ietf.org/mailman/listinfo/netmod

--
--
Xiang Li
Web: www.seguesoft.com<http://www.seguesoft.com>
Voice:   1 (217) 472-4108 Cell 1 (217) 819-0942

---

From: Ladislav Lhotka <[email-masked]>
Date: Wed, 20 Mar 2013 07:01:49 +0100

Hi Lisa,

YANG specifically uses the regular expression syntax defined in "XML Schema: Datatypes", see section 9.4.6 in RFC 6020. In this case, the string value is always matched in its entirety, as if the regular expression was always enclosed in ^…$. Consequently, the special sentinel characters are not needed and so ^ and $ can be used as literals without escaping (except in [^…]).

Lada

---

From: "Lisa Huang (yihuan)" <[email-masked]>
Date: Wed, 20 Mar 2013 17:16:33 +0000

Right. The second half " the special sentinel characters are not needed
and so ^ and $ can be used as literals without escaping (except in [^...])"
is implicit. 

On 3/19/13 11:01 PM, "Ladislav Lhotka" <[email-masked]> wrote:

>Hi Lisa,
>
>YANG specifically uses the regular expression syntax defined in "XML
>Schema: Datatypes", see section 9.4.6 in RFC 6020. In this case, the
>string value is always matched in its entirety, as if the regular
>expression was always enclosed in ^...$. Consequently, the special sentinel
>characters are not needed and so ^ and $ can be used as literals without
>escaping (except in [^...]).
>
>Lada
>  
>>>Behalf