Phil Shafer wrote:
The "echo all attributes back to the client" rule turns this from a CLR into an SLR (simple little rule) with a hundred and one uses. We've used it to record RPC name, hostname, timestamps, and other information so that any information we need to handle the rpc-reply is contained inside the rpc-reply. I can hand the rpc-reply to a transformation that uses this information without having to feed it in out of band.
You missed my point. Echoing all attributes is fine -- good stuff. Making a special check that the manager included an attribute named 'message-id', and rejecting the PDU if not, is the CLR.
Thanks, Phil
Andy
Andy Bierman writes:Hi, Didn't anybody notice that the protocol spec makes a big deal about a mandatory message-id (and I made a big deal about limiting its length), but it isn't used anywhere in the document in a normative manner? Nope. We took out the only operation that depended onthe message-id attribute a couple years ago.The agent totally ignores this attribute except to check if needs to generate an error if it is missing. If that isn't the essence of a Crappy Little Rule, I don't know what is. (I know, we may need the message-id someday, but not now.) Andy -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/netconf/>
-- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/netconf/>