Hi, Med, Please see inline...
> Given that the new query parameter is not expected for a PATCH method, > the following behavior should be followed per 8040: > > o A server MUST return an error with a "400 Bad Request" > status-line > if a query parameter is unexpected. The error-tag value > "invalid-value" is returned in this case. > Why the error message is diving into more granular error handling > while the parameter is not allowed at the first place for that method? > [Qiufang] Note that this error message is caused because the client > attempts to override an immutable node, rather than an unexpected > query parameter for a PATCH method. The two examples in > B.6 are symmetrical following the below sentence in introduction > section: > "That said, it is expected that a server will return an error with an > error-tag containing "invalid-value" if a client attempts to modify an > immutable node." I have noted that. My comment was actually hoping that you include some text to explain what we gain operationally from this vs. using the 8040 behavior ;-) [Qiufang] I see your point now. But I would clarify we are exactly using the 8040 behavior. As defined in Section 7.1 of 8040 (https://datatracker.ietf.org/doc/html/rfc8040#section-7.1), while a server returns a status-line (e.g., "400 Bad Request") for a failed edit operation, it is fully expected and standard practice to include granular error fields such as error-path and error-message in the response body to provide details. RFC 8040 itself provides similar granular examples like Section 3.6.3 (see https://datatracker.ietf.org/doc/html/rfc8040#section-3.6.3) when a validation or internal constraint fails. I think it is obviously true that it would be helpful if the server could provide as rich information as it can to help clients diagnose the cause of an error (in this case, pinpointing the specific immutable node being modified). Based on this, do you still think it necessary to include any additional explanatory text in the draft? One nit in -13: OLD: immutable-annotation" module Section 9 by reading the YANG library NEW: immutable-annotation" module (Section 9) by reading the YANG library [Qiufang] Good catch. I have fixed this in https://github.com/netmod-wg/immutable-flag/pull/32. Thanks again for the very thorough review and valuable comments. Best regards, Qiufang _______________________________________________ netmod mailing list -- [email protected] To unsubscribe send an email to [email protected]
