Priorities: 

[P1] -> must have, otherwise not useful
[P2] -> would be very useful, to most operators
[P3] -> nice to have, useful to some

From the OOB ethernet port it should be possible to:

[P1]: Powercycle the RP, switchfabrics and linecards (hard, as in they might be totally dead and I want to cut power to it via the back plane. Also useful for FPGA upgrades).

[P1]: Connect to manage the RP(s) and linecards (equivalent of todays "connect" on GSR and ASR9k or connecting to RP serial port). 

[P2]: It should be possible to connect to the OOB from the RP as well (to diagnose OOB connectivity problems).

[P2]: Upload software to the RP or otherwise make information available to the RP (for later re-install/turboboot for example). RP should have access to local storage on the OOB device to transfer configuration or software from the OOB device to the RP).

[P2]: Read logs and other state of the components in the chassis (displays and LEDs) plus what kind of card is in each slot.

[P1]: The OOB port should support (configurable), telnet, ssh and optionally [P3] https login (with a java applet or equivalent to give CLI access in the browser) with ACLs to limit wherefrom things can be done. 

[P3] OOB should support ssh key based logins to admin account.

[P1]: The IP address of the OOB port should be set via DHCP/DHCPv6/SLAAC and should have both IPv4 and IPv6 support. If not both, then IPv6 only.

[P1]: It should be possible to transfer data using tftp, http and scp (http client on the OOB device, scp being used to transfer data *to* the device (OOB being scp server).

[P2]: OOB device should have tacacs and radius and [P1] local user/password database support for authentication.

[P3] Chassis should have a character display or LEDs with configurable blink pattern from OOB, to aid remote hands identification. 

[P3] OOB should have two USB ports, one to use to insert storage to transfer files to/from device. The other should be USB port that presents itself as ether USB serial port, or USB ethernet port, where the OOB device would have built in DHCP/DHCPv6 server to give IPv4v6 access to a laptop connected to the OOB so the onsite engineer can then use ssh/telnet to administrate the OOB. Optionally this port could be ethernet port (compare todays CON and AUX port functionality on current generation devices). It should be possible to access another device using this ethernet port, where the "AUX" port on the OOB is connected to the OOB "CON" port of another device.

[P2] OOB should have procedure to factory default its configuration, perhaps physical button that can be pressed and held for duration of time. The fact that this is done should be logged to the RP.

[P3] OOB should have possibility to show power supply and environmental state.

[P3] The factory default configuration should not include an empty or obvious login password.  The factory-default login password should be the MAC address (without punctuation) of the OOB ethernet interface, which should be printed on the chassis next to the OOBE port.


Rationale for above, ie what is bad about current situation:

RS232 cabling is operationally cumbersome (needs special pinout cables) and goes short distance (compared to ethernet). It also requires special equipment on-site that doesn't do anything else. The power functionality helps if there is a hard-lock on the equipment needing power cycle. Current serial mgmt solutions on XR requires both serial and ethernet address, and ethernet is only used to download using tftp (which is super slow on long latency links). Above suggestion is very much like CMP on Cisco Nexus platforms.