Presentation is loading. Please wait.

Presentation is loading. Please wait.

IETF #84 - NETCONF WG session 1 NETCONF WG IETF 84, Vancouver, Canada MONDAY, July 30, 2012 1540-1710 Bert Wijnen Mehmet Ersue.

Similar presentations


Presentation on theme: "IETF #84 - NETCONF WG session 1 NETCONF WG IETF 84, Vancouver, Canada MONDAY, July 30, 2012 1540-1710 Bert Wijnen Mehmet Ersue."— Presentation transcript:

1 IETF #84 - NETCONF WG session 1 NETCONF WG IETF 84, Vancouver, Canada MONDAY, July 30, 2012 1540-1710 Bert Wijnen Mehmet Ersue

2 2 Before we can start... We need: 2 minute takers 1 Jabber scribe IETF #84 - NETCONF WG session

3 Note Well Any submission to the IETF intended by the Contributor for publication as all or part of an IETF Internet- Draft or RFC and any statement made within the context of an IETF activity is considered an "IETF Contribution". Such statements include oral statements in IETF sessions, as well as written and electronic communications made at any time or place, which are addressed to: * The IETF plenary session * The IESG, or any member thereof on behalf of the IESG * Any IETF mailing list, including the IETF list itself, any working group or design team list, or any other list functioning under IETF auspices * Any IETF working group or portion thereof * The IAB or any member thereof on behalf of the IAB * The RFC Editor or the Internet-Drafts function All IETF Contributions are subject to the rules of RFC 5378 and RFC 3979 (updated by RFC 4879). Statements made outside of an IETF session, mailing list or other function, that are clearly not intended to be input to an IETF activity, group or function, are not IETF Contributions in the context of this notice. Please consult RFC 5378 and RFC 3979 for details. A participant in any IETF activity is deemed to accept all IETF rules of process, as documented in Best Current Practices RFCs and IESG Statements. A participant in any IETF activity acknowledges that written, audio and video records of meetings may be made and may be available to the public. July 30, 2012 1540-1710 Afternoon Session II

4 4 Agenda Agenda bashing (2 min) WG status review (5 min) Charter-item-to-be: 1. NETCONF Over TLS update - RFC 5539bis - M. Badra (5 min.) http://tools.ietf.org/html/draft-badra-netconf-rfc5539bis http://tools.ietf.org/html/draft-badra-netconf-rfc5539bis 2. NETCONF Light - Kent Watsen (10 min.) http://tools.ietf.org/html/draft-schoenw-netconf-light http://tools.ietf.org/html/draft-schoenw-netconf-light 3. Yangifying RFC 5277 - NETCONF Event Notifications - A. Bierman (5 min.) 4. NETCONF over BEEP and NETCONF over SOAP to historic - Bert&Mehmet (5 min) http://www.ietf.org/mail- archive/web/netconf/current/msg07278.htmlhttp://www.ietf.org/mail- archive/web/netconf/current/msg07278.html IETF #84 - NETCONF WG session

5 5 Agenda (ctd.) Rechartering: 1. NETCONF Rechartering - Bert & Mehmet (15 min.) http://www.ietf.org/proceedings/84/slides/slides-84-netconf-5.txt http://www.ietf.org/proceedings/84/slides/slides-84-netconf-5.txt Non-chartered items: 1. NETCONF over WebSocket - T. Iijima (10 min.) http://tools.ietf.org/html/draft-iijima-netconf-websocket-ps http://tools.ietf.org/html/draft-iijima-netconf-websocket-ps 2. REST API vs. YANG-API - A. Biermann - A. Bierman (15 min.) 3. NETCONF issues for YANG Conformance - A. Bierman (10 min.) IETF #84 - NETCONF WG session

6 6 WG Status (since Paris) We were lazy and chatty:  Long discussions on the Netconf-Light document, whether it should be developed as Netconf 2.0, 1.2 or seperate.  The WG obviously does not want a Netconf 2.0 or 1.2.  The last discussion shows that the WG rather would like to advance the Netconf standard to the next level.  Based on this the co-chairs prepared a draft charter proposal and asked for comments.  The draft charter proposal to be discussed today. IETF #84 - NETCONF WG session

7 7 Charter Proposal (excerpt) In the current phase of the incremental development of NETCONF the workgroup will focus on following items: 1. Advance NETCONF over TLS to be in-line with NETCONF 1:1. This means that RFC5593 needs to be updated. 2. To enable an implementation with a reduced code-size there seems to be a need for a modular NETCONF solution (Netconf-Lite), which can be used e.g. for an incremental deployment or in constrained devices with less memory. Netconf-Light does not aim to address new operational needs of constrained devices currently discussed in the Coman activity. The WG will create a document defining the minimal base of features for such a standard. 3. RFC5277 (Netconf Event Notifications) was written before the YANG modeling language existed. The WG will "YANGify" that RFC, so that we have a proper YANG module for the Netconf Event Notifications. 4. Based on the implementation and deployment experience, the WG will document the status of NETCONF in order to advance the base documents (at least RFC6241 and RFC6241) on the standards track. IETF #84 - NETCONF WG session

8 8 Open mic/AOB Open mike AOB? IETF #84 - NETCONF WG session


Download ppt "IETF #84 - NETCONF WG session 1 NETCONF WG IETF 84, Vancouver, Canada MONDAY, July 30, 2012 1540-1710 Bert Wijnen Mehmet Ersue."

Similar presentations


Ads by Google