Minutes for NETCONF at IETF-94
minutes-94-netconf-1

NETCONF 94 Agenda:

   - draft-leiba-netmod-regpolicy-update (3 min)

   Asking room for capabilities in iana registries move from rfc required to
   expert reviews? Mehmet: Any objections from within this working group?
   Benoit: Do we want to allow ability to create IANA registeries with expert
   review? Dan Romascanu: Needs to review the document, but does not see a
   problem.

No objection raised to proposal in Barry Leiba draft
The process in the leiba-draft will be then used in future for non-standard
capabilities in the registry.

Benoit: Time capability draft is a AD sponsored draft

Benoit Claise: There was an AD sponsored netconf capability draft that needed
IANA actions. Joel suggested to have an experiment with registry update
process. We wanted to change the registration process for the capabilities. We
are asking whether it would be possible to not use the IANA registry and
instead to use the expert review? Mehmet: has anyone read the draft? Do you
have any comments? Benoit: do we want to have capabilities for experiments? Dan
Romascanu: [missed, see above] Benoit: the draft is already published. We do
not want to disturb the WG if there is a limited consensus.

  Non-Chartered items:

      1. I2RS strawman proposal - S. Hares (20 min)

Sue Hares presenting.

Mehmet: what about next steps? what is planned for the next time?
Susan: any questions, complaints? [no response in the room]
Sue: our first goal was to figure what to do with the minimal requirements. If
the effort looks good we will work with netconf wg to define the full protocol.
Sue: Action item 1 - what to do with requirements. Mehmet: let's discuss next
week to align with the upcoming protocol work. Sue: please tell us what we need
to add into netconf protocol.

Jason Sterne: is the idea that ephemeral always takes priority over config? 
ephemeral always wins, not last one always wins.  Does an operator has a way to
overwrite / preempt ephemeral Sue: higher priority clients can overwrite lower
priority clients

Jason: slide 12: is scheduler client prirotity checked/ compared vs ephemeral?
do you see any mechanism for operator to override the ephemeral
Sue: the client can be overridden by higher priority clients. You can delete
the ephemeral and then the config will take over. You can do both config and
ephemeral at the same time. Jason: you have a management interface. Does it
have a pririty? Sue: the client in the picture is the I2RS client. Jason: my
understanding the top level was management interface, Sue: it is I2RS capable
management client. Jeff Haas: is there any way for static? to win? No, not at
this time. We do not allow for infinite sets of overlays, no infinitely deep
panes of glass model. Jason: my point was about the ability for operator to
override the ephemeral decision. Jeff: that is understood, and this should be
done via config/CLI mechanisms. Jason: I am referring to the ability to
override. Jeff: one of the things considered was whether some mechanism of
tagging the ephemeral as not being overridable. Sue: that potentially can be
used in your scenario, config could be higher priority than ephemeral. Balasz -
jabber: are lower priority ephemeral config operations stored, or are they
silently ignored? Sue: excellent question - get on the list - related to
caching Sue: please get on the list and discuss this.

Sue: if you really think you must have ephemeral state, that's not in hte model.



  Chartered items:

      1. Subscribing to YANG datastore push updates - Alex Clemm (10 min)
         https://tools.ietf.org/html/draft-ietf-netconf-yang-push-00

Alberto Gonzalez Prieto presenting

Martin Bjorklund: Why do you have different ways to structure encodings - why
not use YANG-patch for both? Maybe specify another option to indicate user
preference for encoding style
                Alberto: good suggestion, will consider
Martin: why do you have different ways depending on encoding? Why not use YANG
patch for both? Alberto: we thought it would be more intuitive to use NETCONF
approach and not the RESTCONF approach. Martin: maybe you should first define
patch style, and then encoding style?

From Jabber Andy Bierman: if the client is not the same as receiver - what
protocol is used there? Alberto: [missed]

Jeff Haas: we think that sending to more than one station is needed, multiple
receivers could need different encodings though. Also, Receivers should be able
to select their own encoding Alberto: receivers should be able to tweak the
subscription parameters. Benoit: what is the interaction between this and
update notification document? Alberto: we had to change the semantics of
subscribe time?? Benoit: I am still waiting for update of 5277bis?

Alex Clemm: We didn't want to extend the semantics in this document.
Benoit: Anyone working on 5277  bis in charter? [a: not yet]
Benoit: is there anyone in the room working on 5277bis? Not yet.

Mahesh: is there a requirement for receivers to be able to request the
notifications midstream? Alberto: the receiver can tweak the parameters, If you
are talking about the subscriber, that is something that the ? can do. There is
nothing that mandates that. Alex Clemm: when you have multiple receivers that
want to tweak their parameters, that should be multiple subscriptions,
otherwise it is too complex. Martin: why not use call home for multiple
subscriptions? Alberto: yes, that is possible. Jeff Haas: call home is one of
the cases that we need to support in the base profile. We have customers that
will want to use alternative formats; e.g. grpc and protobufs.  Motivation for
asking whether you can tweak the receiver parameters - if you have those,
serializing the protocol on the wire is the easy part. SNMP traps can be an
example - once you have a schema, transferring is just a serialization.
encoding might even be grpcs or protobufs Jabber - Balsalz Lengel: will replay
be supported from push Alberto: right now that is not supported. Mehmet: would
it be good to support? Alberto: good input, will think about it. Alex Clemm: it
would be good to support, but need to know the requirements. You may have use
cases that need to get the most recent? response? (many applications may not
require raw replay, they want just the most recent -there is overhead
associated with replay ability - does not make sense to store/retain updates
for replay for longer time) Martin: if you do not have the subscription, you do
not know what to replay as you do not have filters, you would have to buffer
all. Alberto: it is not good to mandate to support always. Jeff: we talked
about this in the context of I2RS traceability for retrieving the subset of
data. If the data is cached, it can be replayed, but need not to cache too
much. Mehmet: we are running out of time. Martin: [missed] Jeff: timestamps
would be an example. Andy - jabber: we do not replay what we have stored in the
past. Andy - jabber: what does it mean if start time is in the past Alberto: in
this case, subscription starts immediately.  [Alex Clemm note: also, time in
the past still serves as anchor for periodic subscriptions- in that case, the
next update will be sent on first interval from the start time)

      2. RESTCONF & Co. - M. Bjorklund (45 min.)
         - RESTCONF Protocol

Martin Bjorklund presenting.

Kent Watsen: the spec requires realm to be sent by the server, but we do not
specify what realm should it be, either user configurable, or hardcoded. Realms
are used for virtual hosts and do not foresee that RESTCONF server would be
used in that context.

Martin: this is an open issue for the WG to decide
Tim ...: Why can't this not be part of a virtual host

?: restconf server can be a part of virtual host - would be applicable?

Kent: the server runs in VM but that is not the issue as the server's context
is a single host.

Kent: we can just stop sending notifications. We also have a callhome type of
connections that could be used here. Martin: the other question was how would
the client actually stop it Jeff: I would be careful with just dropping the TCP
session, it may end up in a mess. There should be a clear notification to stop.

Tim....: There needs to be a clean way for client to request notifications to
be stopped.  Not just drop connection Jeff Haas: seconding what Jim said.
Transport session can just go away for unknown reason. Kent: servers and client
must be coded to handle drops of transport sessions, if they don’t do that then
it is implementation issue. Jeff Haas: this is intent question.

Martin: need to resolve this on the list

Mehmet: is this seen as an open issue?
Martin: this seems to be an open issue and we need to find a solution.

Kent: there is one more issue on authentication - any authentication mechanisms
is allowed but does not specify which one must be supported. We need it
specified for requesting client certificates. Some draft that was referenced is
expired

Mehmet: our plan was to LC next week - do you think it is possible to close
those issues in 1-2 weeks? Martin: we need to agree on the open issues -
subscription/notification thing, how to do in a nice way. Kent: we need more
discussion. Mehmet: good.

         http://tools.ietf.org/html/draft-ietf-netconf-restconf
         - YANG Patch Media Type

Martin presenting.

no questions and comments.

         http://tools.ietf.org/html/draft-ietf-netconf-yang-patch
         - YANG Module Library
         http://tools.ietf.org/wg/netconf/draft-ietf-netconf-yang-library/

Martin presenting.
[updating the slides as the ones presented are not current] [slides presented
are draft-ietf-netconf-yang-library-2.pdf]

Jeff Haas: an example could be I2RS - we are trying to define how to do it in
netconf and restonf, but restconf will be first. netconf is not guaranteed to
be supported. Martin: yes, we need to look at this also on the list, need to
add something to datamodel to support this Sue Hares/I2RS chair: how much more
can you simplify - what is the level of granularity, only restconf/netconf, or
more than that list? Are you thinking about the granularity deeper than the
module level?

Martin: Would have to be extensible list
Martin: the idea is to do this at the module level.  Different idea would be to
have protocol-specific instances of modules. there can be protocol-specific
instances of modules

Jabber - Andy: does restconf have to implement module ietf-netconf.
Martin: that was another example - would say no

Jeff Haas: requirement for I2RS - if the module implements configuration state
and operational state, that operational state may noit be only I2rs state. Do
we need any mechanism to try to separate that? Martin: we need to think about
this.  Might be easier to view this as a sepparte instances, in this case we
don't need any additions, just clarification Martin: maybe would be simple to
view it as separate instances per protocol, and the we need no additions.

Mehmet: plan to go to WGLC with all 3 drafts as a package.  Please try to
finalize in 2 weeks Martin: need to work out the issues on the list first, and
require review Mehmet: can you finalize the issues in next two weeks? Martin:
we will work on a list as that involves many authors.

Lada: restconf depends on YANG 1.1
Martin. And YANG 1.1 depends on YANG library.
Lada: some preliminary conclusion was to target December 1st.

What is the YANG 1.1 schedule?  Lada - Dec 1st

Mehmet: restconf cannot be published before yang 1.1
Mehmet: going to wg lc is our first step.

Martin; nothing stops people from reviewing docs and send comments in the
meantime Mehmet: let's work on the solutions and bring on the list.

Mikael Abrahamsson: the last slides do not seem to be uploaded?
Others: they are there.  Maybe confusion about where

      3. NETCONF Server Configuration Model - K. Watsen (5 min.)
         http://tools.ietf.org/html/draft-ietf-netconf-server-model

Kent presenting.

Kent asking: has anyone read this and comments?

Jeff Haas: I have not read it. Are you aware of Acee's work on this subject too?
Kent: there are other keychain oriented drafts - 3 or 4 - not overlapping with
this.  They are not system-level keychain models, oriented at router.  but, may
have missed some comments when those were discussed.

Mehmet: whether it makes sense to split it into 2 parts - keychain and the rest?
Kent: concern is that groupings have leafrefs into keychain model, if you send
this to other WG you have dependency, would need this to stabilize.  Could
split into documents - but there is still the dependency - splitting may not be
helpful.

Martin: just split the documents?
Kent: there will still be a dependency.

Mehmet: If you do not think splitting is helpful, then how long do you need to
prepare the solution? Kent: There are some issues that are missing.  Clearly it
is a complex topic.  Therefore cannot answer the question how long to complete.

Mehmet: I do not need to hear a deadline, just the indication.

      4. Zero Touch Provisioning for NETCONF Call Home (ZeroTouch) - K. Watsen
      (20 min.)
         http://tools.ietf.org/html/draft-ietf-netconf-zerotouch

Kent presenting.

Kostas Pentikousis: why would the new device not be able to reply to the NMS?
It is initiated from the device, there should be no problems for communication?
Not questioning the design, just want to understand whether there are any
requirements to do that?

Kent: maybe for convenience and simplicity in implementation.  Very few NMS
support call home today, many support initiated connection, so this fits more
easily with existing implementations.  But nothing forces to do it in a
particular way.

Max Pritikin: one of the places where we need to look and see what happens in
the local network is the DHCP redirect server? There is overlap in discussions
with ANIMA approach.

Kent: right.  This diagram does not illustrate what Anima might do.

Mahesh: how many operators are there in this room. Of those, how many would
want to implement a solution like this? Mahesh: how many have read the draft?
Please provide context 4 operators, 2 out of 4 would implement

Mahesh: can we have show of hands of operators that are interested in this type
of solutions.

Max Pritikin: I will indicate that the updated draft to cover the loose ends is
rather large.

Kent: thank you

  Non-Chartered items:

      2. Restconf subscription and HTTP push for YANG datastores - A. Clemm (10
      min)
         https://tools.ietf.org/html/draft-voit-restconf-yang-push-00

Alberto Gonzalez Prieto presenting.

Mehmet: I would like to hear pro and contra concerning having one or two
drafts. My personal view is that two drafts need to go as twins. Alberto: after
the LC we can define a different extension. Alex Clemm: the issue does not seem
to be the bundling of the release date / releasing them together . Should be
release together.  Still, each can be separate, this will be easier to assess,
less options, and then they could be released together. Editorially separate.
Mahesh: can the authors repost the drafts with the correct names? Kent: I think
there should be 1 or 3 drafts. 3 would be - one for generic pub/sub, other for
NETCONF and one for RESTCONF. Martin: it is not easy to read two documents. It
adds to the noise. Better merge. Mehmet: what is your preference? Martin: my
preference would be one, otherwise three. Alberto: what about the conformance?
Martin: I do not think that is a problem. Now the data model is duplicated in
two drafts, and that is almost the same data model. Kent: both callhome and
subscription drafts have to do the same with netconf and restconf. Mahesh: how
many people would prefer to have single draft? How many three? How may would
prefer two? Mehmet: we should discuss this offline, there is no obvious winner.
The current chanter covers the topic. Do people like to address this issue in
this group, or not? When we converge on this agreement, then we can address
whether it is 1 or 3 drafts. Mehmet: who in the room is in favor of addressing
this issue in the netconf wg? Kent: we already adotped netconf push. Given
that, is the question that we want to adopt restconf yang push? Mehmet ...
Martin: in the charter it says only netconf push. Mehmet: charted does not
mention restconf or netconf. Martin. Mehmet: this is a new draft with new
cointent. Mehmet: please show hands is you in favor to address this in netconf
wg. Nobody against. Many hands for.

7 hands for single (did not count the others) - Mehmet: no obvious winner,
charter covers the topic Mehmet: are people supporting this particular topic
(quite a few hands for (between 12 and 20?), none against)

Mehmet: we take this to the list, and then you can provide the corresponding
draft. This agreement needs to be verified on the list - this is a process step.

  Open
      AOB

Mehmet: is there anything else to discuss?

Kent: Update on the callhome work. It is currently in IESG. Except of Stephen
Farrells DISCUSS all other have been closed. Met with TLS co-chairs to get
agreement. I am hopeful that - it describes what we described verbally - that
they agree with that. Will inform the list when I get back from them. Kent:
Github review procedure. Do we need to do another LC on that draft? Be Benoit:
that is a good point. If there are major changes, then maybe the WG should
review it again. If that requires time it is fine., Mehmet: such issues need
indeed to be brought to the mail list

Kent: my plan is to post the updated document and bring the discussion to the
list Mehmet: will be reviewed on the mailing list

Benoit: either you do it - the review, or you do a formal LC.
anything that works is fine

Mahesh: end of meeting.