Minutes for NETCONF at IETF-91
minutes-91-netconf-2

Minutes of the Netconf WG Ssssion in IETF 91 (2014-11-11 1pm)
=============================================================

Yangpatch and Zerotouch close to final call

Benoit and Mehmet thanked Bert Wijnen for the work he did since 22 years for
the OPS area and since 2008 as the NETCONF WG co-chair. The OPS area will miss
Bert.

Call-Home  - Ken
----------------
Is Restconf callhome needed?
Lada: for restconf do you need a new port
Dean B: No need for callhome and restconf
Andy: RESTCONF is for controllers. Northbound inteface has different
requirements than smaller devices.
Hum, do we need callhome restconf? HUMM we want to do it
HUM, do it now (or later): We want to do it now
Single or transport specific 2/3 port for call home?
Mehmet: is technically necessary to differentiate the bindings?
Ken: Differentiating the 3 bindings would need some work.
Andy: Common port would completely break transparency. It will be more
difficult to use if we have a common port plus a differentiating
message.
Ken: node will be configured to know which service to use.
Mikael: there are not too many ports.
Mehmet: we already discussed whether ports are a scarce resource. We
always got back we can use separate ports.
Lada: original discussion was 1 or 2 ports. Now we are at 3 later for
future transports we waill need more. I propose single port.
Martin: If you have single port you need implementation
coordination. It would be difficult to support both NETCONF and
RESTCONF at the sam time.
Andy: single port is extensible
Ken: only for TCP based protocols
Dean: I need just one port to start. use it to bootstrap the sessions
John Messenger: You could send which list of protocols you accept
Jabber: separate ports
Hum: separate port (or single): HUM says separate ports

Netconf over TLS - chairs
---------------------------
HUM: Focus on the use of X.509 for TLS (rfc5539bis) only: Hum says only
Hum: describe algorithm for extracting a user name out of the X509 attributes:
HUM says yes Ken: server model should define what to extract not how. Which
poeces of the certificate to use Mehmet: rfc5539bis should describe how to
extract Bert: we need to describe what to extract not how Juergen: supports
describing the algorithm, agrees with Kent.

Server model  kent
---------------------------------
Has a Yang 1.1 features statement
Andy: do not use YANG 1.1 statements yet
Kent: features are commented out by mistake. I will define name mangeled
features Bert: How long will YANG 1.1 take really. Andy: we cant really use
yang 1.1 now, too early HUM: YANG 1.0 only HUM: Add x.509 client certificates?:
no one for, no one against Joel: Is anybody strongly against it? Jabber: how
often are x.509 hostkeys used? Kent: not really used as it is not part of
OpenSSH but there is a patch. It should become more popular with ZeroTouch &
CallHome. Mikael: if not much work, we should do it. Bert: add it. Kent:
Support for hostkeys, certs? Bert: normally hostkey/certs are generated offline
Kent: hostkey is generated ussually on first boot, cert configured. It is the
same config model I am describing. Bert: this sounds as quite some work Dean
B.: leave it to offline generation. other WGs will comment, much work. Do it
later. HUM: Should we generate ssh host keys/509-certificates via a yang model
or generate them out of band. HUM: Postpone support. Kent: Shall we keep that
as status data. I would take it out HUM: Report hostkeys/certificates via yang
data model HUM: take them out and not report them via a data model Jason Stern:
why are the 2 timeouts mandatory, not behind if-feature Kent: Ok they should
not be mandatory, but as they have a default, they are mandatory false Jason:
should we use if-feature Kent: No need to do that. Andy: If-feature means
optional to implement. Andy: clean up iana section

Restconf - Andy
---------------
Bert: check issue list, add to it if needed
Lada:  Defining namespaces via groupings is problematic. Uses defines
the namespace not the grouping.
Andy: yes, add some text to define namespace
Lada: use augment instead of grouping with an artifical target to define
namespace Phil Shafer: misusing grouping is wrong. I guess we would be upset
when seeing somebody to use groupings this way. Andy: We use it as a schema
language for defining both XML and JSON content. Balazs: Dont use data nodes in
a magic way, that might disturb tools. Methem: Take it to the list. Andy:
deviations as they are are flawed Restconf session monitoring Kent: I think we
do have sessions. TLS defines the session. Monitor it Andy: We dont have
sesions, no locks. Kent: We should have RESTCONF session and correlate it to
the TLS session. Bert: Issue #2 should be taken to the list. Added collection:
Lada: can I avoid the collection in the JSON encoding? Andy: In some cases
Lada: If a client only wants yang data, but no collection Phil: the collection
doesnt show up in xml? Andy: we want the similar encoding in the two Lada: I am
not against comparable encoding for collection media type, my question is
whether a JSON client can ask for application/yang.data and receive the entire
list. Andy: do we agree to advertise with-defaults basic mode? seems yes Phil:
a restconf server must implement rfc6243 which is optional? Andy: we dont have
a way to advertise Kent: we should make it Andy: we could define a query
parameter for with-defaults Andy: Using http 1.1 mark it as SHOULD: no
objection agreed

Bert: Post mail per issue to mailing list

Zero touch - Ken
----------------
Mikael: There is currently a lot of work going on about bootstraping,
also in anima. Anima is a WG now.
Mehmet: If anima has specific requirements towards zerotouch, they should state
them Dean B.: I proposed to anima to use the zerotouch draft. We should have
just one RFC. (there is a third one as well). Brian Carpenter: another overlap
with homenet. Anima does not want Netconf, so the solution should not be
netconf dependent. Mehmet: lets take it offline.

Chair: Are the virtual interims good?
Balazs, Andy, Dean B. Yes we want it. It speeds up work.
Mehmet: we need more participation
We could use doodle to find the corerct time.
Benoit: The question should be whether work is being done in virtual meetings.
Mehmet: We need minutes.
Benoit: virtual meetings have overhead. We need the a fixed timeslot.
Mehmet: If only the authors are attending, it is not enough, and then
we dont need to make offical virtual interims.
Benoit: Lets fix slots. people will get used to it, we need to sped up.
Jeff H.: virtuals are good for developing I-Ds. Actual work is
done. Don't worry about participation.

Ephemeral State - Jeff Hass
---------------------------
Dean B.: I recommended restconf for I2RS, not netconf because RESTCONF
has unified datastore, that is, only one state you need to read and
change. Candidate config in ephemeral is difficult, as you only have
one state of the device.
Jeff: we already have a private solution
Benoit: What does peer-mount have to do with ephemeral state?
Jeff H: peer-mount has easier use-cases for people to understand. It
will push you to solve some of the i2rs problems. They have better
documentation.
Eric Voit: Are some issues are urgent?
Mehmet: Is anybody interested in this discussion? (Several people
indicated interest.)

Persistent replies - Mahesh
---------------------------
Mahesh: juergen proposed to solve this at the rpc layer.
Andy: This is confusing. Message-id comes from the client. How does
the server come up with a new message-id?
Phil: Why does this have to be solved? We can use start-task and
stop-task.
Balazs: We have the same problem. IMHO there is no solution
today. Multiple replies have to be linked somehow.
Mahesh: working with overalpping draft to merge
Mehmet: the details of linking are not for discussion today

Data fragmentation - Bing
-------------------------
Andy: Two problems: (1) GET request was sent and the client wants to
stop the ongoing reply. (2) Blind chunking is not enough. Operators
wnat to operate over well-defined chunks.
Balazs: Simple Chunking is already done in SSH encoding.
Balazs: Get-block is interesting but it solves only half of the
problem. We need a solution for RPC/actions .
Phil: We want RPC parameters to say "start here" and "go that far".
Bing: We try to send a complete instance each time.

Virtual Meetings:
-----------------
- The WG will continue with virtual meetings.
- In the first meeting we will discuss I2RS ephemeral state.
- Action item: Mehmet to send out a new doodle poll to chose the best time for
all.

Potential requirements on zerotouch from ANIMA WG:
--------------------------------------------------
Action item: WG chairs to communicate with ANIMA WG co-chairs that they must
agree on requirements and provide a draft to NETCONF WG.

Mehmet: there will be virtual meetings