Subject: [Netconf] Alia Atlas' Block on charter-ietf-netconf-18-10: (with BLOCK)

From: Alia Atlas <[email-masked]>
Date: Wed, 12 Apr 2017 08:57:00 -0700

Alia Atlas has entered the following ballot position for
charter-ietf-netconf-18-10: Block

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/charter-ietf-netconf/

----------------------------------------------------------------------
BLOCK:
----------------------------------------------------------------------

This charter uses the term "I2RS protocol" and I2RS isn't doing its own
protocol.

Now, what I heard secondhand is that the intent is for NetConf to defined
the needed
capabilities so that the I2RS WG can define the necessary extensions -
probably to
RestConf - to support the well-documented requirements.

As Responsible AD for I2RS, I need to actually hear and understand the
change and intended
split of work.  This change is going to require a recharter for I2RS,
since it is explicitly not
chartered to do any protocol work; the expectation has been that this
would be done in NetConf
and NetMod, as needed.

I am quite positive on the idea of letting the I2RS WG define the
necessary extensions and 
finally be able to move at the speed appropriate to the active
contributors - but we need
to be correct in terminology, clear on the work split, and understand how
this will proceed.

---

From: Benoit Claise <[email-masked]>
Date: Wed, 12 Apr 2017 11:17:13 -0700

Alia,

> https://datatracker.ietf.org/doc/charter-ietf-netconf/
I'm actually glad you made that point. I introduced that term to make 
sure we cover I2RS, but I've not been happy about it. I could not find 
the right wordings.
> RestConf - to support the well-documented requirements.

You're right, the revised DS document specifies the needed capabilities. 
See 
https://datatracker.ietf.org/doc/html/draft-ietf-netmod-revised-datastores#appendix-B

Thinking about the text.

OLD: Define capabilities for NETCONF and RESTCONF to support I2RS 
protocol and ephemeral-state datastore requirements.

NEW: Define capabilities for NETCONF and RESTCONF to support I2RS and 
ephemeral-state datastore requirements.

Or even better, IMO
NEW: Define capabilities for NETCONF and RESTCONF to support the 
ephemeral-state datastore requirements.

Now, wait. Actually, I believe you should have all you need for I2RS 
part of entry 6
6. Based on the revised datastore concept work in NETMOD, provide a 
revision for the NETCONF and RESTCONF protocols and the used datastore 
framework.

In the end, we could remove the point 7.

Feedback?

Regards, Benoit
> .

---

From: Benoit Claise <[email-masked]>
Date: Tue, 25 Apr 2017 10:52:02 +0200

Dear all,

In order to progress this charter, I would like to clarify one point 
with the revised datastore concept authors. See below.
> You're right, the revised DS document specifies the needed 
> capabilities. See 
The current charter is at 
https://datatracker.ietf.org/doc/charter-ietf-netconf/

Am I correct that the entry 6 will cover all the new NETCONF/RESTCONF 
capabilities that I2RS might need, based on 
draft-ietf-netmod-revised-datastores?
Am I correct that it will be up to I2RS authors to specify the I2RS 
datastore semantic, persistence, guidelines, along with the I2RS concept 
of priorities?
If yes to both questions, the current charter point 7 is not right ...

    7. Define capabilities for NETCONF and RESTCONF to support I2RS
    protocol and ephemeral-state datastore requirements.

... because there are no new RESCONF/NETCONF capabilities needed.
Hence my proposal to remove it.

The last question is: what is the right place for this  "I2RS datastore 
semantic, persistence, guidelines, along with the notion of priorities" 
document?

Regards, Benoit

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 25 Apr 2017 18:45:36 +0200

On Tue, Apr 25, 2017 at 10:52:02AM +0200, Benoit Claise wrote:
> Dear all,
> 
> In order to progress this charter, I would like to clarify one point with
> the revised datastore concept authors. See below.

[...]
 
> semantic, persistence, guidelines, along with the notion of priorities"

Here is my take:

a) Once we have NMDA extensions in place, the protocols (NETCONF and
   RESTCONF) should not need any additional protocol work to support
   I2RS. If the NETCONF WG, for whatever reason, fails to reach this
   goal, then I think it should be the NETCONF WG's task to fix this.

b) Once we have NMDA extensions in place, the definition of an I2RS
   datastore with its specific semantics should be done in the I2RS
   working group. None of this should require _changes_ to the NMDA
   enabled NETCONF/RESTCONF protocols or the YANG language. If the
   NETCONF WG and the NETMOD WG, for whatever reason, fails to reach
   this goal, then I think it should be the NETCONF or NETMOD WG's
   task to fix this.

In other words, my hope is that the NMDA solution provides a workable
separation of concerns.

/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: Tue, 25 Apr 2017 18:45:46 +0000

My take is that, once we update NC/RC to support the intended, dynamic, and operational datastores, that will go a long way towards achieving what I2RS needs, maybe even all the way.  That said, I don’t know how generic some of the things discussed in the following can be made:

  draft-hares-netmod-i2rs-yang
  draft-hares-netconf-i2rs-netconf
  draft-hares-netconf-i2rs-restconf

For instance, the secondary priority concept seems very unique to I2RS and thus may entail an I2RS-specific parameter passed in <edit-data>.  For extensions such as this, I would think they'd be done in I2RS.

To answer Benoit's question, I agree that #7 seems out of place.  If we remove it, then #6 might be better written:

OLD
  Based on the revised datastore concept work in NETMOD, ...
NEW
  Based on the revised datastore concept work in NETMOD, and
  protocol requirements provided by I2RS, ...

Thoughts?

Kent

[...]

Here is my take:

/js

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

---

From: Benoit Claise <[email-masked]>
Date: Tue, 25 Apr 2017 23:46:49 +0200

> In other words, my hope is that the NMDA solution provides a workable
As I understand, you're in favor of removing the item 7 from the 
charter. Thanks Jürgen.

Regards, Benoit

---

From: Benoit Claise <[email-masked]>
Date: Tue, 25 Apr 2017 23:47:48 +0200

>    protocol requirements provided by I2RS, ...
That makes sense.

Alia, fine with you?

Regards, B.

---

From: "Mehmet Ersue" <[email-masked]>
Date: Wed, 26 Apr 2017 14:29:36 +0200

Hi Benoit, All,

I think we all agree that any NC/RC extensions, including new and changed
capabilities/RPCs as well as YANG modules describing formal protocol
behavior, should be developed in NETCONF WG.

Point 6) and 7) in NETCONF charter proposal have been so far discussed as
two different work items done by people with different background. Where
point 6 was meant to be only the basic DS support point 7 covers the
remaining functionality/capabilities from I2RS pov. e.g. supporting
ephemeral DS. The idea was that the authors of point 6) focus only on basic
DS support and Sue Harris shouldn't need to care of that part. This is the
reason why we kept them separate.

The question raised is actually whether point 6) can be done in such a
generic way (e.g. the generic handling of dynamic datastores) so that it
addresses the I2RS requirements on DS handling using NC/RC. 
I think it is no issue to merge the two charter items which could be still
addressed with two documents.

I also agree that any I2RS specific parts like "I2RS datastore semantic,
persistence, guidelines, along with the notion of priorities" should be done
in I2RS WG.

>>> NEW  Based on the revised datastore concept work in NETMOD, and

I think we should talk on DS handling in general and use the generic term
"dynamic datastore" instead of " ephemeral-state datastore".
Also assuming that this functionality will be used by other WGs in the
future we shouldn't limit it to and mention I2RS explicitly.

Regards,
Mehmet

> -----Original Message-----
> From: Benoit Claise [mailto:[email-masked]]
> Sent: Tuesday, April 25, 2017 11:47 PM
> To: Alia Atlas <[email-masked]>; The IESG <[email-masked]>; netconf-
> [email-masked]; [email-masked]
> Subject: Re: [Netconf] Alia Atlas' Block on charter-ietf-netconf-18-10:
(with
> BLOCK)
> >> The last question is: what is the right place for this  "I2RS
> >> datastore semantic, persistence, guidelines, along with the notion of
> priorities"
> >> document?
> > Here is my take:
> >
> As I understand, you're in favor of removing the item 7 from the charter.
> Thanks Jürgen.
> 
> Regards, Benoit
> >
> > /js
> >