[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Comments on Partial Locking -01
To second some of Sharons items, the impression I got from the document
was that
configuration seems to be the only way resources on the box are
created.
We need to also consider hot insertion and removal of hardware.
E.g. I lock an ethernet interface to get get exclusivity on the
interface
but someone physically removes the card. Is my lock persisted ?
If that card is pushed back in what happens ? If a similar card is put
in ?
(e.g I pull out a 4 port card and put in an 8 port card)
I also support Phil's concerns. Can I "read" a config when someone has
locked
a subtree ? The risk for me is I could extract a config which is in
an intermediate state. We need some rules on reading such that I can
only
read a config which is in a know stable state (i.e. not locked)
James.
> -----Original Message-----
> From: owner-netconf@ops.ietf.org
> [mailto:owner-netconf@ops.ietf.org] On Behalf Of Sharon Chisholm
> Sent: Wednesday, 5 December 2007 9:45 AM
> To: netconf@ops.ietf.org
> Subject: Comments on Partial Locking -01
>
> Hi
>
> I assume since the new charter has been approved, this list is now the
> correct place to discuss the drafts proposing to address those items.
> Here are my comments on the latest partial locking draft.
>
> I continue to like the general approach.
>
> 1. Section 2.1, last paragraph, I assume multiple partial locks is
> achieved via multiple partial locking commands. This should be
> clarified.
>
> 2. Section 2.4.1, second paragraph, I assume the discussion of the
> partial lock not picking up new stuff to lock is done for
> simplicity? I
> am not sure it is what the user would want. I'd also be
> interested in an
> example of how new stuff get created if there is a lock.
>
> 3. Section 2.4.1, forth paragraph, is this defining a third way a
> partial lock can terminate (when what it is locking gets deleted) that
> should also be mentioned in the third paragraph of section 2.1?
>
> 4. Section 2.4.1, where it discusses that a partial lock will fail due
> to access rights, isn't that all we should say. "The lock will fail if
> the user does not have sufficient privileges ..." I don't think we
> should be talking about having enough privileges to read. We
> don't know
> what the access model will be and these could be separate attributes.
>
> 5. Section 2.4.1, where it talks about supporting XPATH when
> XPATH isn't
> supported. Do we really want this? Wouldn't it just be simpler to
> require XPATH. It seems people are supporting it anyway and if they
> don't, they don't get this optional capability.
>
> 6. Partial locks should be included in the NETCONF monitoring draft.
>
> 7. Section 5.1 (Open Issues), if I can't lock the thing I am about to
> create, then don't I need to lock its parent? This might be
> simpler, but
> at times might be locking other people out unnecessarily.
>
> Sharon Chisholm
> Nortel
> Ottawa, Ontario
> Canada
>
> --
> 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/>