idnits 2.17.1
draft-liu-netmod-yang-schedule-04.txt:
Checking boilerplate required by RFC 5378 and the IETF Trust (see
https://trustee.ietf.org/license-info):
----------------------------------------------------------------------------
No issues found here.
Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt:
----------------------------------------------------------------------------
No issues found here.
Checking nits according to https://www.ietf.org/id-info/checklist :
----------------------------------------------------------------------------
No issues found here.
Miscellaneous warnings:
----------------------------------------------------------------------------
== The copyright year in the IETF Trust and authors Copyright Line does not
match the current year
== Line 163 has weird spacing: '...eration ope...'
== The document seems to lack the recommended RFC 2119 boilerplate, even if
it appears to use RFC 2119 keywords.
(The document does seem to have the reference to RFC 2119 which the
ID-Checklist requires).
-- The document date (September 6, 2017) is 2423 days in the past. Is this
intentional?
Checking references for intended status: Proposed Standard
----------------------------------------------------------------------------
(See RFCs 3967 and 4897 for information about using normative references
to lower-maturity documents in RFCs)
== Missing Reference: 'RFC3688' is mentioned on line 594, but not defined
== Missing Reference: 'RFC6242' is mentioned on line 618, but not defined
== Missing Reference: 'RFC6536' is mentioned on line 618, but not defined
** Obsolete undefined reference: RFC 6536 (Obsoleted by RFC 8341)
== Unused Reference: 'RFC6021' is defined on line 673, but no explicit
reference was found in the text
== Unused Reference: 'RFC6087' is defined on line 717, but no explicit
reference was found in the text
-- Possible downref: Non-RFC (?) normative reference: ref. 'IEEE1588'
** Obsolete normative reference: RFC 6021 (Obsoleted by RFC 6991)
** Downref: Normative reference to an Informational RFC: RFC 7384
** Downref: Normative reference to an Informational RFC: RFC 7399
** Downref: Normative reference to an Experimental RFC: RFC 7758
== Outdated reference: A later version (-07) exists of
draft-birrane-dtn-ama-05
** Downref: Normative reference to an Informational draft:
draft-birrane-dtn-ama (ref. 'I-D.birrane-dtn-ama')
== Outdated reference: A later version (-26) exists of
draft-ietf-netconf-subscribed-notifications-03
== Outdated reference: A later version (-25) exists of
draft-ietf-netconf-yang-push-08
-- Obsolete informational reference (is this intentional?): RFC 6087
(Obsoleted by RFC 8407)
Summary: 6 errors (**), 0 flaws (~~), 11 warnings (==), 3 comments (--).
Run idnits with the --verbose option for more detailed information about
the items above.
--------------------------------------------------------------------------------
2 Network Working Group X. Liu
3 Internet-Draft Jabil
4 Intended status: Standards Track I. Bryskin
5 Expires: March 10, 2018 Huawei Technologies
6 V. Beeram
7 Juniper Networks
8 T. Saad
9 Cisco Systems Inc
10 H. Shah
11 Ciena
12 O. Gonzalez de Dios
13 Telefonica
14 September 6, 2017
16 A YANG Data Model for Configuration Scheduling
17 draft-liu-netmod-yang-schedule-04
19 Abstract
21 This document describes a data model for configuration scheduling.
23 Status of This Memo
25 This Internet-Draft is submitted in full conformance with the
26 provisions of BCP 78 and BCP 79.
28 Internet-Drafts are working documents of the Internet Engineering
29 Task Force (IETF). Note that other groups may also distribute
30 working documents as Internet-Drafts. The list of current Internet-
31 Drafts is at http://datatracker.ietf.org/drafts/current/.
33 Internet-Drafts are draft documents valid for a maximum of six months
34 and may be updated, replaced, or obsoleted by other documents at any
35 time. It is inappropriate to use Internet-Drafts as reference
36 material or to cite them other than as "work in progress."
38 This Internet-Draft will expire on March 10, 2018.
40 Copyright Notice
42 Copyright (c) 2017 IETF Trust and the persons identified as the
43 document authors. All rights reserved.
45 This document is subject to BCP 78 and the IETF Trust's Legal
46 Provisions Relating to IETF Documents
47 (http://trustee.ietf.org/license-info) in effect on the date of
48 publication of this document. Please review these documents
49 carefully, as they describe your rights and restrictions with respect
50 to this document. Code Components extracted from this document must
51 include Simplified BSD License text as described in Section 4.e of
52 the Trust Legal Provisions and are provided without warranty as
53 described in the Simplified BSD License.
55 Table of Contents
57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
58 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
59 2. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 3
60 3. Configuration Scheduling YANG Data Model Overview . . . . . . 3
61 4. Usage Example . . . . . . . . . . . . . . . . . . . . . . . . 4
62 5. Relations to Datastores . . . . . . . . . . . . . . . . . . . 6
63 5.1. Validation . . . . . . . . . . . . . . . . . . . . . . . 6
64 5.2. Schedules Expansion and Operational States . . . . . . . 7
65 5.3. Server Executions at Scheduled Moments . . . . . . . . . 7
66 5.4. Interactions with Locks . . . . . . . . . . . . . . . . . 7
67 5.5. Interactions with Authorization Mechanism . . . . . . . . 7
68 6. Synchronization Aspects . . . . . . . . . . . . . . . . . . . 7
69 7. Configuration Scheduling YANG Module . . . . . . . . . . . . 8
70 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
71 9. Security Considerations . . . . . . . . . . . . . . . . . . . 14
72 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 14
73 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 14
74 11.1. Normative References . . . . . . . . . . . . . . . . . . 14
75 11.2. Informative References . . . . . . . . . . . . . . . . . 16
76 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16
78 1. Introduction
80 This document introduces a YANG [RFC6020] [RFC7950] data model for
81 configuration scheduling. This model can be used together with other
82 YANG data models to specify a schedule applied on a configuration
83 data node, so that the configuration data can take effect according
84 to the schedule. Such a configuration schedule can be one-time or
85 recurring, with its properties persistently saved in the datastores
86 of the management system server.
88 The mechanism described in this document is designed to complement
89 the one described in [RFC7758], which defines a capability extension
90 to NETCONF to allow time-triggered RPCs. Such RPCs can be executed
91 at a future time moment, but cannot be repeated and is not saved in
92 the persistent datastores.
94 1.1. Terminology
96 The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
97 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
98 "OPTIONAL" in this document are to be interpreted as described in BCP
99 14, [RFC2119].
101 The following terms are defined in [RFC7950] and are not redefined
102 here:
104 o augment
106 o data model
108 o data node
110 2. Motivation
112 Some applications benefit from resource scheduling to allow operators
113 to plan ahead of time. Traffic engineering is one of such examples
114 [RFC7399]. When configuration and state models are designed for such
115 applications, it has been considered that certain data objects need
116 to be configured according to predefined schedules. In other
117 situations, operators need to deconfigure certain data objects at
118 predefined schedules for the purposes such as maintenance. These
119 data objects are interpreted and implemented by the applicable
120 applications.
122 Delay/Disruption Tolerant Networking (DTN) is another example for
123 which the scheduled configuration can be used, where a long-lived,
124 reliable, low-latency sequenced data delivery session is
125 unsustainable. Section 4.3 of [I-D.birrane-dtn-ama] describes the
126 Autonomous Parameterized Control. Time-based event is one of the two
127 types of triggers in such a system.
129 3. Configuration Scheduling YANG Data Model Overview
131 This document defines a YANG data model that specifies configuration
132 schedules for other YANG data models. For each targeted
133 configuration data object or a group of configuration data objects,
134 an entry is specified along with requested schedules using this
135 configuration schedule model. The application implementing the
136 targeted schema nodes implements the configuration schedules,
137 configuring or deconfiguring the specified objects according to the
138 specified schedules. The model schema of the targeted application
139 does not need changes, so the data model described in this document
140 can be used for any data model. The configuration scheduling YANG
141 data model has the following structure:
143 module: ietf-schedule
144 +--rw configuration-schedules
145 +--rw target* [object]
146 +--rw object yang:xpath1.0
147 +--rw operation? operation
148 +--rw data-value? anydata
149 +--rw schedules
150 | +--rw schedule* [schedule-id]
151 | +--rw schedule-id uint32
152 | +--rw inclusive-exclusive? enumeration
153 | +--rw start? yang:date-and-time
154 | +--rw schedule-duration? string
155 | +--rw repeat-interval? string
156 +--ro state
157 | +--ro future-executions
158 | +--ro execution* [start]
159 | +--ro start yang:date-and-time
160 | +--ro duration? string
161 | +--ro operation? operation
162 +---n execution
163 +---- operation operation
164 +---- datetime? yang:date-and-time
165 +---- results? anydata
167 4. Usage Example
169 The following model defines a list of TE (Traffic Engineering) links
170 which can be configured with specified schedules:
172 module: example
173 +--rw te-links
174 +--rw te-link* [id]
175 +--rw id string
176 +--rw enabled? boolean
178 The following configuration requests that
180 o link-1 is configured weekly for five one-day periods, starting
181 from 2016-09-12T23:20:50.52Z.
183 o link-2 is deconfigured for two hours, starting from 2016-09-
184 15T01:00:00.00Z.
186
187
188
189 configure
190
191
192 link-1
193 true
194
195
196
197
198 11
199 2016-09-12T23:20:50.52Z
200 P1D
201 R5/P1W
202
203
204
205
206
207 configure
208
209
210 link-2
211 true
212
213
214
215
216 12
217 exclusive
218 2016-09-15T01:00:00.00Z
219 P2H
220
221
222
223
225 The following configuration requests that
227 o link-1 is enabled weekly for five one-day periods, starting from
228 2016-09-12T23:20:50.52Z.
230 o link-2 is not enabled for two hours, starting from 2016-09-
231 15T01:00:00.00Z.
233
234
235
237 set
238 true
239
240
241 11
242 2016-09-12T23:20:50.52Z
243 P1D
244 R5/P1W
245
246
247
248
249
251 set
252 true
253
254
255 12
256 exclusive
257 2016-09-15T01:00:00.00Z
258 P2H
259
260
261
262
264 5. Relations to Datastores
266 NETCONF defines configuration datastores and operations that can be
267 used to access these datastores. The configuration data encoded
268 according to this data model is persistently saved in the proper
269 datastores in the same way as other data model, such as ietf-
270 interfaces.
272 5.1. Validation
274 When configuration data based on this model is received, the server
275 MUST perform syntax validations on the received data nodes, and
276 examine the requested schedules. The server does not validate
277 whether requested target configuration data can be applied to the
278 target configuration objects, until the actual scheduled time
279 arrives.
281 At each scheduled time moment, the server applies the requested
282 target configuration data to the target configuration objects. The
283 server MUST perform the validations on the target configuration data
284 along with the current target configuration objects in the proper
285 datastore.
287 5.2. Schedules Expansion and Operational States
289 The server SHOULD expand these schedules and expose them to the
290 client as operational states.
292 5.3. Server Executions at Scheduled Moments
294 At each scheduled time moment, the server applies the requested
295 target configuration data to the target configuration objects, as if
296 an RPC request is newly received. Whether such a time-triggered
297 configuration is successfully applied depends on the configuration
298 data of the target object and requested configuration data. The
299 results of such executions are sent to the client through
300 notifications. The notification management mechanism described in
301 [I-D.ietf-netconf-yang-push] and
302 [I-D.ietf-netconf-subscribed-notifications] can be used to enable,
303 disable, subscribe, filter, and replay the notifications.
305 5.4. Interactions with Locks
307 The rules of datastore lock specified by NETCONF [RFC6241] are
308 checked when the schedule configuration data is received and when the
309 target configuration data is applied.
311 5.5. Interactions with Authorization Mechanism
313 If the server implements any authorization mechanism, the
314 authorization rules MUST be checked against this data model schema
315 when the schedule configuration data is received. At each scheduled
316 time moment, the authorization rules MUST be checked against the
317 target objects by using the target configuration data. To check the
318 authorization rules, the server uses the same client credential
319 learned when the initial configuration data was received.
321 6. Synchronization Aspects
323 The scheduling mechanisms described in this document assume that
324 servers have access to the wall-clock time. Thus, servers are
325 required to acquire the time-of-day from an external time source, for
326 example using the Network Time Protocol [RFC5905], or the Precision
327 Time Protocol [IEEE1588].
329 It is assumed that the client and servers rely on a common time
330 source, so as to guarantee that schedules are defined with respect to
331 a common reference. In order to avoid the potential ambiguity of
332 different time zones and daylight saving time, it is recommended to
333 define all schedules in the UTC time zone, using the suffix 'Z'. For
334 example, the time 2016-09-12T23:20:50.52Z, is specified with respect
335 to the UTC time zone.
337 7. Configuration Scheduling YANG Module
339 file "ietf-schedule@2017-09-06.yang"
340 module ietf-schedule {
341 yang-version 1.1;
342 namespace "urn:ietf:params:xml:ns:yang:ietf-schedule";
344 prefix "sch";
346 import ietf-yang-types {
347 prefix "yang";
348 }
350 organization
351 "IETF NETMOD (NETCONF Data Modeling Language) Working Group";
352 contact
353 "WG Web:
354 WG List:
356 Editor: Xufeng Liu
357
359 Editor: Igor Bryskin
360
362 Editor: Vishnu Pavan Beeram
363
365 Editor: Tarek Saad
366
368 Editor: Himanshu Shah
369
371 Editor: Oscar Gonzalez De Dios
372 ";
374 description
375 "The model allows time scheduling parameters to be specified.";
377 revision 2017-09-06 {
378 description "Initial revision";
379 reference "TBD";
380 }
382 /*
383 * Typedefs
384 */
385 typedef operation {
386 type enumeration {
387 enum configure {
388 description
389 "Create the configuration data.";
390 }
391 enum deconfigure {
392 description
393 "Remove the configuration data.";
394 }
395 enum set {
396 description
397 "Set the specified configuration data.";
398 }
399 enum reset {
400 description
401 "Revert the specified configuration data back to the
402 original value.";
403 }
404 }
405 description "Operation type.";
406 }
408 /*
409 * Groupings
410 */
412 grouping schedule-config-attributes {
413 description
414 "A group of attributes for a schedule.";
416 leaf inclusive-exclusive {
417 type enumeration {
418 enum inclusive {
419 description
420 "The schedule element is inclusive, i.e., the schedule
421 specifies the time at which the element is enabled.";
423 }
424 enum exclusive {
425 description
426 "The schedule element is exclusive. i.e., the schedule
427 specifies the time at which the element is disabled.";
428 }
429 }
430 default "inclusive";
431 description
432 "Whether the list item is inclusive or exclusive.";
433 }
434 leaf start {
435 type yang:date-and-time;
436 description "Start time.";
437 }
438 leaf schedule-duration {
439 type string {
440 pattern
441 'P(\d+Y)?(\d+M)?(\d+W)?(\d+D)?T(\d+H)?(\d+M)?(\d+S)?';
442 }
443 description "Schedule duration in ISO 8601 format.";
444 }
445 leaf repeat-interval {
446 type string {
447 pattern
448 'R\d*/P(\d+Y)?(\d+M)?(\d+W)?(\d+D)?T(\d+H)?(\d+M)?'
449 + '(\d+S)?';
450 }
451 description "Repeat interval in ISO 8601 format.";
452 }
453 } // schedule-config-attributes
455 grouping schedule-config-notification {
456 description
457 "A group of attributes for a schedule notification.";
459 notification execution {
460 description
461 "Notification event for an execution performed on a target
462 object.";
463 leaf operation {
464 type operation;
465 mandatory true;
466 description "Operation type.";
467 }
468 leaf datetime {
469 type yang:date-and-time;
470 description
471 "The date and time when the execution was performed.";
472 }
473 anydata results {
474 description
475 "This chunk of data contains the results of the execution
476 performed on the target object. The results are the same
477 or equivalent to the contents of a message,
478 Because of the nature of such a target execution, a
479 message is not used to return the execution
480 results. Instead, this notification is used to serve
481 the same purpose.";
482 }
483 }
484 } // schedule-config-notification
486 grouping schedule-state-attributes {
487 description
488 "State attributes for a schedule.";
489 container future-executions {
490 description
491 "The state information of the nexte scheduled event.";
492 list execution {
493 key "start";
494 description
495 "List of scheduled future executions.";
496 leaf start {
497 type yang:date-and-time;
498 description "Start time.";
499 }
500 leaf duration {
501 type string {
502 pattern
503 'P(\d+Y)?(\d+M)?(\d+W)?(\d+D)?T(\d+H)?(\d+M)?(\d+S)?';
504 }
505 description "Schedule duration in ISO 8601 format.";
506 }
507 leaf operation {
508 type operation;
509 description "Operation type.";
510 }
511 } // event
512 } // future-events
513 } // schedule-state-attributes
515 grouping schedules {
516 description
517 "A list of schedules defining when a particular
518 configuration takes effect.";
520 container schedules {
521 description
522 "Container of a schedule list defining when a particular
523 configuration takes effect.";
524 list schedule {
525 key "schedule-id";
526 description "A list of schedule elements.";
527 leaf schedule-id {
528 type uint32;
529 description "Identifies the schedule element.";
530 }
531 uses schedule-config-attributes;
532 }
533 }
534 } // schedules
536 /*
537 * Configuration data and operational state nodes
538 */
539 container configuration-schedules {
540 description
541 "Serves as top-level container for a list of configuration
542 schedules.";
543 list target {
544 key "object";
545 description
546 "A list of targets that configuration schedules are
547 applied.";
548 leaf object {
549 type yang:xpath1.0;
550 description
551 "Xpath defining the data items of interest.";
552 }
553 leaf operation {
554 type operation;
555 default "configure";
556 description
557 "Operation type.";
558 }
559 anydata data-value {
560 description
561 "The data value applied to the leaf data node
562 specified by data-objects.
563 The format of the data value depends on the value of the
564 leaf operation defined above:
565 configure: data-value is the sub-tree added to the
566 target object;
567 deconfigure: data-value is the child to be deleted from
568 the target object;
569 set: the target object MULST be a leaf, and
570 data-value is the new value to be set to
571 the target object;
572 reset: data-value is ignored.";
573 }
574 uses schedules;
575 container state {
576 config false;
577 description
578 "Operational state data.";
579 uses schedule-state-attributes;
580 } // state
582 uses schedule-config-notification;
583 } // target
584 } // configuration-schedules
585 }
586
588 8. IANA Considerations
590 RFC Ed.: In this section, replace all occurrences of 'XXXX' with the
591 actual RFC number (and remove this note).
593 This document registers the following namespace URI in the IETF XML
594 registry [RFC3688]:
596 --------------------------------------------------------------------
597 URI: urn:ietf:params:xml:ns:yang:ietf-schedule
598 Registrant Contact: The IESG.
599 XML: N/A, the requested URI is an XML namespace.
600 --------------------------------------------------------------------
602 This document registers the following YANG module in the YANG Module
603 Names registry [RFC6020]:
605 --------------------------------------------------------------------
606 name: ietf-schedule
607 namespace: urn:ietf:params:xml:ns:yang:ietf-schedule
608 prefix: l3te
609 reference: RFC XXXX
610 --------------------------------------------------------------------
612 9. Security Considerations
614 The configuration, state, action and notification data defined in
615 this document are designed to be accessed via the NETCONF protocol
616 [RFC6241]. The lowest NETCONF layer is the secure transport layer,
617 and the mandatory-to-implement secure transport is Secure Shell (SSH)
618 [RFC6242]. The NETCONF access control model [RFC6536] provides the
619 means to restrict access for particular NETCONF users to a pre-
620 configured subset of all available NETCONF protocol operations and
621 contents.
623 The functionality defined in this memo can potentially allow network
624 reconnaissance; by gathering information about schedules an attacker
625 can learn about the network policy, its temporal behavior, and future
626 events.
628 The schedule YANG model defines schedules that are writable,
629 creatable, and deletable. Therefore, this model may be considered
630 sensitive or vulnerable in some network environments. An attacker
631 may maliciously configure a schedule in a way that disrupts the
632 normal behavior of the network. Furthermore, an attacker may attempt
633 to maliciously set a schedule or a set of schedules in a way that
634 amplifies an attack, or schedules an attack to a particularly
635 sensitive time instant.
637 The use of configuration scheduling implicitly assumes that there is
638 an underlying synchronization or time distribution mechanism.
639 Therefore, an attack on the synchronization mechanism may compromise
640 the configuration scheduling. The security considerations of time
641 protocols are discussed further in [RFC7384].
643 10. Contributors
645 Tal Mizrahi
647 Email: talmi@marvell.com
649 11. References
651 11.1. Normative References
653 [IEEE1588]
654 IEEE, "IEEE Standard for a Precision Clock Synchronization
655 Protocol for Networked Measurement and Control Systems
656 Version 2", IEEE Standard 1588.
658 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
659 Requirement Levels", BCP 14, RFC 2119,
660 DOI 10.17487/RFC2119, March 1997, .
663 [RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch,
664 "Network Time Protocol Version 4: Protocol and Algorithms
665 Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010,
666 .
668 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for
669 the Network Configuration Protocol (NETCONF)", RFC 6020,
670 DOI 10.17487/RFC6020, October 2010, .
673 [RFC6021] Schoenwaelder, J., Ed., "Common YANG Data Types",
674 RFC 6021, DOI 10.17487/RFC6021, October 2010,
675 .
677 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed.,
678 and A. Bierman, Ed., "Network Configuration Protocol
679 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011,
680 .
682 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language",
683 RFC 7950, DOI 10.17487/RFC7950, August 2016,
684 .
686 [RFC7384] Mizrahi, T., "Security Requirements of Time Protocols in
687 Packet Switched Networks", RFC 7384, DOI 10.17487/RFC7384,
688 October 2014, .
690 [RFC7399] Farrel, A. and D. King, "Unanswered Questions in the Path
691 Computation Element Architecture", RFC 7399,
692 DOI 10.17487/RFC7399, October 2014, .
695 [RFC7758] Mizrahi, T. and Y. Moses, "Time Capability in NETCONF",
696 RFC 7758, DOI 10.17487/RFC7758, February 2016,
697 .
699 [I-D.birrane-dtn-ama]
700 Birrane, E., "Asynchronous Management Architecture",
701 draft-birrane-dtn-ama-05 (work in progress), March 2017.
703 [I-D.ietf-netconf-subscribed-notifications]
704 Voit, E., Clemm, A., Prieto, A., Nilsen-Nygaard, E., and
705 A. Tripathy, "Custom Subscription to Event Notifications",
706 draft-ietf-netconf-subscribed-notifications-03 (work in
707 progress), July 2017.
709 [I-D.ietf-netconf-yang-push]
710 Clemm, A., Voit, E., Prieto, A., Tripathy, A., Nilsen-
711 Nygaard, E., Bierman, A., and B. Lengyel, "Subscribing to
712 YANG datastore push updates", draft-ietf-netconf-yang-
713 push-08 (work in progress), August 2017.
715 11.2. Informative References
717 [RFC6087] Bierman, A., "Guidelines for Authors and Reviewers of YANG
718 Data Model Documents", RFC 6087, DOI 10.17487/RFC6087,
719 January 2011, .
721 Authors' Addresses
723 Xufeng Liu
724 Jabil
725 8281 Greensboro Drive, Suite 200
726 McLean VA 22102
727 USA
729 EMail: Xufeng_Liu@jabil.com
731 Igor Bryskin
732 Huawei Technologies
734 EMail: Igor.Bryskin@huawei.com
736 Vishnu Pavan Beeram
737 Juniper Networks
739 EMail: vbeeram@juniper.net
741 Tarek Saad
742 Cisco Systems Inc
744 EMail: tsaad@cisco.com
745 Himanshu Shah
746 Ciena
748 EMail: hshah@ciena.com
750 Oscar Gonzalez de Dios
751 Telefonica
753 EMail: oscar.gonzalezdedios@telefonica.com