Subject: [Netconf] ietf-netconf-partial-lock.yang

From: Andy Bierman <[email-masked]>
Date: Thu, 24 Jun 2010 22:20:27 -0700

Hi,

I am puzzled by some of the YANG usage in this module.
For the 'lock-id', why on Earth is returning it in
the rpc-reply not mandatory, and in the partial-unlock,
the

 rpc partial-lock {
    description
     "A NETCONF operation that locks parts of the running datastore.";
    input {
      leaf-list select {
        type string;
***          ^^^^^^  
***  I needed to change this to yang:xpath1.0 to get the XML prefixes
***  automatically in the stack.  Should we make an errata request
***  to change string to xpath1.0?

        min-elements 1;
        description
         "XPath expression that specifies the scope of the lock.
          An Instance Identifier expression MUST be used unless the
          :xpath capability is supported, in which case any XPath 1.0
          expression is allowed.";
      }
    }
    output {
      leaf lock-id {
        type lock-id-type;
        description
         "Identifies the lock, if granted.  The lock-id SHOULD be
          used in the partial-unlock rpc.";

*** I cannot find any text that suggests returning the lock-id is optional
*** I do not understand SHOULD instead of MUST

      }
      leaf-list locked-node {
        type instance-identifier;
        min-elements 1;
        description
         "List of locked nodes in the running datastore";
      }
    }
  }

  rpc partial-unlock {
    description
     "A NETCONF operation that releases a previously acquired
      partial-lock.";
    input {
      leaf lock-id {
        type lock-id-type;
        description
         "Identifies the lock to be released.  MUST be the value
          received in the response to a partial-lock operation.";

*** why isn't mandatory=true here?
*** what lock is released if no parameter is provided?

      }
    }
  }
}

Andy

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Sun, 27 Jun 2010 12:15:13 +0200

This document was published as RFC 5717.

Dan

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Andy Bierman
> Sent: Friday, June 25, 2010 8:20 AM
> To: Martin Bjorklund
> Cc: NETCONF
> Subject: [Netconf] ietf-netconf-partial-lock.yang
> 
> Hi,
> 
> For the 'lock-id', why on Earth is returning it in the 
> rpc-reply not mandatory, and in the partial-unlock, the
> 
> 
>  rpc partial-lock {
>     description
> _______________________________________________
> Netconf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netconf
>

---

From: Andy Bierman <[email-masked]>
Date: Sun, 27 Jun 2010 07:55:55 -0700

> This document was published as RFC 5717.

I know that.
It is full of bugs, most of which I ignored because it
is an RFC already.  Since it is an RFC the WG should
have no problem fully understanding it and explaining
what lock is released when there is no lock-id given.

One part says SHOULD provide a lock-id and another
says the lock-id MUST be correct.   If that isn't a bug
then how is it interoperable?

Andy

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Sun, 27 Jun 2010 18:30:38 +0200

Hi Andy,

See in-line. 

Dan

> From: Andy Bierman [mailto:[email-masked]] 
> Sent: Sunday, June 27, 2010 5:56 PM
> To: Romascanu, Dan (Dan)
> Cc: Martin Bjorklund; NETCONF
> Subject: Re: [Netconf] ietf-netconf-partial-lock.yang
> 
> It is full of bugs, most of which I ignored because it is an 
> RFC already.  Since it is an RFC the WG should have no 
> problem fully understanding it and explaining what lock is 
> released when there is no lock-id given.

It would have been better if problems (if agreed to be such) were
discovered before publication. This requires careful review from all WG
participants at all phases. 

Now we are where we are and we should decide if a. it's a problem b. it
it's a problem how should we deal with it (errata, RFC revision, other?)

> then how is it interoperable?

My reading is that of the lock-id is provided in the response to the
partial-lock operation, then this MUST be the value to be included in a
partial-unlock. Why this is a SHOULD in the partial-lock response and
what to do if a lock-id is not available - open questions to the editors
I guess. 

> rpc-reply not 
> >> mandatory, and in the partial-unlock, the
> >>
> >>
> >>  rpc partial-lock {
> >>     description

---

From: Andy Bierman <[email-masked]>
Date: Sun, 27 Jun 2010 09:54:14 -0700

> what to do if a lock-id is not available - open questions to the editors

The current YANG text says that the lock-id is optional
to implement by the server.  It does not have to be returned
in the reply.  IMO, this is a horrible for a standard.
It also breaks the monitoring module because
the <partial-locks> list is keyed by the lock-id,
so it is mandatory from the monitoring POV.

The server MUST make sure the same session is issuing the
partial-lock that is calling partial-lock.  If the client
only has 1 partial-lock, then the lock-id is redundant.

IMO, this sort of optimization to save a'uint32' leaf
is beyond clueless.  It increases client complexity
greatly because no developer is going to
design code for a max of 1 partial lock.

What if the client wants more than 1 partial-lock
from a server that doesn't implement lock-id?
Does the server hand out multiple locks without
any way to distinguish them for partial-unlock?
How broken is that?  If not, then the server
is non-compliant because it MUST support multiple
concurrent locks.

How does the client know if the server implements
client-id without trying to lock something? (It doesn't)

Andy

---

From: Martin Bjorklund <[email-masked]>
Date: Mon, 28 Jun 2010 07:57:44 +0200 (CEST)

>      "A NETCONF operation that locks parts of the running datastore.";

I agree that the correct type is 'xpath1.0'.

> *** I cannot find any text that suggests returning the lock-id is optional

Correct; it is not optional.  This leaf should have a "mandatory
true;" statement.  This would be it consistent with the text and XSD.

> *** I do not understand SHOULD instead of MUST

I don't think either SHOULD or MUST is actually correct.  The client
can close the connection without doing partial-unlock, so MUST is not
right either.

> *** what lock is released if no parameter is provided?

It should have mandatory true.  This would make it consistent with the
text and XSD.

/martin

---

From: "Bert (IETF) Wijnen" <[email-masked]>
Date: Mon, 28 Jun 2010 12:23:19 +0200

I suggest that we create proposed text for reporting these errata
We then let the WG read/think-about/check it, and once we agree
we report it as an errata and keep it on the shelf for whever we
do a revision.

Bert