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

From: Martin Bjorklund <[email-masked]>
Date: Mon, 16 Jun 2008 11:31:22 +0200 (CEST)

Hi,

I have a comment on the ip prefix types.

The text says:

    The IPv4 address represented in dotted quad notation should have
    all bits that do not belong to the prefix set to zero.

Should a server treat e.g. 10.0.0.1/8 and 10.0.0.2/8 as equal values?
(For example if a list entry exists with key 10.0.0.1/8, should a
request to create 10.0.0.2/8 fail?)

Should a server accept 10.0.0.1/8 as an input value, but send back
10.0.0.0/8?

Is a server allowed to accept 10.0.0.1/8 as an input value, but send
back 10.0.0.0/8?

Would it be better to s/should/MUST/ in the description above?

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?  RFC4001 contains some
discussion about the zone index; can we refer to that rfc in this
document?

/martin

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

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 16 Jun 2008 15:46:14 +0200

> Should a server accept 10.0.0.1/8 as an input value, but send back

Yes, MUST might be a better choice to avoid this sort of problems.

> 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?

> 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.

/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/>
_______________________________________________
netmod mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/netmod

---

From: Martin Bjorklund <[email-masked]>
Date: Mon, 23 Jun 2008 10:29:47 +0200 (CEST)

> 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?

>   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

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 24 Jun 2008 12:31:10 +0200

> Can you elaborate on the particular circumstances that could affect

I also have trouble to understand which RFC4741 error tag is for which
purpose. Perhaps Andy can shed some light on this...
 
> (which in 4001 refers to the default zone)?

Do we need it? If you want the default zone, you can simply omit the
zone part. But I would also not object against having %0 mean the
same thing for those who like index numbers. But see below...

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

Done.

> interface name or index is accepted?

This is something for the WG to discuss. I allowed interface names
since this is what I believe is commonly shown on CLIs. It seems that
most people I get in touch with refer to interfaces by the equivalent
of ifName instead of ifIndex.

Sure, allowing both formats in the zone index raises a bunch of
questions that should be answered:

  - does a number take precedence to be an index number (if there is
    an interface with a matching number)

  - what are boxes supposed to generate (index numbers or names)

  - are implementations supposed to remember whether a value was
    configured as name or number.

All these questions could be avoided by just having one format, which
however requires to find agreement how NETCONF data models identify
interfaces, by name or by index number. Opinions more than welcome.

/js

---

From: Andy Bierman <[email-masked]>
Date: Wed, 25 Jun 2008 11:48:29 -0700

> purpose. Perhaps Andy can shed some light on this...

   <rpc-error>
     <error-type>application</error-type>
     <error-tag>operation-not-supported</error-tag>
     <error-severity>error</error-severity>
     <error-message>Zone index encoding not supported.</error-message>
   </rpc-error>

invalid-value is not correct when the value is valid
for the leaf syntax, as defined in the data model.

Andy

---

From: Martin Bjorklund <[email-masked]>
Date: Wed, 25 Jun 2008 21:25:12 +0200 (CEST)

Hi,

>      <error-message>Zone index encoding not supported.</error-message>

I would never have guessed 'operation-not-supported'!  The term
"operation" is used for two things in rfc4741; as the "rpc operation"
(e.g. get-config), and also as the edit-config inline operations
(e.g. 'merge').

So I would think that this error is returned e.g. if someone tries to
do an edit-config towards running, and :writeble-running is not
advertised.

> for the leaf syntax, as defined in the data model.

invalid-value is defined as

    The request specifies an unacceptable value for one
    or more parameters.

It's not obvious to me that "unacceptable value" only covers syntax
checks.

If we ever do a revised 4741, I think more text should be added
re. the error codes.

/martin

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 25 Jun 2008 21:53:10 +0200

On Wed, Jun 25, 2008 at 09:25:12PM +0200, Martin Bjorklund wrote:
 
> I would never have guessed 'operation-not-supported'!

So do I.

> The term "operation" is used for two things in rfc4741; as the "rpc
> operation" (e.g. get-config), and also as the edit-config inline
> operations (e.g. 'merge').

Yes, that is bad. Terminology is not really consistent in RFC 4741.

> It's not obvious to me that "unacceptable value" only covers syntax

Same here.

> If we ever do a revised 4741, I think more text should be added

Yes. And we have to find consistent terminology at the same time and
make sure the document is consistent in the use of terms.

/js

---

From: Andy Bierman <[email-masked]>
Date: Wed, 25 Jun 2008 13:28:57 -0700

>> I would never have guessed 'operation-not-supported'!

That was the intent of allowing 'application layer operation'
not supported.   I guess bad-element could apply.  I agree the
terminology is bad.

Andy