The propose update to CoMI is available on github at:
https://core-wg.github.io/comi/draft-ietf-core-comi.txt.
A diff can be generated using the following URI.
https://tools.ietf.org/rfcdiff?url1=https://www.ietf.org/id/draft-ietf-core-comi-03.txt&url2=https://core-wg.github.io/comi/draft-ietf-co
Hello,
Recently we came up against a problem where a certain
implementation did not accept the following:
report-all
while it did accept
report-all
I am unsure whether YANG's XML encoding allows whitespace before
and after a leaf's value? In R
This issue has been touched by earlier version of
draft-kwatsen-netmod-artwork-folding-07.
RFC7950 has provide XML encoding rule as follows:
"
Any whitespace between the subelements to the list entry is
insignificant, i.e., an implementation MAY insert whitespace
characters between subelemen
Hello,
That does not answer my question about whitespace around
individual leaf/leaf-list values. The question about all these
examples is also open.
regards Balazs
On 2018. 10. 09. 11:23, Qin Wu wrote:
This issue
Balázs Lengyel wrote:
> Hello,
>
> Recently we came up against a problem where a certain implementation
> did not accept the following:
>
>
> report-all
>
>
> while it did accept
>
> report-all
>
> I am unsure whether YANG's XML encoding allows whitespace before and
> after a leaf's val
Hence why we go through so many hoops in the line-wrapping draft.
Adrian
> -Original Message-
> From: netmod [mailto:netmod-boun...@ietf.org] On Behalf Of Martin Bjorklund
> Sent: 09 October 2018 11:07
> To: balazs.leng...@ericsson.com
> Cc: netmod@ietf.org
> Subject: Re: [netmod] Whitesp
Balázs Lengyel writes:
> Hello,
>
> Recently we came up against a problem where a certain implementation did not
> accept the
> following:
>
>
> report-all
>
>
> while it did accept
>
> report-all
The "with-defaults" leaf is modelled as an enumeration in RFC 6243
(sec. 5), so the lexical
Hello Qin,
I will add the referemce.
Netconf server capabilities can be read from ietf-netconf-monitoring
/ncm:netconf-state/ncm:capabilities/ncm:capability
regards Balazs
On 2018. 10. 09. 8:28, Qin Wu wrote:
Support adoption of this draft,
Two quick comments on this draft
1. section 2.5 fac
I support the adoption.
Lada
Lou Berger writes:
> All,
>
> This is start of a two week poll on making
> draft-lengyel-netmod-yang-instance-data-04 a working group
> document. Please send email to the list indicating "yes/support" or
> "no/do not support". If indicating no, please state your re
Hi,
I still think that this draft should either be split into two, one for
specifiying the generic file format (ok with examples), and one for
"Documenting Server Capabilities", or the document should just be
about the file format (+ *examples*).
[The current document mixes the two; it's a bit as
+1 to Martin's comments. I think that I made similar comments at the
mic at IETF 102.
I strongly support the idea of documenting YANG instance data. If the WG
timing works out I would like this to cover CBOR as well.
I also strongly support the idea of documenting server capabilities.
But
On Tue, 2018-10-09 at 12:19 +0100, Robert Wilton wrote:
> +1 to Martin's comments. I think that I made similar comments at the
> mic at IETF 102.
Me too, it is also recoreded in the minutes. I thought this could be addressed
after this draft becomes a WG item.
Lada
>
> I strongly support the
Hello Martin,
I agree that this document shall be about defining the file format,
and server capabilities shall only be a use-case.)
I already took out a lot of text, that explicitly recommended using
instance data for documenting capabilities. Server capabilities are only
mentioned in the intr
On 10/8/18 07:38, Lou Berger wrote:
> All,
>
> This is start of a two week poll on making
> draft-lengyel-netmod-yang-instance-data-04 a working group
> document. Please send email to the list indicating "yes/support" or
> "no/do not support". If indicating no, please state your reservations
> wi
Hi,
Balázs Lengyel wrote:
> Hello Martin,
>
> I agree that this document shall be about defining the file format,
> and server capabilities shall only be a use-case.)
>
> I already took out a lot of text, that explicitly recommended using
> instance data for documenting capabilities. Server cap
OK, If the chairs are happy with that, I can update the document before
I store it as an official netmod document.
regards Balazs
On 2018. 10. 09. 14:25, Martin Bjorklund wrote:
Hi,
Balázs Lengyel wrote:
Hello Martin,
I agree that this document shall be about defining the file format,
and
I would expect that there are many other alternative uses of YANG
instance data.
Some possible alternatives that I can think of:
- Storing the configuration of a device at some point in time to a file,
e.g. for archive or audit purposes.
- Storing diagnostics data, if the format of the data was
Support.
On 2018-10-08, 7:39 AM, "netmod on behalf of Lou Berger"
wrote:
All,
This is start of a two week poll on making
draft-lengyel-netmod-yang-instance-data-04 a working group
document. Please send email to the list indicating "yes/support" or
"no/do not support".
Benjamin Kaduk has entered the following ballot position for
draft-ietf-netmod-schema-mount-11: No Objection
When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)
Please refe
Yes - support for this document.
Susan Hares
-Original Message-
From: netmod [mailto:netmod-boun...@ietf.org] On Behalf Of Lou Berger
Sent: Monday, October 8, 2018 7:39 AM
To: NetMod WG
Cc: NetMod WG Chairs
Subject: [netmod] WG adoption poll
All,
This is start of a two week poll on ma
Support –
I’m not sure I saw this on the list.
Cheerily, Sue Hares
On Mon, Oct 1, 2018 at 2:48 PM Kent Watsen wrote:
The IETF 102 in-room poll should really good support to adopt
this draft, and no objections.
This email starts an adoption poll for:
https://tools.ietf.or
As co-chair, I have two minds:
1) requests a fix and redo the adoption poll
2) realize that it's a living doc and regardless
how it begins, the WG can sort it out in time.
i.e., we're adopting to work on the problem,
not necessarily the specific solution.
While (1) seems more
I agree that a mandatory to implement format is desirable.
I disagree that YANG-Patch is the right format, for reasons
stated before. I feel that a compromise of this sort for
a mandatory-to-implement is wrong.
If this is what the WG wants, I withdraw my support.
Kent // contributor
-Or
As Martin points out, this is how XML works.
As a result, XML instance documents are poster-child examples for why long
lines occur sometimes, and where the artwork-folding draft shines when placing
said examples into drafts.
Lada, good point, but would there be a layer violation?
Kent // cont
I have a question about “when” and mandatory objects.
It seems to me that the implemented semantics of “when” are really “optional
when”, in that the enclosing object can be absent even though it is mandatory
and the “when” clause holds true.
The RFC could be clearer about this.
Example
lea
On Tue, Oct 09, 2018 at 05:07:06PM +, Kent Watsen wrote:
>
> As co-chair, I have two minds:
>
> 1) requests a fix and redo the adoption poll
> 2) realize that it's a living doc and regardless
> how it begins, the WG can sort it out in time.
> i.e., we're adopting to work on the
Eric Rescorla has entered the following ballot position for
draft-ietf-netmod-schema-mount-11: Discuss
When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)
Please refer to h
On Tue, 2018-10-09 at 17:24 +, Kent Watsen wrote:
> As Martin points out, this is how XML works.
>
> As a result, XML instance documents are poster-child examples for why long
> lines occur sometimes, and where the artwork-folding draft shines when placing
> said examples into drafts.
>
> Lad
28 matches
Mail list logo
