Re: [netmod] js review of draft-bierman-netmod-system-mgmt-00

Martin Bjorklund <mbj@tail-f.com> Fri, 09 September 2011 13:28 UTC

Return-Path: <mbj@tail-f.com>
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D424F21F86A5 for <netmod@ietfa.amsl.com>; Fri, 9 Sep 2011 06:28:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.046
X-Spam-Level:
X-Spam-Status: No, score=-2.046 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rgcr04JK967t for <netmod@ietfa.amsl.com>; Fri, 9 Sep 2011 06:28:21 -0700 (PDT)
Received: from mail.tail-f.com (de-2007.d.ipeer.se [213.180.74.102]) by ietfa.amsl.com (Postfix) with ESMTP id 93CE421F8680 for <netmod@ietf.org>; Fri, 9 Sep 2011 06:28:21 -0700 (PDT)
Received: from localhost (c213-100-166-57.swipnet.se [213.100.166.57]) by mail.tail-f.com (Postfix) with ESMTPSA id 7F36A1200D5F; Fri, 9 Sep 2011 15:25:08 +0200 (CEST)
Date: Fri, 09 Sep 2011 15:30:13 +0200
Message-Id: <20110909.153013.381801558.mbj@tail-f.com>
To: j.schoenwaelder@jacobs-university.de
From: Martin Bjorklund <mbj@tail-f.com>
In-Reply-To: <20110726164341.GA7684@elstar.local>
References: <20110726164341.GA7684@elstar.local>
X-Mailer: Mew version 6.3.50 on Emacs 23.2 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Cc: netmod@ietf.org
Subject: Re: [netmod] js review of draft-bierman-netmod-system-mgmt-00
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: NETMOD WG list <netmod.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netmod>
List-Post: <mailto:netmod@ietf.org>
List-Help: <mailto:netmod-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 09 Sep 2011 13:28:22 -0000

Hi,

Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote:
> I have reviewed draft-bierman-netmod-system-mgmt-00 (as technical
> contributor). I am fine with the scope of document and support its
> adoption as WG document. The comments come in document order.
> 
> 1) Is there some authoritative reference for the crypt-hash format,
>    e.g., a POSIX standard? Is this regulated as part of say POSIX.1 or
>    is all this a GNU invention? Are we sure we can use $0$ as a
>    cleartext password format? Do we have to state that lowercase
>    characters are the canonical representation?

The POSIX definition of the crypt() function is pretty generic, see
http://pubs.opengroup.org/onlinepubs/9699919799/functions/crypt.html.

I don't think a canonical representation is needed for this type.

> 2) The platform leafs are very Unix specific - is this OK? Can we have
>    better references than "uname --kernel"? It looks uname is covered
>    by POSIX.1-2001 but I am not sure.

See
http://pubs.opengroup.org/onlinepubs/9699919799/functions/uname.html.

We should probably add this as reference.

> 3) Rename timezone-info leafs, e.g.
> 
>    OLD
>    
>    choice timezone-info
>      leaf tz-database-id
>      leaf tz-enumeration-is
>      leaf utc-offset
> 
>    NEW
> 
>    choice timezone
>      leaf timezone-location
>      leaf timezone-name
>      leaf timezone-utc-offset

The reason they have these names is that the db seems to go by the
name "tz database".  See also
http://tools.ietf.org/html/draft-lear-iana-timezone-database-04.

But if people prefer 'timezone-database', that's fine as well.

> 4) Can we reasonably expect to control timeouts and retries for
>    different implementations of DNS, NTP, or RADIUS? Or should we
>    leave this to protocol specific modules?

If we can expect to control the timeouts and retries, I think we can
define them here.  If cannot expect to control them, a protocol
specific module won't help.  Or did I misunderstand your concern?

But it should be noted that we basically just put some objects in
there in order to get started.  We need to discuss more exactly what
is needed.

> 5) For RADIUS, you include a port number leaf but not for DNS and
>    NTP. Should we be consistent about this?

Consistency is good...  But can you typically configure the port for
dns and ntp?

> 6) What exactly is stored in the ssh-dsa and ssh-rsa leafs?

Just the binary key as is.  Since there is no other standard format,
this seems simplest.

> 7) Should we submodularize this YANG module this so that we can more
>    easily revise parts of the model as we move along?

I don't mind submodules.


/martin