Hi Juergen,
thank you for the review.
Juergen Schoenwaelder writes:
> On Mon, Jun 15, 2015 at 10:49:28PM +, Kent Watsen wrote:
>>
>> This is a notice to start a NETMOD WG last call for the document "JSON
>> Encoding of Data Modeled with YANG":
>>
>> https://tools.ietf.org/html/draft-ietf
All,
Today is the cutoff date for the Last Call for this draft, but the author
indicated that comments received today or tomorrow can be incorporated into the
draft-update being worked on. So, if you have any lingering reviews, please
send them before as soon as possible.
Thanks!
Kent
Fro
All,
Today is the cutoff date for the Last Call for this draft, but the author
indicated that comments received today or tomorrow can be incorporated into the
draft-update being worked on. So, if you have any lingering reviews, please
send them before as soon as possible.
Thanks!
Kent
Fro
Juergen Schoenwaelder writes:
> On Mon, Jun 15, 2015 at 10:49:32PM +, Kent Watsen wrote:
>>
>> This is a notice to start a NETMOD WG last call for the document "Defining
>> and Using Metadata with YANG":
>>
>> https://tools.ietf.org/html/draft-ietf-netmod-yang-metadata-01
>>
>> Please ind
Martin Bjorklund writes:
> Hi,
>
> Currently we have an inconsistency in
> draft-ietf-netmod-rfc6020bis-05. With Y35, we allow type empty in
> unions. But section 7.8.2 says:
>
>A leaf that is part of the key can be of any built-in or derived
>type, except it MUST NOT be the built-in ty
Martin Bjorklund writes:
> Juergen Schoenwaelder wrote:
>> On Sun, Jun 28, 2015 at 05:11:28PM +0200, Martin Bjorklund wrote:
>> > Andy Bierman wrote:
>> > > On Sun, Jun 28, 2015 at 7:16 AM, Juergen Schoenwaelder <
>> > > j.schoenwael...@jacobs-university.de> wrote:
>> > >
>> > > > On Wed, Jun
Hi Lada,
FWIW, I have a few general question/comment on the draft, for which it might be
useful to add clarification:
- The general approach appears to be that metadata generally needs to
be defined as part of the module, and when it is, must be supported. How about
augmenting an ex
The following errata report has been submitted for RFC7223,
"A YANG Data Model for Interface Management".
--
You may review the report below and at:
http://www.rfc-editor.org/errata_search.php?rfc=7223&eid=4405
--
Type: Edito
Juergen Schoenwaelder writes:
>And my understanding is that the list foo defined above will never
>have an instance, correct? I assume decent compilers will continue to
>create warnings when they can decide that a list will never have any
>instances. (And yes, there are other ways to construct such
On Mon, Jun 29, 2015 at 2:40 PM, Phil Shafer wrote:
> Juergen Schoenwaelder writes:
> >And my understanding is that the list foo defined above will never
> >have an instance, correct? I assume decent compilers will continue to
> >create warnings when they can decide that a list will never have an
Dear all,
As a contributor, I browsed through draft-ietf-netmod-yang-metadata
-
The set of annotations must be extensible in a distributed manner
so as to allow for defining new annotations without running into
the risk of collisions with annotations defined and used by
Hello
I think I see how container meter-cfg is intended to allow configuration of RFC
2697 and 2698 style meters (by linking two meters in the meter-list via the
pointer next-meter-id). But it seems to me that a way to indicate overflow from
one bucket to another during token update is needed.
On Mon, Jun 29, 2015 at 05:40:22PM -0400, Phil Shafer wrote:
> Juergen Schoenwaelder writes:
> >And my understanding is that the list foo defined above will never
> >have an instance, correct? I assume decent compilers will continue to
> >create warnings when they can decide that a list will never
13 matches
Mail list logo
