Subject: Message-id and Session-id

From: "王罕" <[email-masked]>
Date: Wed, 24 Nov 2004 13:39:19 +0800

Dear all:

  I am confused by an example in the prop-04 document, so I want to ask a few questions.
1. when does the message-id increasing? 
2. how does the session-id create?
  
  Formerly I think that a Session is composed by several messages which are sent from a special client. The session and the messages is identified by session-ID and message-ID respectively.

  In the prop-04,the message-id is defined as "an arbitrary string chosen by the sender of the RPC that will commonly encode a monotonically increasing integer." 

  In followed example, (in 7.5), the first message acquired a lock successfully, I supposed 
the message is identified by "101" , and the message is part of the session 150 of clientA.
  then clientB try to acquire a lock through message "101" in its session 454, of course failed.
  
  BUT, why can it use the same message-id with clientA?  does it mean the message-id only
increasing in the session which it belonged?

<rpc message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
         <lock>
           <target>
             <running/>
           </target>
         </lock>
</rpc> 

<rpc-reply message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
         <ok/> <!-- lock succeeded -->
       </rpc-reply>

       <rpc message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
         <lock>
           <target>
             <running/>
           </target>
         </lock>
       </rpc>

       <rpc-reply message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
         <rpc-error> <!-- lock failed -->
           <error-type>protocol</error-type>
           <error-tag>LOCK_DENIED</error-tag>
           <error-severity>error</error-severity>
           <session-id>150</session-id>
           <error-message>Lock failed, lock is already held</error-message>
           <error-info>
             <session-id>454</session-id> <!-- lock is held by NETCONF session 454 -->
           </error-info>
         </rpc-error>
       </rpc-reply>

Best Regards

Wang

--------------------------------------------------
Han Wang   PostGraduate

Research Center of Network Technology
Nanjing University of Posts and Telecommunications
---------------------------------------------------

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/netconf/>

---

From: Wes Hardaker <[email-masked]>
Date: Wed, 24 Nov 2004 17:03:09 -0800

>>>>> On Wed, 24 Nov 2004 13:39:19 +0800, "王罕" <[email-masked]> said:

y030737> 1. when does the message-id increasing? 

It is entirely up to the client application.  It can reuse the same
message id if it wants (and hopeful do so and not get confused).  The
server doesn't care what the message ID is.  It merely puts it in the
reply RFC to help the client recognize what the response is responding
to.

y030737> 2. how does the session-id create?

The server creates that and hands it to the client during start up.  I
think this may not be complete in -04???  But will be in -05.
  
y030737> In followed example, (in 7.5), the first message acquired a
y030737> lock successfully, I supposed the message is identified by
y030737> "101" , and the message is part of the session 150 of
y030737> clientA.  then clientB try to acquire a lock through message
y030737> "101" in its session 454, of course failed.
  
y030737> BUT, why can it use the same message-id with clientA?  does
y030737> it mean the message-id only increasing in the session which
y030737> it belonged?

The server won't care that the message-ids are the same.  There is no
need for uniqueness.  It's only the clients that will likely need them
to be different, and only for their own messages.

[note that all the examples in the document use the same message ID.
I personally don't think this is helpful, but I didn't spend the
effort writing the document ;-]

-- 
"In the bathtub of history the truth is harder to hold than the soap,
 and much more difficult to find."  -- Terry Pratchett

---

From: "David T. Perkins" <[email-masked]>
Date: Wed, 24 Nov 2004 17:54:51 -0800 (PST)

HI,

I believe that saying that session and message IDs are not too
useful is a little bit of a simplication and not thinking ahead.

First, the message ID is a great piece of info to be used
for correlation. That is, if it is saved and provided to
lower levels, then if an event occurs, then the ID can
be sent with the event report for correlation.

Secondly, when the transport is connectionless, a message
ID can be used to determine duplicates and lost messages.

Thirdly (this is what Wes covered, but did not fully explain)
is that a "client" (manager) application may submit multiple
requests and the "server" (managed system), may perform them
concurrently, and a later request may be completed before
and earlier request. The message ID is what is used to pair
a response with a request.

Of course if messages can only be sent over a connection
oriented transport, and requests are always processed
in order, then there are not too much benefit other
than correlation.

On Wed, 24 Nov 2004, Wes Hardaker wrote:

> >>>>> On Wed, 24 Nov 2004 13:39:19 +0800, "Íõº±" <[email-masked]> said:
> 
Regards,
/david t. perkins

---

From: Wes Hardaker <[email-masked]>
Date: Thu, 25 Nov 2004 11:45:07 -0800

>>>>> On Wed, 24 Nov 2004 17:54:51 -0800 (PST), "David T. Perkins" <[email-masked]> said:

David> I believe that saying that session and message IDs are not too
David> useful is a little bit of a simplication and not thinking
David> ahead.

Um, who said that?  I don't remember reading that at all.