Hello,
We have the following design pattern.
1) An enumeration or a set of identities are defined that define a set
of options generally supported by Ericsson products. (e.g. supported
compression algorithms)
2) The specific node sets in run-time a leaf-list indicating the set of
values that
Andy,
This thread started with discussion of an apparent ambiguity in the current
text:
OLD
It is acceptable to reuse the same revision statement within unpublished
versions (i.e., Internet-Drafts), but the revision date MUST be updated to a
higher value each time the Internet-Draft is re-pos
> On 29 Aug 2016, at 12:42, William Lupton wrote:
>
> Regardless of whether circular import is permitted, isn’t it best avoided
> from a layering point of view? In general I would think that a module should
> be importing things that (a) it needs, and (b) don’t need it. W.
If possible, yes. H
> On 29 Aug 2016, at 09:17, Bogaert, Bart (Nokia - BE)
wrote:
>
> Just taking another approach on this: why do we have the restriction
> on circular imports? Is this really required? If not then this may
> be solved in another way too (but will take some time before it gets
> into the YANG c
Hello Andy,
Martin's main problem was that we would need to update the
original modules if the mount changes. I showed that design-time
mount can be defined without modifying the original modules, if
you specify the mount information in a separate file. So what
Regardless of whether circular import is permitted, isn’t it best avoided from
a layering point of view? In general I would think that a module should be
importing things that (a) it needs, and (b) don’t need it. W.
> On 29 Aug 2016, at 11:34, Ladislav Lhotka wrote:
>
>> On 29 Aug 2016, at 09:
> On 29 Aug 2016, at 09:17, Bogaert, Bart (Nokia - BE)
> wrote:
>
> Just taking another approach on this: why do we have the restriction on
> circular imports? Is this really required? If not then this may be solved
> in another way too (but will take some time before it gets into the YANG
>
"Bogaert, Bart (Nokia - BE)" wrote:
> Hi Martin,
>
> In BBF this pointer from HW to interface will be available (it has
> been proposed in the Berling BBF meeting already).
I assume this is done as an augmentation? Is it an augmentation to the
interface list, or to the hardware list? I.e., is
"Bogaert, Bart (Nokia - BE)" wrote:
> Hi Martin,
>
> In BBF this pointer from HW to interface will be available (it has been
> proposed in the Berling BBF meeting already).
I assume this is done as an augmentation? Is it an augmentation to
the interface list, or to the hardware list? I.e., is
Hi Martin,
In BBF this pointer from HW to interface will be available (it has been
proposed in the Berling BBF meeting already).
Best regards - Vriendelijke groeten,
Bart Bogaert
Broadband-Access System Architect Data
Contact number +32 3 2408310 (+32 477 673952)
NOKIA
Copernicuslaan 50, 2018 An
Hi,
[We had mail server problems during the weekend, so this reply might
not get the thread's history right.]
"Bogaert, Bart (Nokia - BE)" wrote:
> Martin Bjorklund wrote:
> "Bogaert, Bart (Nokia - BE)" wrote:
> > I would like to bring this to the ietf-entity group. Currently BBF is
> > propo
"Reorganization" of the modules as they are currently defined in IETF is
required in order to avoid the "circular import" error reported by the ConfD
compiler (e.g. confdc of TailF). I guess that when we remove this
restriction (as far as I remember, a #include equivalent is possible in
C/C++) the
I fail to see what this thread has to do with circular imports.
/js
On Mon, Aug 29, 2016 at 07:17:58AM +, Bogaert, Bart (Nokia - BE) wrote:
> Just taking another approach on this: why do we have the restriction on
> circular imports? Is this really required? If not then this may be solved
>
Just taking another approach on this: why do we have the restriction on
circular imports? Is this really required? If not then this may be solved
in another way too (but will take some time before it gets into the YANG
compilers I'm afraid).
Best regards - Vriendelijke groeten,
Bart Bogaert
Broa
14 matches
Mail list logo
