Slides 92 Netconf 5

NETCONF
Server and RESTCONF Server

Configura4on Models

dra8-‐ie;-‐netconf-‐server-‐model-‐06

NETCONF WG
IETF #92 Dallas, TX, USA

Updates since IETF 90
•  Removed YANG 1.1 style if-‐feature statements

•  Removed the read-‐only lists of SSH host-‐keys and TLS certs
•  Added ability to configure trust-‐anchors for SSH X.509 client certs
•  Now imports by revision, per best prac4ce (?)
•  Added support for RESTCONF server
•  Added RFC Editor instruc4ons
•  Added NACM statements to YANG modules for sensi4ve nodes
•  Added client-‐cert-‐auth subtree to ie;-‐restconf-‐server module
•  Added descrip4on for braces to tree diagram sec4on
•  Renamed feature from "rfc6187" to "ssh-‐x509-‐certs"
2
Last Call Results
•  Model changes needed

•  Some editorial clarifica4ons needed

3
Open Issues

hbps://github.com/netconf-‐wg/server-‐model/issues
4
#32: rename "applica4on" node name to "netconf-‐client”?
•  Current: module: ietf-netconf-server!

+--rw netconf-server!
+--rw call-home {call-home}?!
+--rw application* [name]!
+--rw ssh!
+--rw endpoints!
+--rw endpoint* [name]!
...!
•  Proposed: module: ietf-netconf-server!

+--rw call-home {call-home}?!
+--rw netconf-client* [name]!
+--rw ssh!
+--rw endpoints!
+--rw endpoint* [name]!
...!
5
#33: Is it a good idea to name the top-‐level
node "netconf-‐server"?
•  Is this name consistent with how we name other things?

–  what might be beber?
–  FWIW, RFC 6022 has "netconf-‐state”
•  Example using current naming strategy:
<netconf-server !
xmlns="urn:ietf:params:xml:ns:yang:ietf-netconf-server">!
<session-options>...</session-options>!
<listen>...</listen>!
!
<call-home>...</call-home>!
<ssh>...</ssh>!
</netconf-server>!
6
#34: Are the current features granular enough?
•  For NETCONF only, it’s not possible to adver4se being

able to listen for just SSH and call-‐home with just TLS
+--rw listen {listen}?!
| +--rw endpoint* [name]!
| +--rw (transport)!
YANG 1.1’s new if-‐
| +--:(ssh) {ssh}?!
| +--:(tls) {tls}?!
feature syntax was
+--rw call-home {call-home}?! designed to support
| +--rw application* [name]! this case, but can’t
| +--rw (transport)! use because 6020bis
| +--:(ssh) {ssh}?! isn’t stable yet…
| +--:(tls) {tls}?!
+--rw ssh {ssh}?!
...!
+--rw tls {tls}?!
...!
7
#36: is import by revision needed?
•  At the 4me I submibed this dra8, it was my understanding that
import by revision was best prac4ce, and that prior YANG
modules were in viola4on.
•  Recent YANG 1.1 conformance discussions seem to be swinging

the other direc4on now, but with poten4al to swing back again.
•  Unclear what the right thing to do is !
•  Perhaps taking it out is the way to go because, even if it's wrong,
it will at least be in the company of other published modules ;)
8
#38: remove upper-‐bound on hello-‐4meout,
idle-‐4meout, and max-‐sessions?
leaf hello-timeout {!
type uint32 {!
range "0 | 10 .. 3600";!
}!
units "seconds";!
}!
!
leaf idle-timeout {!
type uint32 {!
range "0 | 10 .. 360000";!
}!
units "seconds";!
}!
!
leaf max-sessions {!
type uint16 {!
range "0 .. 1024";!
}!
}!
9
#39: move away from a number with a fixed unit?
•  Removing upper-‐bounds is well and good, but large

values can become unreadable:
–  Example: 3 days or 259,200 seconds?
•  How about a 2-‐tuple?

–  One leaf for a numerical value
–  One leaf for an enum [secs, mins, hours, days, etc.]
•  Or something like a XSD’s “dura4on”?

–  Example: PnYnMnDTnHnMnS
10
#40: move "max-‐sessions" to global session-‐param?
•  Currently under the “listen” leaf
•  If moved to global level, how to catch if configured

number of call-‐homes exceed the value?
•  Can an must statement catch this?

–  count(/call-‐home/applica4on) <= /session-‐op4ons/max-‐sessions
11
#41: should address be mandatory?
•  Currently, neither address nor port are
mandatory for a listening endpoint
–  but port has a default
•  should address be mandatory

–  or should no specified address be treated as a
wildcard?
12
#43: keep-‐alive, linger, reconnect
interval defaults OK?
•  …/connec4on-‐type/persistent/keep-‐alives/interval-‐secs:
–  15 seconds
•  …/connec4on-‐type/periodic/linger-‐secs:
–  30 seconds
•  …/reconnect-‐strategy/interval-‐secs:
–  5 minutes
13
#45: how do interval-‐secs and count-‐max work for reconnect-‐
strategy if an endpoint resolves to mul4ple IP addresses?
•  E.g., let's say an applica4on has 3 endpoints

–  name1, name2, and name3
•  And each expands into two IP addresses:

–  {ip1.1, ip1.2}, {ip2.1, ip2.2}, {ip3.1, ip3.2}
•  Proposal: treat as if IPs were configured explicitly

–  E.g., ip1.1 à ip1.2 à ip2.1 à ip2.2 à ip3.1 à ip3.2
14
#46: move "peer_allowed_to_send" to CH dra8?
•  Currently Call Home dra8 says nothing about keep alives!

–  It should say “Servers SHOULD send keep-‐alives…”
•  But in order to do so, TLS [RFC 6520] requires the client to
adver4se "peer_allowed_to_send”
–  Thus we also need “Clients MUST adver4se "peer_allowed_to_send"
•  Proposal: move en4re Sec4on 5 to Call Home dra8

–  Sec4on 5: Implementa4on strategy for keep-‐alives
•  Covers both SSH and TLS keep-‐alives
15
#47: introduce a 2nd 4meout for periodic
connec4ons for when there's data to send?
•  Current text says that a device SHOULD pro-‐ac4vely

connect to the client if it has messages to send
•  Op4ons:
1.  Leave as it is
2.  have another configurable 4mer (less than periodic
interval) for how long device should wait?
3.  Or an absolute 4me (e.g., 2:00am) ?
16
#49: combine trusted-‐ca-‐certs and
trusted-‐client-‐certs for ssh/tls?
•  Current text has separate lists for configuring trusted CA-‐certs
and client-‐certs for SSH and TLS
•  There doesn’t seem to be a Security reason for why these are
separate
•  Would like to combine, but how to set if-‐feature statement?
•  Ideally would use YANG 1.1 if-‐feature syntax

–  if-‐feature “(ssh-‐x509-‐certs or tls)”;
•  Create feature called “ssh-‐x509-‐or-‐tls”?

17
Next Steps
•  Another Last Call will be necessary
18
Thank you
19

Slides 92 Netconf 5

Uploaded by

Copyright:

Available Formats

Slides 92 Netconf 5

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Slides 92 Netconf 5

Uploaded by

Copyright:

Available Formats

NETCONF

Server and RESTCONF Server

• Removed YANG 1.1 style if-­‐feature statements

• Model changes needed

• Current: module: ietf-netconf-server!

• Proposed: module: ietf-netconf-server!

• Is this name consistent with how we name other things?

• Example using current naming strategy:

• For NETCONF only, it’s not possible to adver4se being

• Recent YANG 1.1 conformance discussions seem to be swinging

• Unclear what the right thing to do is !

• Removing upper-­‐bounds is well and good, but large

• How about a 2-­‐tuple?

• Or something like a XSD’s “dura4on”?

• Currently under the “listen” leaf

• If moved to global level, how to catch if conﬁgured

• Can an must statement catch this?

• should address be mandatory

• E.g., let's say an applica4on has 3 endpoints

• And each expands into two IP addresses:

• Proposal: treat as if IPs were conﬁgured explicitly

• Currently Call Home dra8 says nothing about keep alives!

• Proposal: move en4re Sec4on 5 to Call Home dra8

• Current text says that a device SHOULD pro-­‐ac4vely

• Ideally would use YANG 1.1 if-­‐feature syntax

• Create feature called “ssh-­‐x509-­‐or-­‐tls”?

• Another Last Call will be necessary

You might also like

•  Removed YANG 1.1 style if-‐feature statements

•  Model changes needed

•  Current: module: ietf-netconf-server!

•  Proposed: module: ietf-netconf-server!

•  Is this name consistent with how we name other things?

•  Example using current naming strategy:

•  For NETCONF only, it’s not possible to adver4se being

•  Recent YANG 1.1 conformance discussions seem to be swinging

•  Unclear what the right thing to do is !

•  Removing upper-‐bounds is well and good, but large

•  How about a 2-‐tuple?

•  Or something like a XSD’s “dura4on”?

•  Currently under the “listen” leaf

•  If moved to global level, how to catch if conﬁgured

•  Can an must statement catch this?

•  should address be mandatory

•  E.g., let's say an applica4on has 3 endpoints

•  And each expands into two IP addresses:

•  Proposal: treat as if IPs were conﬁgured explicitly

•  Currently Call Home dra8 says nothing about keep alives!

•  Proposal: move en4re Sec4on 5 to Call Home dra8

•  Current text says that a device SHOULD pro-‐ac4vely

•  Ideally would use YANG 1.1 if-‐feature syntax

•  Create feature called “ssh-‐x509-‐or-‐tls”?

•  Another Last Call will be necessary