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

*** NETCONF meeting [2013-11-04 Mon]

**** NETCONF over TLS (Jürgen)
http://www.ietf.org/proceedings/88/slides/slides-88-netconf-0.pdf

***** slide 3
Kent: it could be a deployment specific-port, so it needn't be registered, it
also has no impact on zerootuch configuration. Kent: Maybe option without a new
port. The device is already configured with address/FQDN address, why not
configure a port as well? Martin B: That works. But this is not the same
service as Netconf. Separate port needed Mikael Abrahamsson: quickest way to
have port included in the draft and leave it to other WG to decide MAbrmson:
Should be discussed in TLS/SSH WGs.  Wants this quickly include port, if thats
not good go to other WG. Mehmet: We are not changing TLS, so it needs be
discussed here Andy: agree w Mikael, it's not an operator's choice but rather
the vendor's Andy: We are not TLS experts. Are there any standard protocols
without a port assignment. Port will be a vendor choice, not an operator
choice. I dont see a point not to chose a port Juergen: NETCONF protocol starts
only after all auth etc. is done, and cannot change anything. Juergen: Netconf
can not establish the port. Mehmet: To have a secure solution Lisa Huang: agree
w Andy Lisa Huang: Should be vendor Diego Lopez: Is there a way for discovery
announcement? You have to start a different transport mechanism - is it
discovery or negotiation? ??: PCP inside TLS similar situation. You don't need
a fix port if you have this in a directory mechanism. If you don’t have that
fix port is good. Benoit: support allocation; as A-D: we should discuss it with
Joe Touch. Benoit: cleaner to have a port. This is callhome only for Netconf,
not a generic. Is Joe a contributor or expert reviewer We should discuss with
Joe, but I believe have a new port Mehmet: mailing list wanted new port, as
this is just for Netconf Question: who wants new port: yes ca. 30, 0 against
Sense of the room: allocate a new port ***** slide 4 Kent: in Reverse Ssh it's
a list of applications that comes first, within each there is a list of
servers, reconnect strategy, sticky connection Strategy, always first server,
or always last connected server Mikael: Is it implicitly TCP? Jürgen: Yes.
Mikael: So it should be mentioned. michael: put in transport, as later sctp,
etc. migh come Martin: Did you consider unifying the data model with rev ssh?
This would be useful. Martin B: did you consider same structre, but also use
the exact same list. Why have it separately Jürgen: We could actually extract
it out and make call home independent of transport. Jurgen: there could be
differences, having a common module would need to split it out into a separate
draft. Do we want to do it? Kent: It would be nice to have just one document:
call home Jürgen: That would actually be much easier for readers. Jurgen:
transport specific separate documents is a good idea Andy: agree with Martin,
similar objects, no need for separate modules, special objects can be
augmented. Andy: use groupins to avoid copy paste. Separate documents with
references enough. Put the stuff into the netconf tree Mehmet: separate
documents or one doc with the module? Mehmet: Yang module in separate document
better then dependencies Martin: support 2 docs for TLS and SSH, extra doc for
the module. Martin: YANG module in separate document

***** slide 5
Kent: reminds me of conditional enablement
kent: enable button. this follows the conditional enabblement draft
Martin: there is already "enable" button in rev ssh?
Martin: agree with kent, enable is needed all over the space
Mrtin: prefers conditional enablement, but accepts button
kent: is it too late for conditional enablement, thinks no
Jürgen: I'd like to have it done rather than wait on a new doc.
Jurgen: timing issue, doesnt want to wait
Jurgen: Reconnect is it OK
Martin: same reconnect strategy - it could be simple but extensible.
Kent: we have round-robin strategy, assumes persistent connection strategy.
Kent: what we need to configure - NMS public key, NMS has to authenticate the
server first. Provisioning server is one set of credentials, the other server
may need another set of credentials. kent: this is what we use at juniper,
operational experince says this is OK. details on reconnect strategy Martin:
strategies need a better explanation Jurgen: What to configre Kent: SSH public
key is configure per application per server Michael: yes key needs configured.
Strict checking of server needed. Hostkey might be communicated out-of-band. it
could be multiple certs on the device, this needs to be extensible. This is
complex. I could help Kent: for SSH, after you get past tunnel establishment,
it's username and pw, it could also be hash password, or public key can be
used. Kent: standard TLS crypto setup. For SSH authentication credentials:
public key RSA X.509, hashed password, etc.

**** Reverse SSH (Kent)
http://www.ietf.org/proceedings/88/slides/slides-88-netconf-1.pptx

***** slide 9
Mehmet: pay attention to the IPR statement
Mehmet: IPR seems to use standard licensing terms.
Andy: one issue - does it cover entire spec or only portions?
Andy: is the RAND o ly valid for the mandatory perts or does it cover the
entire spec. Kent: entire spec, AFAIK Kent: Juniper document does not
differentiate between mandatory and optional parts. Dan R. You should ask your
legal department Wes Hardaker: What is actually covered by the patent? Dan R.
Dont discuss patents in IETF meetings Kent: patent cover reserve SSH. Cleartext
messae sent about identity, covered by HMAC. It is for reserve SSH, but not
exactly this solution Patent number is in IPR. K: TCP connection is
established, then a cleartext exchange takes place. David Lamparter: it must
cover the whole thing. ???: IPR text mentions "what is needed for spec"...
Martin: is this really applicable Kent: believe yes, read IPR Dan R. Should not
discuss content of patents here. Read patent. Disclosure happened. Karl Moberg:
Would Juniper revoke the patent if needed? Kent never heard about such thing
Kent: we have implementation. It goes through opensource and legal review,
hopes to post it under apache license for reading or reusing. Mehmet: next
steps? Kent: some clarifications, then work with Juergen on a common YANG
module Kent: One comment plus extracting the common YANG module.

**** Zerotouch Provisioning (Kent)
http://www.ietf.org/proceedings/88/slides/slides-88-netconf-1.pptx

***** slide 8
Andy: access control list needed. you want to block malicios attempts.
kent: we want to support the usecase where the connection comes from outside
Andy: in order to block normal netconf requests while allowing call home, we
need a separate port Andy: this is why I asked about access control list, the
service provider may not want to have that traffic Kent: agree Diego:
Certificate can be an option, but not the only option. ??: checking that the
device authorized. Is this the only way to authorizing the device Kent: Any
unique identifier will work, serial numbers are ubiquitous. Kent: identity we
recomend erial number, but any universal unique ID would work, but serial
number is intuitive Diego: I am just questioning the precondition of security
chip. ??: I am just asking if other mechanisms could also be used. This is one
possibility Kent: Devices may be allowed to use another identifier. Kent: the
choice of identifier=serialno is vendor specific as long as NMS agrees. But
Others could be used. I will still recomend serialno. ***** slide 9 Kent:
ipersonate DNS is sketc Russ Mundy: private DNSSEC will work. ??: role over
time is not specified any spec. It should work Michael: Private net will not
have the public signing keys. So you need to provide the other keys. Do we need
all this in one dratf? This is a big topic. If the device is on the shelf too
long, DNSsec keys may role over Michael: Should this be one draft or multiple
drafts? We have different mechanisms. Kent: In OPS there was another draft
outlining the diff solutions. We'd like to have a universal solution. Kent:
opsarea there was a draft to outline many solution, but people did not realize
why it was good? Here we are going for a specific solution. Michael Behringer:
What's the name of the ops draft? Kent: Don't remember, will send to the list.
Jurgen: I will send it to the mailing list Rüdiger Volk: proposing DT(?) cards
Ian Farrel: [ missed his point ] ??: Why do you want to put tyour credentials
into the device? Why not just plugin? Offers flexibility, same ease of use,
better security, as Kent: fair question. Flash drive or near field radio may be
used. We could use an HTTP server. ??: problem that this depend of vendor.
Vendors might collapse, they effectively control the operator network to some
degree Martin: does not have to be the vendor, any 3rd party can be Martin:
DNSSEC - it needn't be the vendor who provides DNSSEC Kent: the server can be
someone else, but the vendor manufactures the needed parts Wes: even if the
vendor dies, the device is usable, just no zero conf works Mehmet: what's being
proposed - adopt or clarify open issues first? Kent: Joe Clarke, plus comments
here should be included. But we want to check interest Mikael: support the
problem description, even willing to work on this. Dan: Do you mean an
alternative proposal? Michael: yes, we are willing to provide an DHCP approach.
I am not against it. Mikael: Yes, have an alternative solution via DHCP. Kent:
We did DHCP, too, but found it insufficient. Kent: we also have a DHCP
approach, but as it does not work in some cases we went for this Martin: Both
solutions are complementary. Kent: DHCP is an laternative even in this
document, but I fear this opens up an attack possibilities Mehmet: Go to
mailing list, there is interest.

**** RESTCONF (Andy)
http://www.ietf.org/proceedings/88/slides/slides-88-netconf-3.pdf

***** slide 14
Carl: You define all sorts of new things on 75 pages, some features are
arguably not RESTful, so I can't see the purported benefit of reusing existing
technologies. KarlM: Restconf is already 75 pages over http/libcurl. Andy: this
is what rest is missing. schema language KarlM: do you want to fix it here?
Andy: This is a specific solution for YANG and Rest combination. Customers like
it. KarlM: Libcl or JSON tools dont understand YANG Andy: its OK. libcrl does
not need that KarlM. Lacking precise definition of what we try to do Andy: dont
agree. provide rest access to YANG server KarlM with a lot of extensions Andy
not many stuff KarlM: this is not that easy. 75 pages to learn. Andy: You can
use simple patch instead of yangpatch Needs cross area review DanR: Why here?
Why in this WG? This will slow down netconf adaptation. This is a different
protocol. You have a lot of experrtise, but a lot of resstance Andy: has been
DanR: Wny not new WG Andy Area directors/WG chairs sad do it here, to have this
aligned Unified management means one model not one protocol. Naming and
semantics should be the same. protocols will always be different. YANG is the
key. Maybe it should be in the same WG DanR: another WG would be better Mehmet:
History: a new WG and a BOF was proposed. It is different from Netconf, but
based on Netconf. Keep them aligned. Second option for Netconf. Dan: Does this
work belong to this WG or another? Lada: It is actually valuable to combine
REST concepts with the YANG model schema. But in order to make the RESTCONF
document shorter, the definition of Yang Patch should be in a separate
document. Lhotka: I like it. YANG as a base is good. Andy: Without YANG
modules, management does nto work. Vendors are doing fancy stuff with YANG
already. Lhotka: Maybe we can use JSON patch Andy: JSON patch not schema based
Jan Medved: Support it, we implemented in OpenDaylight. We need it, we have
done it anyway, so we are have to have it, many proprietary solutions will
appear otherwise. Scott Bright: agree with this. One data model is not
realistic. Scott Whyte: there is no single schema, vendors have their
extensions. Andy: I don’t mean one yang model, everyone defines it. One per
device, augmented standard. Naming is a problem. that's why we have the augment
statement, one model means one model per server, consisting of multiple YANG
modules. Scott: different formats. Andy: same data on cli, netconf, webui,
restconf. Any protocol changes the same Lianshu Zheng (?): support chinese ??:
we are implementing this. We like it. Andy: people dont want to use netconf for
notificatios as it keeps the connections up, as restconf. Kent: Juniper
supports this and implements this. mehmet closes the line Do you want this
adopted Andy: I want this adopted. I want to see the consensus. Who wants this
in Netconf WG aligned: 25 No one against Mehmet: I see a lot of interest.
People want it to do in the Netconf WG. Benoit, will you support it in the
charter? Benoit: alignment is important, new charter needed. Opendaylight
requires it that is important as a customer. Mehmet: New charter ??: do it fast
as multiple implementation might branch Lhotka: draft is dependent on the JSON
draft. Lhotka: this draft should go together with the JSON draft. Andy: the
JSON encoding must follow Lada's draft Kent: Juniper is also looking into this.
Tina Tsou: Can somebody present RESTCONF at ONF NBI summit?

**** NETCONF Efficiency Extensions (Andy)
http://www.ietf.org/proceedings/88/slides/slides-88-netconf-4.pdf

??: like it, are notifications in scope?
Scott Whyte: You don't address notifications.
Andy: Customers want an SNMP type notification. Customers don’t even need
security always. Mehmet: Discuss case by case or as a package. ANdy: mailing
list debate Martin: support this. This is not just efficiency. It is usability
as well. Who supports 15, Against: 0 Andy: this does not breaks anything,
backwards compatibility. Mehmet: raise discusssion on mailing list.

**** NETCONF DHCPv6 Options (Mikael)
http://www.ietf.org/proceedings/88/slides/slides-88-netconf-5.pdf

Want to use it for all types of boxes
Dan: Should this be in NETCONF or DHCP WG?
Mikael: This is about bootstrapping NETCONF, so it belongs to this WG, but
should also be reviewed by DHCP WG. Mehmet: Who wants it: 10, against 1 Andy:
This should be combined with Kent's work. Kent: +1

**** Update on OpenDaylight (Jan Medved)
http://www.ietf.org/proceedings/88/slides/slides-88-netconf-6.pptx

YANG models used in adaptation layer. RestConf is automatically redering APIs.
Zero touch This looks like an NMS, handles the full network not just one ME.
access control to data Need RstConf JSON encoding binary encoding optimisation
Query language, a more precise query possibility I2RS (maybe netconf) YANG ODL
extensions (request touring, JavaApiGeneration, remoteMounting) YANG programing
language bindings, how to create APIs from YANG (Java, Pyton) Possible remote
library Standard service models: VPN, DDOS, QoS, Topology, IP, ACL, RIB
WADL/RSDL from YANG? for RestConf clients YANG as an interface description
language Carl: Any special protocol in mind for the API generation? KarlM. What
protocol for the language bindings Jan M: We dont care about protocol KarlM.
The protocol will show up in the API JanM Netconf or RestConf Jan: Essentially
NETCONF. Ole : What about locking? ??: Distributed locking needs to be solved
JanM: Both, it is in the codebase Jan: Locking is really a nightmare in a
distributed syastem. Benoit:  Restconf NBI or SBI?

Benoit: Will RESTCONF be implemented?
Jan: Yes.
JanM: Both, it is in the codebase
Edward Crabbe: Are your suggestions future action items for NETCONF of YANG
groups? ??: Who should standardize it? Which WG? Jan: General models should be
done ny NETMOD, the rest probably by OpenDaylight. JanM Netconf, Netmod? Zhen
Cao: In the diagram, are the applications aware of which network element a
request is directed to? Jan: No, on purpose. DanR: We encourage other areas to
develop their own models JanM: extensions and program bindings Netmod/Netconf
??: Are the NBI transprent to the SBI JanM: yes, the NBI user does not know
which SBI used DanR: This is a lot of work. We need to identify elements that
are for this WG, YANG WG, but other elements (models) might go to routing area.
Dan: We have to identify elements that are important for this WG. JanM: we need
Restconf/Json?Binary encoding Efficiency is also wanted. Extensions to Netmod
Martin: are you asking for more complicated quesries or better filtering
Martin: What do you mean by queries? Jan: Queries that are more complicated
that XPath, mainly for filtering. JanM Both Mehmet: Are you available for
additional discussion? Jan: Absolutely. JanM available for additional
discussions.