Subject: Re: [Netconf] Non-Netconf lock monitoring

From: WashamFan <[email-masked]>
Date: Wed, 01 Apr 2009 16:54:47 +0800

> Hello Washam,
>  I agree, that the netconf monitoring draft should include both 
> non-netconf locks, and 
>  non-netconf sessions.

IMO, sessionId is used to locate a lock accurately, when we want
to unlock by force, it is useful to <kill-session> relevant session.
But maybe, sessionId is not suitable for every case, as you mentioned
in thread "sessionId issue", for UDP, another approach may be better.

>  If you write such a MIB, it should have the same structure and 
> content as the relevant part of 
>  the netconf-monitoring YAM.

There is an effort to monitor all locks via different NM interfaces in a
consistent and extensive way. Please refer to
http://www.ietf.org/internet-drafts/draft-meng-fan-lock-mib-01.txt
Since Netconf WG would not do mibs, I will announce it to opsawg WG
expecting further development there.

>  Balazs
>  
>  WashamFan wrote:
>  > Hi,
>  > 
>  > When multiple NM protocols are supported by a device, all locks 
> acquired via all supported protocols should be monitored in a 
> consistent way.
>  > 
>  > We should identify each lock whatever protocol is used to control 
> the lock. If I understand correctly, lockId is used to differentiate 
> all locks including both Netconf and non-Netconf ones. That is good, 
> but maybe not enough.
>  > 
>  > We still should provide some information which is expected to be 
> used for releasing a lock by force. sessionId is used to release a 
> Netconf lock via <kill-session>, but IIRC, 
>  > sessionId=0 for all non-Netconf sessions. Please refer to another 
> thread discussing
>  > sessionId issue.
>  > 
>  > I co-author a mib draft to model multiplex protocols supported 
> locks monitoring,, I think it 
>  > is of value to this issue. And I want to ask if Netconf WG is a 
> suitable place to accommodate the draft.
>  > 
>  > washam

washam