Lou Berger wrote:
> Hi Martin,
>
> See below.
>
>
> On 8/22/2017 6:20 AM, Martin Bjorklund wrote:
> > Hi,
> >
> > Lada presented an open issue in schema mount in Prague. (See slide 6
> > in
> > https://datatracker.ietf.org/meeting/99/materials/slides-99-netmod-sessb-schema-mount)
> >
> > The o
My preference is to have the guidelines say what people should do,
namely design NMDA models. I would prefer to keep any transition
aspects out of the guidelines. If people want to include transition
aspects, it should be in the appendix (i.e., easy to remove / ignore
later on).
I understand that
A logical entity in the ENTITY-MIB boils down to the SNMP parameters
needed to talk to an SNMP agent that provides a context view on say a
bridge. This all was needed because the original bridge MIB module
design was not prepared to expose virtual lans, multiple spanning
trees etc. I assume that YA
Hi,
I'm not Rob, but my understanding is that if a module author wanted to migrate
to YANG 2.0, they could merge their submodules back into the main module -
which is not a difficult procedure and does not break compatibility with
clients.
Alex
From: ne
Hi Rob,
I’m fine with simplifying (even if the resultant pattern is much less
impressive ;^). I’ve copied the BESS WG to see if there are any objections.
Thanks,
Acee
From: "Robert Wilton -X (rwilton - ENSOFT LIMITED at Cisco)"
mailto:rwil...@cisco.com>>
Date: Monday, August 21, 2017 at 11:14 AM
Kent/WG,
This seems a bit terse to me and not provide needed guidance during
the current transition period. I understood the discussion ended up
with the options being to either (1) provide the guidance as a
standalone document, e.g., (a)-(s) in draft-dsdt-nmda-guidelines, with a
pointer to
RFC6933 Entity MIB contains the following tables:
* entPhysicalContainsTable (this is modeled in ietf-hardware-yang module)
* entLPPhysicalTable (describes the mapping of logical entities and
physical components supporting that entity).
There are some solution spaces that need to s
Hi,
During the meeting in Chicago, the NMDA authors took an action to
propose some text for S4.23. After a little review, the following
emerged. Yes, it's short, but was anything left anything out?
=START=
4.23 Operational Data
Operational data includes both config "false" nodes as
Acee, Rob,
Can you propose a specific change/addition to 6087Bis?
Thanks,
Lou
On 8/21/2017 10:01 AM, Acee Lindem (acee) wrote:
> Hi William, Rob, Andy,
>
> Given their limited usefulness and the detriments, perhaps we should
> discourage the creation of new submodules in RFC6087Bis.
>
> Than
Hi Martin,
See below.
On 8/22/2017 6:20 AM, Martin Bjorklund wrote:
> Hi,
>
> Lada presented an open issue in schema mount in Prague. (See slide 6
> in
> https://datatracker.ietf.org/meeting/99/materials/slides-99-netmod-sessb-schema-mount)
>
> The original problem comes from the NI use case
>
"Acee Lindem (acee)" wrote:
> Hi Martin,
>
>
> On 8/22/17, 6:20 AM, "netmod on behalf of Martin Bjorklund"
> wrote:
>
> >Hi,
> >
> >Lada presented an open issue in schema mount in Prague. (See slide 6
> >in
> >https://datatracker.ietf.org/meeting/99/materials/slides-99-netmod-sessb-s
> >chem
Hi Martin,
On 8/22/17, 6:20 AM, "netmod on behalf of Martin Bjorklund"
wrote:
>Hi,
>
>Lada presented an open issue in schema mount in Prague. (See slide 6
>in
>https://datatracker.ietf.org/meeting/99/materials/slides-99-netmod-sessb-s
>chema-mount)
>
>The original problem comes from the NI us
Hi,
Lada presented an open issue in schema mount in Prague. (See slide 6
in
https://datatracker.ietf.org/meeting/99/materials/slides-99-netmod-sessb-schema-mount)
The original problem comes from the NI use case
(https://tools.ietf.org/html/draft-ietf-rtgwg-ni-model). In this
use case, interface
13 matches
Mail list logo
