On Tue, May 31, 2016 at 11:02:41PM +0200, Martin Bjorklund wrote:
> "Acee Lindem (acee)" wrote:
> > Hi Lada,
> > If we can’t get YANG to do what we need, can we just support a choice with
> > a special value of “unspecified” for the interface and address?
>
> Yes, you can make these keys be unio
"Acee Lindem (acee)" wrote:
> Hi Lada,
> If we can’t get YANG to do what we need, can we just support a choice with
> a special value of “unspecified” for the interface and address?
Yes, you can make these keys be unions of interface-ref and an enum
'unspecified', and an ip-address and enum 'uns
Jason,
With regards to adding log-input-transports: please see RFC 5424 – The Syslog
Protocol, sections 3 and 4 where relay and collector functions are discussed.
In order to support the relay and/or collector function, log-input-transports
is required and I believe it is best to support the en
Since “multi-next-hop” is a list and we need a key for a list, even choice
doesn’t work here. I’m thinking maybe we can use “0.0.0.0” for empty ip
address and “NULL” for empty interface, but it doesn’t look pretty anyway.
Especially the interface should be a reference, and it can’t be “NULL”.
Than
Hi Lada,
If we can’t get YANG to do what we need, can we just support a choice with
a special value of “unspecified” for the interface and address?
Additionally, we’d need a constraint that enforces the fact that both
interface and address cannot be “unspecified”.
Thanks,
Acee
On 5/30/16, 8:51
