Subject: Re: [netmod] comments on draft-ietf-netmod-yang-11

From: Martin Bjorklund <[email-masked]>
Date: Thu, 01 Apr 2010 09:56:41 +0200 (CEST)

Hi Kent,

Kent Watsen <[email-masked]> wrote:
> 
> Two concerns:
> 
> 1. In section 5.6.4, why is the module-parameter included in the
> capability-string?  My understanding is that each module has a unique
> namespace, so is listing its name in the capability string really needed? In
> many examples it seems redundant (e.g. http://example.com/syslog?module=syslog)

If you specify a deviation, you specify it with the module name:

  http://example.com/syslog?module=syslog&deviations=my-devs

In this case 'my-devs' is the name of the module with the deviations.
Since the module name is specified in the capability string, the
client can find out which module/namespace/revision it refers to.

> 2. Section 6.3.1 says YANG compilers MAY ignore unknown extensions.  This
> behavior may not be OK in all cases.  Can the modeler be provided syntax to
> indicate if it's OK to ignore an extension?

No.

This would be something like "must-understand true;".

Such a statement would be useful if the extension changed the
semantics of existing statements.  But I don't think we want to allow
that.  The YANG statements have their meaning, and compliant
implementations must follow this.

> And a few editorial comments:
> 
> 5.6.4.[2-3]: (both)
>   - example missing revision= in capability string

Well, the revision statement is optional, so it is strictly speaking
not a bug.  Also, it makes the example easier to read...

> 6.1.3.1:
>   - would be good if the "first line\n" + "  second line"
>     examples could be indented similarly

The point is that regardless of indentation, these strings are equal.

>   - also, it's not clear if there should be 2 or 3 spaces
>     in the second example.  The text says "up to the column
>     of the double quote character".

How about  "up to and including the column of the double quote
character"?

>     The example has 2 spaces,
>     but I'd rather not leave it to an example.  How about 
>     using XSD's "token" type as an example? Token: "A string
>     that does not contain line feeds, carriage returns, tabs,
>     leading or trailing spaces, or multiple spaces"

I'm not sure I understand how that relates to this?  These two strings
are equal in YANG:

  "foo  bar" 
  'foo  bar'

An xsd:token interpretation of the first of these is 'foo bar'.

/martin

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 1 Apr 2010 10:11:07 +0200

On Thu, Apr 01, 2010 at 04:13:40AM +0200, Kent Watsen wrote:
> 
> Two concerns:
> 
> 1. In section 5.6.4, why is the module-parameter included in the capability-string?  My understanding is that each module has a unique namespace, so is listing its name in the capability string really needed? In many examples it seems redundant (e.g. http://example.com/syslog?module=syslog)

One reason is that the module-parameter tells you unambiguously what
the module name is; guessing the modulename by picking something out
of the namespace URI can lead to errors are requires that we define
CLRs how the namespace URI is formed.

> 2. Section 6.3.1 says YANG compilers MAY ignore unknown extensions.  This behavior may not be OK in all cases.  Can the modeler be provided syntax to indicate if it's OK to ignore an extension?

I think this was discussed in the past and we concluded that extensions 
that change the semantics of the core of the language are bad for 
interoperability.

/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: Kent Watsen <[email-masked]>
Date: Thu, 1 Apr 2010 12:28:51 -0700

> client can find out which module/namespace/revision it refers to.

I see, good point.

> implementations must follow this.

Right, features are always additive.  It's the deviations that can modify previously defined behavior and deviations are ignore-at-your-own-risk, so that works out...

> not a bug.  Also, it makes the example easier to read...

Then perhaps the statement in 5.6.4.1 is wrong? "A server MUST advertise all revisions of all modules it implements"

> The point is that regardless of indentation, these strings are equal.

That was on purpose? - wow, you might want to make that more clear...

> How about  "up to and including the column of the double quote

Yup, that resolves it, thanks

> An xsd:token interpretation of the first of these is 'foo bar'.

I see, you want to preserve internal whitespace as well, which is a good. So for instance:

  description
    "paragraph1

     paragraph2
       * bullet1
          * sub-bullet1
          * sub-bullet2
       * bullet2
    ";

Would preserve the layout.  Cool.

Thanks,
Kent