Subject: [Netconf] How to specify a namespace in a options/get/head/delete request

From: lianji <[email-masked]>
Date: Thu, 27 Jul 2017 02:23:52 +0000

Hi, all,

I'm wondering how to specify a namespace in a options/get/head/delete message. Should it be a part of the request uri? What's the format?

e.g.
"example-jukebox" YANG Module is defined in rfc8040 in namespace "http://example.com/ns/example-jukebox". We can get data as:

GET /restconf/data/example-jukebox:jukebox/library/artist=Foo%20Fighters/album=Wasting%20Light HTTP/1.1
Host: example.com
Accept: application/yang-data+xml

If the namespace is required in the request, how to do it? Should it be put in the uri and looks like this:

GET /restconf/data/ example/com/ns/example-jukebox:jukebox/library/artist=Foo%20Fighters/album=Wasting%20Light HTTP/1.1
Host: example.com
Accept: application/yang-data+xml

Thanks,
Anji

---

From: Douglas Hubler <[email-masked]>
Date: Thu, 27 Jul 2017 10:55:42 +0000

Namespace cannot be required here because module names themselves should be
"globally" unique
   /restconf/data/{module}:{container or list}/...

In addition, from what I understand, paths in general use the "prefix" to
represent the namespace

YANG
==========
module a {
   import b {
      prefix "x";
   }
}

uses "b:x";

RESTCONF
==========

/restconf/data/a:b:x

On Wed, Jul 26, 2017 at 10:24 PM lianji <[email-masked]> wrote:

> Hi, all,
>
>
>
> I’m wondering how to specify a namespace in a options/get/head/delete
> message. Should it be a part of the request uri? What’s the format?
>
>
>
> e.g.
>
> "example-jukebox" YANG Module is defined in rfc8040 in namespace “
> http://example.com/ns/example-jukebox”. We can get data as:
>
>
>
> GET
> /restconf/data/example-jukebox:jukebox/library/artist=Foo%20Fighters/album=Wasting%20Light
> HTTP/1.1
> Host: example.com
> _______________________________________________
> Netconf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netconf
>

---

From: lianji <[email-masked]>
Date: Fri, 28 Jul 2017 09:03:26 +0000

Hi, Douglas,

I don’t agree “module names themselves should be "globally" unique”. A module could be defined by anybody and nobody can guarantee it’s unique. That’s why we need a namespace. The author of a module can guarantee the module name is unique in the namespace but not outside of it.

One more bit, a Yang module could have multiple versions which could be identified with module name & revision. In this case ,we need revision to understand the request correctly.

Thanks,
Anji

发件人: Douglas Hubler [mailto:[email-masked]]
发送时间: 2017年7月27日 18:56
收件人: lianji <[email-masked]>; [email-masked]
抄送: Zhengguangying (Walker) <[email-masked]>
主题: Re: [Netconf] How to specify a namespace in a options/get/head/delete request

Namespace cannot be required here because module names themselves should be "globally" unique
   /restconf/data/{module}:{container or list}/...

In addition, from what I understand, paths in general use the "prefix" to represent the namespace

YANG
==========
module a {
   import b {
      prefix "x";
   }
}

uses "b:x";

RESTCONF
==========

/restconf/data/a:b:x

On Wed, Jul 26, 2017 at 10:24 PM lianji <[email-masked]<mailto:[email-masked]>> wrote:
Hi, all,

I’m wondering how to specify a namespace in a options/get/head/delete message. Should it be a part of the request uri? What’s the format?

e.g.
"example-jukebox" YANG Module is defined in rfc8040 in namespace “http://example.com/ns/example-jukebox”. We can get data as:

GET /restconf/data/example-jukebox:jukebox/library/artist=Foo%20Fighters/album=Wasting%20Light HTTP/1.1
Host: example.com<http://example.com>
Accept: application/yang-data+xml

GET /restconf/data/ example/com/ns/example-jukebox:jukebox/library/artist=Foo%20Fighters/album=Wasting%20Light HTTP/1.1
Host: example.com<http://example.com>
Accept: application/yang-data+xml

Thanks,
Anji
_______________________________________________
Netconf mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/netconf

---

From: Ladislav Lhotka <[email-masked]>
Date: Fri, 28 Jul 2017 11:13:47 +0200

> On 28 Jul 2017, at 11:03, lianji <[email-masked]> wrote:
> 
> Hi, Douglas,
>  

Module names needn't be globally unique but, as Juergen wrote, they have to be unique within a server data model. That's sufficient for avoiding clashes.

I believe that namespace URIs were introduced mainly because they were needed in the original XML encoding.

> One more bit, a Yang module could have multiple versions which could be identified with module name & revision. In this case ,we need revision to understand the request correctly.

Again, RFC 7950 says:

A server MUST NOT implement more than one revision of a module.

Lada

--
Ladislav Lhotka
Head, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67

---

From: Kent Watsen <[email-masked]>
Date: Fri, 28 Jul 2017 13:47:05 +0000

>> One more bit, a Yang module could have multiple versions which 
>> could be identified with module name & revision. In this case,
>> we need revision to understand the request correctly.
>
> Again, RFC 7950 says:
>

And the NMDA variant of this statement would be:

  A server MUST NOT implement more than one revision of a module per datastore.

Kent

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 28 Jul 2017 16:13:41 +0200

>   A server MUST NOT implement more than one revision of a module per datastore.

Not sure this is correct or desirable. You do not want conventional
datastores run with different versions. Does it make sense the
conventional and operational datastores implement different versions?

/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: "Steve Truong (struong)" <[email-masked]>
Date: Fri, 28 Jul 2017 14:58:55 +0000

>> One more bit, a Yang module could have multiple versions which could 
>> be identified with module name & revision. In this case, we need 
>> revision to understand the request correctly.
[Steve Truong] The YANG library tells the client what revision of a module the server implements (as well as any associated deviations).

Kent

---

From: Kent Watsen <[email-masked]>
Date: Fri, 28 Jul 2017 16:20:28 +0000

> conventional and operational datastores implement different versions?

As discussed in Prague, the new YANG Library model's 'module' list is
now keyed by 'id' (not module-name/revision) because there might be
variations in feature/deviation per datastore.  Technically, the YANG
Library module allows the various conventional datastore entries (in
/datastores) to point to different module-sets, but servers would be
in error.  All the conventional datastore entries SHOULD (MUST?) point
to the same module-set, and hence to the same module-name/revision tuple.

K.

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 28 Jul 2017 18:37:12 +0200

> to the same module-set, and hence to the same module-name/revision tuple.

Lets not turn a simple statement into a complex nightmare. RFC 7950
said: A server MUST NOT implement more than one revision of a module.
What is the reason to relax this simple and clear statement? Just
because we can is not a good reason.

/js

---

From: Andy Bierman <[email-masked]>
Date: Fri, 28 Jul 2017 09:44:48 -0700

> because we can is not a good reason.
+1

What problem does this solve for network operators? Prodice some use-cases.
Seems rather complicated to implement on the client side and understand by
operators.

/js

Andy

---

From: Kent Watsen <[email-masked]>
Date: Fri, 28 Jul 2017 17:09:11 +0000

Fine, keep the statement as is.  I guess that it's still technically correct, in that even if an
NMDA server had variations in a module's feature/deviations in datastores, those
variations would still be on the same *revision* of the module so, technically, only
one *revision* is implemented.

K.

On 7/28/17, 12:44 PM, "Andy Bierman" <[email-masked]<mailto:[email-masked]>> wrote:

On Fri, Jul 28, 2017 at 9:37 AM, Juergen Schoenwaelder <[email-masked]<mailto:[email-masked]>> wrote:

+1

What problem does this solve for network operators? Prodice some use-cases.
Seems rather complicated to implement on the client side and understand by operators.

/js

Andy

---

From: Randy Presuhn <[email-masked]>
Date: Fri, 28 Jul 2017 10:34:36 -0700

Hi -

On 7/28/2017 9:37 AM, Juergen Schoenwaelder wrote:
...
> because we can is not a good reason.

Back in the 1980's I encountered systems (both telco and internet) that
could be simultaneously populated with multiple versions of a given kind
of card, and in some cases the management properties of these versions
differed, though usually in ways easily handled through inheritance in
OO models.  But support for such configurations has long been considered
beyond the scope of netconf - if one needed to do it, then rather than
"revising" the module one would create a new one which would bear a
remarkable resemblance to the old one, and presumably fork any module-
specific management software accordingly.

Randy

---

From: Andy Bierman <[email-masked]>
Date: Fri, 28 Jul 2017 10:51:31 -0700

Hi Randy,

I agree this use-case is beyond the scope of NETCONF.

I do not agree with the premise that this MUST requirement is RFC 7950 can
be ignored or changed.  The RFC clearly defines a revision and defines
how to identify a module revision.

A datastore is merely an abstraction -- just another input parameter.
They are not much use without standard protocol interaction models.
The WG did a good job with NETCONF base:1.1, allowing several server
variants
but well-defined interaction models allowed client developers to easily
support
all the variants.

The protocol interactions between datastores are now way more complicated
than before.  Time will tell if client developers support it and operators
like it.

Andy

---

From: Jan Lindblad <[email-masked]>
Date: Mon, 31 Jul 2017 09:48:47 +0200

Use cases where support for multiple versions of hardware, software, services, ... are required are quite common, in my experience. The good news is that this is well within reach for NETCONF+YANG without any sort of extensions or tweaking. What you seem to forget is that the version of the YANG model description of an object is quite separate from the version of the object that it describes. 

It's trivial to make a YANG model has a list of line cards with a choice of linecard-xyz-v13 and linecard-xyz-v14. And in the next version of the YANG model, extend the model to also include linecard-xyz-v12.

/jan