IETF Logo Mail Archive

Re: [netmod] comments on draft-schoenw-netmod-yang-types-00.txt

Martin Bjorklund <mbj@tail-f.com> Mon, 23 June 2008 08:29 UTC

Return-Path: <netmod-bounces@ietf.org>
X-Original-To: netmod-archive@ietf.org
Delivered-To: ietfarch-netmod-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A9DA33A6816; Mon, 23 Jun 2008 01:29:42 -0700 (PDT)
X-Original-To: netmod@core3.amsl.com
Delivered-To: netmod@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 05EEF3A6917 for <netmod@core3.amsl.com>; Mon, 23 Jun 2008 01:29:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.495
X-Spam-Level:
X-Spam-Status: No, score=-0.495 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m7b6XkETiHao for <netmod@core3.amsl.com>; Mon, 23 Jun 2008 01:29:41 -0700 (PDT)
Received: from mail.tail-f.com (unknown [213.180.94.162]) by core3.amsl.com (Postfix) with ESMTP id 315D53A6943 for <netmod@ietf.org>; Mon, 23 Jun 2008 01:29:41 -0700 (PDT)
Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTP id 37D651B80C5; Mon, 23 Jun 2008 10:29:40 +0200 (CEST)
Date: Mon, 23 Jun 2008 10:29:47 +0200 (CEST)
Message-Id: <20080623.102947.71614638.mbj@tail-f.com>
To: j.schoenwaelder@jacobs-university.de
From: Martin Bjorklund <mbj@tail-f.com>
In-Reply-To: <20080616134614.GA3608@elstar.local>
References: <20080616.113122.210899146.mbj@tail-f.com> <20080616134614.GA3608@elstar.local>
X-Mailer: Mew version 5.2.52 on Emacs 22.1 / Mule 5.0 (SAKAKI)
Mime-Version: 1.0
Cc: netmod@ietf.org
Subject: Re: [netmod] comments on draft-schoenw-netmod-yang-types-00.txt
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: NETMOD WG list <netmod.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe>
List-Archive: <https://www.ietf.org/mailman/private/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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: netmod-bounces@ietf.org
Errors-To: netmod-bounces@ietf.org

Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote:
> On Mon, Jun 16, 2008 at 11:31:22AM +0200, Martin Bjorklund wrote:
> > A comment on the ipv4 address, which contains an optional zone index.
> > Do we need to specify the expected behavior when a server does not
> > support zone index for a particular object?
> 
> This might depend on the particular circumstances of the usage of this
> object. Do you have a concrete proposal?

Maybe say that if the object does not support zones, the error-tag
'invalid-value' should be used.  (or maybe 'bad-element'; it's not
clear to me when 'bad-element'/'bad-attribute' vs. 'invalid-value'
should be used).

Can you elaborate on the particular circumstances that could affect
the error message?


> > RFC4001 contains some discussion about the zone index; can we refer
> > to that rfc in this document?
> 
> I like to avoid a dependency on RFC 4001. Which discussion do you
> mean? Would it be sufficient to add the following text to the
> description clauses of ipv4-address and ipv6-address?
> 
>   The zone index is used to disambiguate identical address values.
>   For link-local addresses, the zone index will typically be the
>   interface index number or the name of an interface. If the zone
>   index is not present, the default zone of the device will be used.

Adding this text would help.  What about the special zone index '0'
(which in 4001 refers to the default zone)?

For the ipv6 type, should we add a reference to rfc4007?

In rfc4001, you had:

   The size of the zone index has been chosen so that it is consistent
   with (i) the numerical zone index, defined in [RFC4007], and (ii) the
   sin6_scope_id field of the sockaddr_in6 structure, defined in RFC
   2553 [RFC2553].

Why do you also allow interface name now?  Can the server decides if
interface name or index is accepted?


/martin
_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

v2.8.7 | Report a Bug | By Email