Subject: [netmod] action-stmt

From: Andy Bierman <[email-masked]>
Date: Wed, 6 Jan 2016 19:26:29 -0800

Hi,

The action-stmt example on page 27 is wrong.
The <action> element is missing.  It is shown correctly
on page 105.
p27
  <rpc message-id="102"
          xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
       <interface xmlns="http://acme.example.com/system">
         <name>eth1</name>
         <ping>
           <destination>192.0.2.1</destination>
         </ping>
       </interface>
     </rpc>

p105

     <rpc message-id="101"
          xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
       <action xmlns="urn:ietf:params:xml:ns:yang:1">
         <server xmlns="http://example.net/server-farm">
           <name>apache-1</name>
           <reset>
             <reset-at>2014-07-29T13:42:00Z</reset-at>
           </reset>
         </server>
       </action>
     </rpc>

Sec. 7.15  provides few details wrt/ input processing.
Extra input is ignored? (draft is silent about that).
YANG attributes like "insert"or "operation" are ignored? (also silent).

Sec 7.15.2, para 2 is not clear whether the XML hierarchy
has to exist in any particular datastore (or opstate).
Since there is no mention of datastores in 7.15, I
assume the text just refers to the input containing
schema-valid XML, which may or may not correspond
to actual data instances somewhere inn the server.

Andy

---

From: Martin Bjorklund <[email-masked]>
Date: Fri, 08 Jan 2016 13:57:36 +0100 (CET)

Hi,

>              <reset-at>2014-07-29T13:42:00Z</reset-at>

Fixed.

> YANG attributes like "insert"or "operation" are ignored? (also silent).

Right, just as the text for rpcs.  Do you think we need to add some
text about this?

> to actual data instances somewhere inn the server.

Yes.

/martin

---

From: Ladislav Lhotka <[email-masked]>
Date: Wed, 13 Jan 2016 10:06:30 +0100

>> to actual data instances somewhere inn the server.

Hmm, so if I understand in correctly, actions can be attached also to
state data nodes. But sec. 7.15.2 says: "For lists, all key leafs MUST
also be included." What if a list in state data has no keys?

Lada

>
>
> /martin
>
> _______________________________________________
> netmod mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netmod

-- 
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C

---

From: Martin Bjorklund <[email-masked]>
Date: Wed, 13 Jan 2016 11:31:04 +0100 (CET)

Ladislav Lhotka <[email-masked]> wrote:
> state data nodes.

Correct.  But actually, I think that the data node instance that has
the action must exist at the time the action is applied.

> But sec. 7.15.2 says: "For lists, all key leafs MUST

No keys means that "all keys" is the empty set.

/martin

---

From: Ladislav Lhotka <[email-masked]>
Date: Wed, 13 Jan 2016 11:52:03 +0100

> On 13 Jan 2016, at 11:31, Martin Bjorklund <[email-masked]> wrote:
> 

OK.

> No keys means that "all keys" is the empty set.

How does the server then select the list entry to which the action is to be applied?

Lada

---

From: Martin Bjorklund <[email-masked]>
Date: Wed, 13 Jan 2016 12:07:25 +0100 (CET)

> How does the server then select the list entry to which the action

Sorry, I missed this point.  You are correct.  Invoking an action in a
descendant node to a list w/o keys is not possible.

/martin

---

From: Andy Bierman <[email-masked]>
Date: Wed, 13 Jan 2016 03:34:15 -0800

> > > the action must exist at the time the action is applied.

I asked about this point and the answer was the instance may or may not
exist.
The current text does not say anything about conceptual instances
that correspond to the ancestors and keys provided in the request.

Why would these rules be different for config vs. opstate?

Andy

---

From: Martin Bjorklund <[email-masked]>
Date: Wed, 13 Jan 2016 12:40:30 +0100 (CET)

> I asked about this point and the answer was the instance may or may not

I know - my fault, sorry.

> that correspond to the ancestors and keys provided in the request.

Right.  Two options:

  1) Keep current text.  When an action is invoked, the parent node
     may or may not exist.

  2) Add text that states that the when an action is invoked, the
     parent node MUST exist.

I prefer 2.

> Why would these rules be different for config vs. opstate?

No, they would be the same.

/martin

---

From: Ladislav Lhotka <[email-masked]>
Date: Wed, 13 Jan 2016 12:44:11 +0100

> On 13 Jan 2016, at 12:34, Andy Bierman <[email-masked]> wrote:
> 
> 
> 
> I asked about this point and the answer was the instance may or may not exist.

My question is about the opposite situation: there may be multiple candidate instances/list entries.

> Why would these rules be different for config vs. opstate?

Because opstate lists needn't have keys.

Lada