Hi,
I agree that anydata is much better than anyxml because it represents
how this "schema replacement" is actually being used.
I don't worry about anyxml too much.
It would be better to just rename anyxml, or declare it really
means anydata, but that would not be backward-compatible.
If anyxml
On Thu, Sep 17, 2015 at 08:24:28AM +0200, Ladislav Lhotka wrote:
>
> Yes, but the same thing can be done with anyxml, right? It has been
> demonstrated in RFC 6241, ietf-yang-patch and probably elsewhere, too,
> and it does the job.
>
> The use case of passing around literally "any XML" is really
On Wed, Sep 16, 2015 at 11:25:25AM -0700, Andy Bierman wrote:
>
> The "anyxml" node allows XML-specific details like processing instructions.
> It is a blob of XML. It is not JSON. It is not YANG. It is XML.
> This is academic, because the vast majority of servers do not support anyxml
> at all
On Wed, Sep 16, 2015 at 08:29:16PM +0200, Ladislav Lhotka wrote:
>
> > On 16 Sep 2015, at 18:00, Andy Bierman wrote:
> >
> >
> >
> > On Wed, Sep 16, 2015 at 8:17 AM, Juergen Schoenwaelder
> > wrote:
> > On Tue, Sep 15, 2015 at 12:21:44PM -0700, Andy Bierman wrote:
> > > On Tue, Sep 15, 2015
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-netmod-yang-json-05
Please indicate your support by Monday October 5, 2015 at 9PM EDT.
We are not only interested in receiving defect reports
Forwarded Anees Shaikh's email, with permission.
Thanks Anees. I believe it's useful info for NETMOD.
Regards, Benoit
Forwarded Message
hi Benoit, we will be publishing the primitives after we complete
our internal review -- it's in progress. There's nothing secret
ab
Hi,
I do not think the issue of scope is being considered very carefully.
IMO the solutions being proposed are extremely router-centric.
(e.g., most NETCONF servers DO NOT have any virtual servers within them).
The larger the scope, the more concern I have that
the IETF will be pushing expensive
Thanks Robert, but I think I like Benoit's edit more. Are you OK with it
as well?
PS: I've moved this issue to the VERIFY state.
Thanks,
Kent
On 9/21/15, 5:34 AM, "Robert Wilton" wrote:
>Hi,
>
>I suggest changing the wording for A and adding D:
>
>7. Ability for distinct modules to l
> On 21 Sep 2015, at 16:50, Acee Lindem (acee) wrote:
>
>
>
> On 9/21/15, 10:23 AM, "netmod on behalf of Ladislav Lhotka"
> wrote:
>
>> "Sterne, Jason (Jason)" writes:
>>
>>> Hi all,
>>>
>>> I met with Dean at IETF93 and we agreed that I should send a specific
>>> proposal to the list for
On 9/21/15, 10:23 AM, "netmod on behalf of Ladislav Lhotka"
wrote:
>"Sterne, Jason (Jason)" writes:
>
>> Hi all,
>>
>> I met with Dean at IETF93 and we agreed that I should send a specific
>>proposal to the list for this. Here it is:
>>
>> -
"Sterne, Jason (Jason)" writes:
> Hi all,
>
> I met with Dean at IETF93 and we agreed that I should send a specific
> proposal to the list for this. Here it is:
>
> -
> Replace the following current snippets from model-03:
> --
"Sterne, Jason (Jason)" wrote:
> Hi Martin,
>
> I think you raised those questions before about the model and they are
> useful to discuss but are they specific to my proposed modification to
> make the type mandatory or do your questions apply equally to the
> current v3 model as-is ?
>
> We ma
Hi Martin,
I think you raised those questions before about the model and they are useful
to discuss but are they specific to my proposed modification to make the type
mandatory or do your questions apply equally to the current v3 model as-is ?
We may want to fork off two somewhat independent em
Thanks Rob, that clarifies the situation for me.
Regards, Benoit
On 14 September 2015 at 08:43:53, Benoit Claise (bcla...@cisco.com) wrote:
Re-reading this section 4.5, I understand 6A and 6C, but is 6B also
required?
Do we need to make the link between a config node and all the derived
counte
Sent too fast.
I would change the requirement text like this.
OLD:
7. Ability for distinct modules to leverage a common model-structure
A. Scope is limited to IETF-defined modules
B. Multiple domain-specific trees are okay
C. Multiple namespaces are okay
NEW:
7. Ab
Dear all,
One update on my side on
https://github.com/netmod-wg/opstate-reqs/issues/7: Why limit scope to
just IETF-defined modules?
This issue will be taken care of in the Guidelines document RFC6087bis,
for both the IETF and the other SDOs, once we agree on the solution.
It is covered by
Hi,
after consulting with Martin Bjorklund, I decided to cancel today's
YANG 1.1 virtual interim meeting. Martin believes he has the input
needed to produce the next revision of draft-ietf-netmod-rfc6020bis.
This update should be posted during this week. We will then do any
word smithing that migh
Hi,
I suggest changing the wording for A and adding D:
7. Ability for distinct modules to leverage a common model-structure
A. Scope is limited to providing a general model-structure only
B. Multiple domain-specific trees are okay
C. Multiple namespaces are okay
Hi Eric,
we are dealing with two rather different problems:
1. A pull-type method for combining YANG schemas as a complement to
"augment".
2. A proxy function that mediates access to data that are located
elsewhere.
I believe the recent thread on structuring YANG models has been about #1
On Tue, Sep 15, 2015 at 10:00:46AM +0200, Ladislav Lhotka wrote:
> Juergen Schoenwaelder writes:
>
> > On Thu, Sep 10, 2015 at 06:19:20PM -0700, Randy Presuhn wrote:
> >
> >> >> Let's look at a slightly more complex hypothetical case to tease
> >> >> out how folks *want* things to work. Assume
Hi,
See below for some clarifying questions.
"Sterne, Jason (Jason)" wrote:
> Hi all,
>
> I met with Dean at IETF93 and we agreed that I should send a
> specific proposal to the list for this. Here it is:
>
> -
> Replace the following curre
21 matches
Mail list logo
