Subject: [Netconf] Fw: Allow other datastores for Netconf

From: "Bert Wijnen \(IETF\)" <[email-masked]>
Date: Mon, 16 Feb 2009 17:32:02 +0100

It is not clear to me that we MUST now define how other datastores will be 
named.

I guess we can say that the entire choice should be maxOccurs=unbounded,
and that any datastore name (running, candidate, startup, but also any
other datastores that we define via IETF or that any comapny defines)
shgould be a maxIccurs=1. (not sure how you represent that in XSD?)

So I am not sure yet where that puts me in terms of the questions asked by 
Balazs
But I think it is:

1) yes
2) not sure we MUST define that now.
    we did not define it in rfc4741, did we? And that is porbably the place
    where we should have defined it or at least we should define the
    naming conventions there (in IANA considerations or some such section), 
no?

Bert

----- Original Message ----- 
From: Balazs Lengyel
To: Andy Bierman
Cc: netconf mailing list
Sent: Wednesday, February 11, 2009 10:21 AM
Subject: Re: [Netconf] Allow other datastores for Netconf

Hello,

Andy Bierman wrote:
>
> 1) I think you want minOccurs=1, maxOccurs=unbounded for
>    the entire choice, maxOccurs=1 on candidate, running,
>    and startup, and maxOccurs=unbounded on 'any'.
>    You don't need minOccurs=0 on choice members.
>
> 2) The schema implies that all agents will accept this 'any'
>    placeholder parameter, even though :url is required for
>    this feature to have any meaning on the agent.

>
> 3) This seems to be changing the design of NETCONF operations
>    to introduce arbitrary empty elements instead of the <url> element,
>    used everywhere else in NETCONF.  There is no such thing
>    as a config named <foo/> in NETCONF.  Instead, there is
>    a <url>file:://foo</url> allowed.  IMO, partial-lock should
>    be consistent with existing protocol operations.
>

BALAZS:

I will ask the basic question.
1) Do we want to prepare partial-lock for addition of other (non-standard) 
datastores?
2) If the answer 1) is yes how do we want to designate the additional 
datastores
    2a) like the datastores today with an empty element: <datastoreName/>
    2b) with an URL: <url>file:://foo</url> even though the datastore will 
often not be a file
    2c) something else

Handling additional datastores is not part of the partial-locking task. So 
unless we can get
consensus fast, I think we need to drop the issue from partial-locking. Very 
fast for me means
by Monday midnight. I would like the chairmans to explicitly approve this 
approach.

So please voice your opinion on the two questions!

Votes as I understand today (please correct me if I am wrong):

1)
Yes: Mehmet
No: Andy
Don't care: Balazs, Martin

2a) Balazs
2b) Andy
2c)
Balazs
_______________________________________________
Netconf mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/netconf

---

From: "David B Harrington" <[email-masked]>
Date: Mon, 16 Feb 2009 16:14:52 -0500

Hi,

> 1) Do we want to prepare partial-lock for addition of other 

I think partial locking MUST support this if NETCONF supports this.

>     2b) with an URL: <url>file:://foo</url> even though the 

I think NETCONF should define this, not the partial-lock document.
So, for now, partial lock should say it will accept whatever format is
accepted by NETCONF.

And maybe it should say it will accept only formats accepted by
NETCONF, so that as NETCONF is updated, partial lock will comntinue to
work with whatever format is defined by NETCONF.

dbh

---

From: Balazs Lengyel <[email-masked]>
Date: Tue, 17 Feb 2009 15:45:29 +0100

Hello,

> work with whatever format is defined by NETCONF.

But what should we put in XSD/YANG?

A) Nothing, just add text that any additional stuff accepted by 4741 will be accepted inside 
<target> - pretty vague
B) anyXML - very liberal
C) else ???

Balazs

---

From: Andy Bierman <[email-masked]>
Date: Tue, 17 Feb 2009 06:52:05 -0800

Balazs Lengyel wrote:
> A) Nothing, just add text that any additional stuff accepted by 4741 
> will be accepted inside <target> - pretty vague
> B) anyXML - very liberal
> C) else ???
> 

C) add <url> parameter to match the way 4741 does it.
    Only supported if :url is advertised by the agent

> Balazs

Andy

---

From: Martin Bjorklund <[email-masked]>
Date: Tue, 17 Feb 2009 16:08:46 +0100 (CET)

Andy Bierman <[email-masked]> wrote:
> > A) Nothing, just add text that any additional stuff accepted by 4741 will be
> > accepted inside <target> - pretty vague
> > B) anyXML - very liberal
> > C) else ???
> > 
> 

But we don't want to support partial locking of external files.  How
would your agent enforce such a lock?

Also, according to section 8.8 of 4741, you cannot <lock> a url.

/martin

---

From: "Ersue, Mehmet (NSN - DE/Munich)" <[email-masked]>
Date: Tue, 17 Feb 2009 16:21:37 +0100

Hi Balazs,

I think it is sufficient to provide b). This addresses already 
the main concern of having the constant "3" in XSD/YANG,
where NETCONF base protocol is open to have additional 
datastores.

The effort to get XSD bullet-proof and self-validating is not 
feasible. I guess, there will be another version of the document 
after 09/09 using YANG as normative, right?

Cheers, 
Mehmet

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of ext Balazs Lengyel
> Sent: Tuesday, February 17, 2009 3:45 PM
> To: David B Harrington
> Cc: 'netconf mailing list'
> Subject: Re: [Netconf] Fw: Allow other datastores for Netconf
> 
> Hello,
>

---

From: Andy Bierman <[email-masked]>
Date: Tue, 17 Feb 2009 07:30:14 -0800

> Also, according to section 8.8 of 4741, you cannot <lock> a url.

IMO, there are only 3 recognized standard databases.
There is also <url> to deal with non-standard databases.

How should we apply the standard to non-standard databases?
We don't.  We drop the whole idea of hacking this into partial-lock,
and determine that adding more standard databases is not in
the new NETCONF charter, and neither is supporting non-standard databases.

A vendor can already augment the partial-lock (YANG) data model.
An abstract element/substitutionGroup hook in the partial-lock
XSD would allow the same thing.  The standard can say that the
hook is there for future standard extensions, and BTW it
supports vendor extensions as well.  A real element (anyXML)
is the wrong approach.

Andy