On Tue, Jun 11, 2019 at 05:43:27PM +, Italo Busi wrote:
> [Italo Busi] If the client knows the prefix used by the server, it
> can pick up a different prefix and use it to tag its own entries. I
> think this rule is not really complex and it seems much simpler than
> managing unintended name
Hi Juergen,
Thanks for your reply: see some comments of mine in line below
Italo
-Original Message-
From: Juergen Schoenwaelder [mailto:j.schoenwael...@jacobs-university.de]
Sent: martedì 11 giugno 2019 19:19
To: Italo Busi
Cc: Andy Bierman ; t...@ietf.org; Tarek Saad
;
On Tue, Jun 11, 2019 at 04:36:08PM +, Italo Busi wrote:
>
> I agree with your statements as long as we consider two sources for the same
> information/instance. In this case, my understanding is that the same key
> value is intentionally assigned by the two sources to indicate that they are
Juergen, Andy,
Thanks for your reply
I agree with your statements as long as we consider two sources for the same
information/instance. In this case, my understanding is that the same key value
is intentionally assigned by the two sources to indicate that they are
representing the same
A somewhat arbitrary choice of message to reply to, in order to say that
other protocols do have layers, e.g. igmp in
draft-ietf-pim-igmp-mld-yang
but they have taken a different approach. They have such as
grouping interface-global-config-attributes {
grouping
On Tue, Jun 11, 2019 at 08:54:11AM -0700, Andy Bierman wrote:
> There are no instance naming collisions within or .
> Only if you try to combine them, which is not how it works. The server
> chooses what to put in and sets the origin attribute
> accordingly.
And for a robust solution, it is
On Tue, Jun 11, 2019 at 8:40 AM Italo Busi wrote:
> Hi Tom,
>
> My understanding is that the running DS contains only the list entries
> configured by the client and therefore there is no key collision (the key
> values are all assigned by the client)
>
> The issue is that the operational DS
Hi Tom,
My understanding is that the running DS contains only the list entries
configured by the client and therefore there is no key collision (the key
values are all assigned by the client)
The issue is that the operational DS will contain two types of list entries:
- list entries
On 2019-06-11 15:43, Xufeng Liu wrote:
Thank Per for the clear analysis. Since the current YANG RFC7950 does not have a formal way to specify the overriding rule, I agree that the best way is to remove the default statements from
"level-1" and "level-2", as Per, Martin, and Rob suggested.
Thank Per for the clear analysis. Since the current YANG RFC7950 does not
have a formal way to specify the overriding rule, I agree that the best way
is to remove the default statements from "level-1" and "level-2", as Per,
Martin, and Rob suggested.
Regards,
- Xufeng
[Forwarding Per's reply to
10 matches
Mail list logo
