ODL Issue For Ietf-alarm yang with key as identity
Anshul Agrawal <aagrawal@...>
Hi,
I am working for Netconf protocol for ietf-alarm yang.
https://tools.ietf.org/html/rfc8632
Ietf-alarm yang has 3 keys for /alarms/alarm-list/alarm list, where alarm-type-id is key of IdentityRef type.
typedef alarm-type-id { type identityref { base alarm-type-id; } description "Identifies an alarm type. The description of the alarm type id MUST indicate whether or not the alarm type is abstract. An abstract alarm type is used as a base for other alarm type ids and will not be used as a value for an alarm or be present in the alarm inventory."; }
While performing get-config operation, via Postman, I am forming all 3 keys where one of key is of type identityref.
alarm-type-id à this key is provided using <module name > : <identity name> test-openconfig-extensions:ABCD
But ODL is sending this request in following format :- <alarm-type-id xmlns:x=http://openconfig.net/yang/test/yang/extensions>x:ABCD</alarm-type-id>
Question here is why ODL is sending this request as “x= or “x: at place of original module name.
Following is corresponding ODL logs
Value is not instance of IdentityrefTypeDefinition but is class java.lang.String. Therefore NULL is used as translation of - test-openconfig-extensions:ABCD 17:56:38.746 DEBUG [qtp350578804-316] Enter container (urn:ietf:params:xml:ns:yang:ietf-alarms?revision=2019-09-11)alarms 17:56:38.747 DEBUG [qtp350578804-316] Enter container (urn:ietf:params:xml:ns:netconf:base:1.0?revision=2011-06-01)source 17:56:38.747 DEBUG [qtp350578804-316] Enter choice (urn:ietf:params:xml:ns:netconf:base:1.0?revision=2011-06-01)config-source
Thanks Anshul Agrawal |
|
Anshul Agrawal
Gentle Reminder.
From: Anshul Agrawal
Sent: Thursday, April 22, 2021 6:12 PM To: discuss@...; dev@... Cc: Sachin Jain <sjain@...> Subject: ODL Issue For Ietf-alarm yang with key as identity
Hi,
I am working for Netconf protocol for ietf-alarm yang.
https://tools.ietf.org/html/rfc8632
Ietf-alarm yang has 3 keys for /alarms/alarm-list/alarm list, where alarm-type-id is key of IdentityRef type.
typedef alarm-type-id { type identityref { base alarm-type-id; } description "Identifies an alarm type. The description of the alarm type id MUST indicate whether or not the alarm type is abstract. An abstract alarm type is used as a base for other alarm type ids and will not be used as a value for an alarm or be present in the alarm inventory."; }
While performing get-config operation, via Postman, I am forming all 3 keys where one of key is of type identityref.
alarm-type-id à this key is provided using <module name > : <identity name> test-openconfig-extensions:ABCD
But ODL is sending this request in following format :- <alarm-type-id xmlns:x=http://openconfig.net/yang/test/yang/extensions>x:ABCD</alarm-type-id>
Question here is why ODL is sending this request as “x= or “x: at place of original module name.
Following is corresponding ODL logs
Value is not instance of IdentityrefTypeDefinition but is class java.lang.String. Therefore NULL is used as translation of - test-openconfig-extensions:ABCD 17:56:38.746 DEBUG [qtp350578804-316] Enter container (urn:ietf:params:xml:ns:yang:ietf-alarms?revision=2019-09-11)alarms 17:56:38.747 DEBUG [qtp350578804-316] Enter container (urn:ietf:params:xml:ns:netconf:base:1.0?revision=2011-06-01)source 17:56:38.747 DEBUG [qtp350578804-316] Enter choice (urn:ietf:params:xml:ns:netconf:base:1.0?revision=2011-06-01)config-source
Thanks Anshul Agrawal |
|
Robert Varga
On 22/04/2021 14:41, Anshul Agrawal wrote:
Hi,Hello, I am working for Netconf protocol for ietf-alarm yang.Can you specify the version you are using, please? Northbound interface is RESTCONF, which is using module names for namespace specification (see RFC8040, section 3.5.3) Southbound interface is NETCONF, which in turn means XML encoding -- which is using XML's built-in facilities for namespace specification (see RFC6020 section 9.10.3), which are completely independent of YANG module names. We are using a strategy which is consistent with examples in RFC6020 section 9.10.5. Regards, Robert |
|