Status in source: current.
Technical details
{
"smi_kind": "OBJECT-TYPE",
"definition": [
"eriDiscoveryStatus",
"OBJECT-TYPE",
"SYNTAX",
"EriDiscoveryStateValue",
"MAX-ACCESS",
"read-write",
"STATUS",
"current",
"DESCRIPTION",
"\"This object shows if discovery messages are beeing issued from the node or not. A manager may turn off issuing of discovery messages by setting this object to disabled(0). The node may conclude that discovery has succeeded by other means of communication with a manager and will then indicate that by changing this value to disabled(0). If a manager sets this value to enabled(1) the node may choose to resume sending of discovery messages - or it may deny such a request by immediately reseting this value to disabled(0). Open issue: Shall we have this flexibility - or shall we mandate the possibility to re-start the dicovery process? It's good for testing and some error scenarios, but may have security implications and impacts on OSS, so we have to decide...\"",
"::=",
"{",
"eriDiscoveryControl",
"1",
"}"
],
"syntax_tree": [
[
"row",
"EriDiscoveryStateValue"
],
null,
[
"MaxAccessPart",
"read-write"
],
[
"Status",
"current"
],
[
"DESCRIPTION",
"This object shows if discovery messages are beeing issued from the node or not. A manager may turn off issuing of discovery messages by setting this object to disabled(0). The node may conclude that discovery has succeeded by other means of communication with a manager and will then indicate that by changing this value to disabled(0). If a manager sets this value to enabled(1) the node may choose to resume sending of discovery messages - or it may deny such a request by immediately reseting this value to disabled(0). Open issue: Shall we have this flexibility - or shall we mandate the possibility to re-start the dicovery process? It's good for testing and some error scenarios, but may have security implications and impacts on OSS, so we have to decide..."
],
null,
null,
null,
null
]
}