Hi Rohit, On one hand, this seems like a protocol issue, so opting for NETCONF's definitions makes sense. On the other hand, RFC 6241 is just defining the error-tag without mandating when it's used, whereas RFC 7950 is specifying when it's to be used, so opting for YANG's normative language makes sense (it does no harm).
Personally, I think YANG got it wrong and so it should be fixed there. Kent // as a contributor On 2/10/17, 9:25 AM, "Rohit pobbathi" <rohit.pobba...@huawei.com<mailto:rohit.pobba...@huawei.com>> wrote: Hi, Repeating a query about RFC Section conflict for the usage of error-tag usage during leaf data value mismatch in range/length/pattern. RFC 6241 Appendix A. NETCONF Error List – provides the below description for “invalid-value” & “bad-element” error-tag: invalid-value error-type: protocol, application error-severity: error error-info: none Description: The request specifies an unacceptable value for one or more parameters. error-tag: bad-element error-type: protocol, application error-severity: error error-info: <bad-element> : name of the element w/ bad value Description: An element value is not correct; e.g., wrong type, out of range, pattern mismatch. RFC 6020 Section 8.3.1. Payload Parsing o If a leaf data value does not match the type constraints for the leaf, including those defined in the type's "range", "length", and "pattern" properties, the server MUST reply with an "invalid-value" error-tag in the rpc-error, and with the error- app-tag and error-message associated with the constraint, if any exist. For leaf data value mismatch in range/length/pattern there is conflict in the error-tag suggested by RFC 6241 & RFC 6020. Please confirm which is the right error-tag to be used in a standard Netconf Server implementation. Regards, Rohit Pobbathi
_______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
