Re: [netmod] On prefixes RE: Next steps for draft-ietf-netmod-rfc8407bis

Hi - On 2024-03-04 12:51 AM, mohamed.boucad...@orange.com wrote: Hi Jan, I went so far with the following: OLD:    Prefix values SHOULD be short but are also likely to be unique.    Prefix values SHOULD NOT conflict with known modules that have been previously published. NEW:   

Re: [netmod] Extending YANG by implementation-specific blocks

Hi - On 2023-11-16 12:09 AM, Maria Matejka wrote: ... we're currently trying to create a YANG-described API for BIRD. The interface will be (at least) one large C file generated from the YANG files, as we want the implementation to be directly tied to the specification. What we're aiming to

Re: [netmod] What to reference when importing an IANA module?

Hi - Serves me right for responding before reading all the messages in my inbox. I concur with Benoit's comments. Randy On 2023-01-16 2:49 AM, Benoit Claise wrote: Dear all, On 1/13/2023 9:22 PM, Randy Presuhn wrote: Hi - On 2023-01-13 10:20 AM, Kent Watsen wrote: On Jan 13, 2023

Re: [netmod] What to reference when importing an IANA module?

Hi - On 2023-01-16 12:00 AM, mohamed.boucad...@orange.com wrote: Hi Randy, Please see inline. Cheers, Med -Message d'origine- De : netmod De la part de Randy Presuhn Envoyé : vendredi 13 janvier 2023 21:22 À : cc...@ietf.org; netmod@ietf.org Objet : Re: [netmod] What to reference

Re: [netmod] What to reference when importing an IANA module?

Hi - On 2023-01-13 10:20 AM, Kent Watsen wrote: On Jan 13, 2023, at 11:25 AM, Benoit Claise wrote: Hi Tom, Yes I do think that people outside the IETF may be ignorant of the nuances of the way the IETF works and may not realise that a URL to the IANA website must be used in preference

Re: [netmod] What to reference when importing an IANA module?

Hi - On 2023-01-12 9:03 AM, Benoit Claise wrote: ... Oh, because you conclude that, if we put a RFC number in the reference, the community will (be stupid enough to) conclude that it has to extract the YANG module from the RFC text directly ... as opposed to look for a location where it's

Re: [netmod] YANG module versioning: Proposed change to "Import by derived revision"

Hi - On 2022-10-04 12:15 PM, Jürgen Schönwälder wrote: ... I am hoping for a technically sound solution that provides predictable behaviour of independently developed tools. Some "hints" that may be used or ignored at the discretion of an implementation do not really meet that bar. ... There

Re: [netmod] [Lsr] I-D Action: draft-ietf-lsr-ospfv3-extended-lsa-yang-10.txt

ink Rob is trying to strike that balance (and has been for a while now with his work in this area), and I support him. Thanks, Chris. Randy Presuhn writes: Hi - If one accepts your arguments, you've made the case for defining a new module with typedefs for ipv6-address, etc. with modified synta

Re: [netmod] [Lsr] I-D Action: draft-ietf-lsr-ospfv3-extended-lsa-yang-10.txt

t the scope information is being provided by other context (e.g., outgoing-interface in the example above), or perhaps most operators just configure their devices using global IP addresses. Some further comments inline … > -Original Message- > From: netmod On Behalf Of Randy

Re: [netmod] [Lsr] I-D Action: draft-ietf-lsr-ospfv3-extended-lsa-yang-10.txt

Hi - I took a fresh look at RFC 6991, and a couple of things that have already been mentioned in this thread bear repetition. (1) in both the ipv4-address and ipv6-address typdefs, the zone is only optionally present. This is made clear both in the string patterns as well as the descriptions,

Re: [netmod] [Lsr] I-D Action: draft-ietf-lsr-ospfv3-extended-lsa-yang-10.txt

Hi - On 2022-04-14 1:33 PM, Andy Bierman wrote: On Thu, Apr 14, 2022 at 1:13 PM Jürgen Schönwälder > wrote: On Thu, Apr 14, 2022 at 12:48:18PM -0700, Andy Bierman wrote: > The proposal is for a 2 year phase to change modules >

Re: [netmod] [Lsr] I-D Action: draft-ietf-lsr-ospfv3-extended-lsa-yang-10.txt

Hi - On 2022-04-14 1:13 PM, Jürgen Schönwälder wrote: On Thu, Apr 14, 2022 at 12:48:18PM -0700, Andy Bierman wrote: The proposal is for a 2 year phase to change modules that really do want a zone index. It is not blindly removing the zone index. People not reading type definitions will

Re: [netmod] [Lsr] I-D Action: draft-ietf-lsr-ospfv3-extended-lsa-yang-10.txt

f description-stmt using 'ip-address' should specify if any zone support is required. The default could be 'none' so no mention is needed most of the time.     Regards,     Rob Andy > -Original Message- > From: netmod mailto:netmod-boun...@ietf.org>> On Behalf

Re: [netmod] [Lsr] I-D Action: draft-ietf-lsr-ospfv3-extended-lsa-yang-10.txt

Hi - On 2022-04-09 4:36 AM, Christian Hopps wrote: ... FWIW, I'm not arguing for this change; however, to be fair, isn't this also about the existing published modules that are using the incorrect type? No. "Incorrect type" is a bit of a mischaracterization. It's like saying using "int32"

Re: [netmod] [Lsr] I-D Action: draft-ietf-lsr-ospfv3-extended-lsa-yang-10.txt

Hi - On 2022-04-08 12:25 PM, Acee Lindem (acee) wrote: ... If you look at the existing YANG RFCs rather than drafts that are confirming to the error, you'll notice that they don't use the no-zone types: https://datatracker.ietf.org/doc/rfc8344/ ... Huh? RFC 8344 *does* use

Re: [netmod] [Lsr] I-D Action: draft-ietf-lsr-ospfv3-extended-lsa-yang-10.txt

Hi - On 2022-04-08 5:11 AM, Christian Hopps wrote: .. Instead, Acee (I'm not sure I'd call him WG B :) is asserting that *nobody* actually wanted the current type, and it has been misused everywhere and all over. The vast majority of implementations in operation probably can't even handle the

Re: [netmod] IETF WG state changed for draft-ietf-netmod-rfc6991-bis

Hi - On 2022-04-07 11:31 AM, Kent Watsen wrote: Hi Randy, That's a reasonable rationale, and might even make a good CLR if adopted from the very beginning, but given the ability of model designers to read too much (or too little) into names, perhaps one might consider the possibility of

Re: [netmod] [Lsr] I-D Action: draft-ietf-lsr-ospfv3-extended-lsa-yang-10.txt

Hi - Let me get this straight. WG A standardized types X and Y years ago, and support for these has presumably been implemented in some number of tools, which in turn have been used to develop some unknowable number of products, whose deployment is even more unknowable. WG B comes along, and

Re: [netmod] IETF WG state changed for draft-ietf-netmod-rfc6991-bis

Hi - On 2022-04-07 12:13 AM, Jürgen Schönwälder wrote: ... given recent discussions around ip addresses, I am not sure about the consensus and perhaps we should consider to name the new date and time types differently, e.g. date -> date-with-zone date-no-zone -> date time ->

Re: [netmod] [CCAMP][TEAS][NETMOD] Efficiency issues with YANG model data in integration

Hi - On 2022-03-17 9:32 AM, tom petch wrote: ... From: netmod on behalf of yuchaode Sent: 15 March 2022 01:30 To: 'cc...@ietf.org'; 't...@ietf.org'; 'netmod@ietf.org' Cc: Fatai Zhang I have a question about YANG data model efficiency issues discovered during integration with OSS. ...

Re: [netmod] [Technical Errata Reported] RFC7950 (6885)

Hi - On 2022-03-15 11:13 PM, Jürgen Schönwälder wrote: YANG update rules expect clients to be lenient about values they received but did not expect. It is possible to debate that design choice but this surely is not an errata, hence this errata should be rejected. I agree that the proposed

Re: [netmod] [Technical Errata Reported] RFC7950 (6855)

te this message immediately from your computer. Any other use, retention, dissemination, forwarding, printing, or copying of this e-mail is strictly prohibited. *From: *Randy Presuhn *Date: *Thursday, February 17, 2022 at 2:55 PM *To: *RFC Errata System , "m...@tail-f.com" , "war...@ku

Re: [netmod] [Technical Errata Reported] RFC7950 (6855)

Hi - This seems like a remarkably pointless change, and arguably at odds with section 6 of RFC 2119. ("Imperatives of the type defined in this memo must be used with care and sparingly.") Randy On 2022-02-17 10:50 AM, RFC Errata System wrote: > The following errata report has been submitted

Re: [netmod] Camel Case versus hyphenation

Hi - On 2022-01-01 5:30 AM, Kent Watsen wrote: The fist couple paragraphs here apply: https://datatracker.ietf.org/doc/html/rfc8407#section-4.3.1 I think that it should be “open-wait” (not openwait).  Mimicking RFC values is not

Re: [netmod] Clarification on the description for chassis and stack in RFC 8348

Hi - On 2021-10-22 4:14 AM, tom petch wrote: ... Yes, I am well familiar with telecoms racks and with cabling racks. With cabling racks, then I think that there is too little logic to qualify for this model and I wonder if the same is true for subshelves which is something I am not familiar

Re: [netmod] [babel] NULL value for uint16

Hi - On 2021-09-27 11:35 AM, Andy Bierman wrote: On Mon, Sep 27, 2021 at 10:42 AM Randy Presuhn <mailto:randy_pres...@alumni.stanford.edu>> wrote: Hi - On 2021-09-27 10:13 AM, Andy Bierman wrote: ... > SNMP GetNext and GetBulk do not handle missing nodes

Re: [netmod] [babel] NULL value for uint16

Hi - On 2021-09-27 10:13 AM, Andy Bierman wrote: ... SNMP GetNext and GetBulk do not handle missing nodes well at all, so it became common practice to return 0 or -1, etc. to simplify client processing of these operations. None of the YANG-based protocols have this problem. In what way

Re: [netmod] NULL value for uint16

Hi - On 2021-09-10 9:57 AM, Andy Bierman wrote: On Fri, Sep 10, 2021 at 9:47 AM Randy Presuhn <mailto:randy_pres...@alumni.stanford.edu>> wrote: Hi - On 2021-09-10 9:42 AM, Andy Bierman wrote: > Hi, > > Maybe the use of [null] in RFC 7951 i

Re: [netmod] NULL value for uint16

Hi - On 2021-09-10 9:42 AM, Andy Bierman wrote: Hi, Maybe the use of [null] in RFC 7951 is confusing people https://datatracker.ietf.org/doc/html/rfc7951#section-6.9 Are you suggesting that the type of this leaf should be a choice

Re: [netmod] [Anima] revising RFC8366 -- Re: BRSKI-AE enum issue -> empty, but what's he encoding ?

Hi - From: netmod on behalf of Michael Richardson Sent: 05 July 2021 21:40 Randy Presuhn wrote: > In ltru the I-Ds contained both material for publication > in the RFC as well as a *massive* amount of material for > population of the IANA language tag registry.

Re: [netmod] [Anima] revising RFC8366 -- Re: BRSKI-AE enum issue -> empty, but what's he encoding ?

Hi - On 2021-07-05 9:13 AM, tom petch wrote: ... Well my answer would be that confusion reigns.  An IANA Registry is > authoritative so the minute the RFC is published asking IANA to maintain a module, then the module in RFC8366(-bis) is obsolete. Trouble is, that the rest of the RFC - if any

Re: [netmod] review of state NBC rules in yang-module-versioning-02

Hi - On 2021-03-30 9:15 AM, Sterne, Jason (Nokia - CA/Ottawa) wrote: Hi guys, Let's take this model for a leaf (line numbers for reference): 10 leaf foo { 20 type uint8 { 30range "5..101"; 40 } 50 } When I've been talking about "type" I've only been talking about line 20.

Re: [netmod] ECA Policy: What is an adequate abstraction level to express policies and intent

Presuhn 发送时间: 2021年3月18日 6:47 收件人: netmod@ietf.org 主题: Re: [netmod] ECA Policy: What is an adequate abstraction level to express policies and intent Hi - On 2021-03-17 4:15 AM, tom petch wrote: From: netmod on behalf of Randy Presuhn Sent: 10 March 2021 18:28 On 2021-03-10 12:43 AM, Juergen

Re: [netmod] ECA Policy: What is an adequate abstraction level to express policies and intent

Hi - On 2021-03-17 4:15 AM, tom petch wrote: From: netmod on behalf of Randy Presuhn Sent: 10 March 2021 18:28 On 2021-03-10 12:43 AM, Juergen Schoenwaelder wrote: Dear Qin, I believe this work repeats failures of the past but since the WG agreed to entertain this, I will keep my mouth

Re: [netmod] ECA Policy: What is an adequate abstraction level to express policies and intent

Hi - On 2021-03-10 12:43 AM, Juergen Schoenwaelder wrote: Dear Qin, I believe this work repeats failures of the past but since the WG agreed to entertain this, I will keep my mouth shut. I suggest you do not spend your energy to convince the that this work is viable since it is rather unlikely

Re: [netmod] Adoption poll for draft-wwx-netmod-event-yang-10

Hi - On 2020-12-29 12:31 PM, Andy Bierman wrote: ... I am not that interested in lessons from the past because it just sounds like an old-timer's negativity.  But I am not interested in boiling the ocean either. There is an invalid assumption with ECA that the current client development

Re: [netmod] Adoption poll for draft-wwx-netmod-event-yang-10

Hi - On 2020-12-29 8:26 AM, Adrian Farrel wrote: ... Since "intent-based networking" is a big thing once again (see recent reports of acquisitions in this sector) the excitement about ECA may be forgiven, but it would help to ground the discussions if those who can remember previous efforts

Re: [netmod] IETF 108: Summary of insignificant whitespace changes and versioning

Hi - On 8/12/2020 1:34 AM, Martin Björklund wrote: ... I think that comments should be treated as insignificant whitespace. Comments in YANG are not tied to a specific statement, so it is difficult to e.g. translate them to YIN properly. For example to which statement does the comment below

Re: [netmod] Alexey Melnikov's Discuss on draft-ietf-netmod-module-tags-07: (with DISCUSS)

Hi - On 2/17/2020 2:14 PM, Christian Hopps wrote: ... If you are talking about the property categories (where I see 'Z' mentioned as "All separators") then there doesn't appear to be a "lower means include, upper means exclude" relationship. Also it appears that to refer to one of these

Re: [netmod] Alexey Melnikov's Discuss on draft-ietf-netmod-module-tags-07: (with DISCUSS)

Hi - On 2/17/2020 11:47 AM, Christian Hopps wrote: On Feb 17, 2020, at 11:51 AM, Randy Presuhn wrote: Hi - On 2/17/2020 3:15 AM, Christian Hopps wrote: ... BTW, I did look at the "SHOULD be avoided" (occurs twice that I saw) once dealing with LFs and CRs which lucky for us i

Re: [netmod] Alexey Melnikov's Discuss on draft-ietf-netmod-module-tags-07: (with DISCUSS)

Hi - On 2/17/2020 3:15 AM, Christian Hopps wrote: ... > BTW, I did look at the "SHOULD be avoided" (occurs twice that I saw) once dealing with LFs and CRs which lucky for us is not part of a tags allowable characters. There are lots of other things that complicate life.  The Yang string

Re: [netmod] Alexey Melnikov's Discuss on draft-ietf-netmod-module-tags-07: (with DISCUSS)

Hi - On 2/14/2020 3:21 AM, Christian Hopps wrote: How about I add this to the description of "typedef tag" in the module: description "A tag is a type 'string' value that does not include carriage return, newline or tab characters. It SHOULD begin with a

Re: [netmod] x509c2n:cert-to-name problem

Hi - On Tue, Oct 29, 2019 at 10:53:49AM +0100, Martin Bjorklund wrote: Randy Presuhn wrote: Hi - On 10/28/2019 2:22 AM, Martin Bjorklund wrote: No, in many SMIv2 objects, a zero-length value is used for optional nodes (due to the way the protocol (SNMP) works). This comes

Re: [netmod] x509c2n:cert-to-name problem

Hi - On 10/28/2019 2:22 AM, Martin Bjorklund wrote: No, in many SMIv2 objects, a zero-length value is used for optional nodes (due to the way the protocol (SNMP) works). This comes as a complete surprise to me. References? Randy ___ netmod

Re: [netmod] Management Protocol Roles: Client/Server vs Manager/Agent

Hi - On 5/6/2019 8:24 AM, Schwarz Albrecht (ETAS/ESY1) wrote: The relevant role semantics originate at application level (and not at lower levels such as specific protocol layers), i.e., management applications (= the primary scope of NETCONF/RESTCONF). That (native) roles are defined in

Re: [netmod] 6021 ipv4-prefix

Hi - On 5/1/2019 12:46 PM, Mikael Abrahamsson wrote: Where is the text that tells the server implementor whether to throw an error when client commits non-zero bits, or to just throw the bits away and store the value in the canonical format? Such text would be an inappropriate constraint

Re: [netmod] 6021 ipv4-prefix

Hi - On 4/30/2019 1:46 AM, Mikael Abrahamsson wrote: Is it generally ok that the canonical value potentially represents a different bit field/value than what the client sent? The *value* represented is the same. The sequences of bytes used to represent that value may be different.

Re: [netmod] Obsolete feature - what does it mean?

Hi - On 2/27/2019 10:17 AM, Kent Watsen wrote: ... If so, then there should be a way for the server to indicate which discretionary choices it made.   I'd suggest that "obsolete" defaults to "not-implemented" and thus only servers that want to continue support for the node need to indicate

Re: [netmod] datastore-specific constraints

Hi - On 12/13/2018 3:58 AM, Ladislav Lhotka wrote: . SHOULD conform to any constraints specified in the data model, but given the principal aim of returning "in use" values, it is possible that constraints MAY be violated [...] According to the definition of SHOULD and MAY

Re: [netmod] Kathleen Moriarty's Discuss on draft-ietf-netmod-revised-datastores-09: (with DISCUSS)

Hi - On 1/12/2018 8:00 AM, Juergen Schoenwaelder wrote: On Fri, Jan 12, 2018 at 09:23:28AM -0500, Kathleen Moriarty wrote: Hi Juergen, On Fri, Jan 12, 2018 at 4:45 AM, Juergen Schoenwaelder wrote: On Thu, Jan 11, 2018 at 11:03:30AM -0500, Kathleen

Re: [netmod] Use feature to advertise pre-nmda-support {was: WG Last Call: draft-ietf-netmod-rfc7223bis-00 ]

Hi - On 12/1/2017 3:37 AM, Balazs Lengyel wrote: Hello, https://tools.ietf.org/html/rfc7950#section-7.21.2 o "deprecated" indicates an obsolete definition, but it permits new/continued implementation in order to foster interoperability with older/existing implementations.

Re: [netmod] Comment on draft-clacla-netmod-yang-model-update-02

Hi - On 11/15/2017 2:02 AM, Balazs Lengyel wrote: While a server may correctly support multiple versions, the human operator on the CLI has a 99% chance of mixing up which version he is using. Humans will not check every type and leaf  to check that they remember the little differences

Re: [netmod] rfc7223bis Backward compatibility in YANG - BAD !!!

Hi - On 11/9/2017 8:59 AM, Balazs Lengyel wrote: ... From an NMS point of view the current definition just states: Anything can be deprecated/obsoleted anytime. If something has a status different from current there is no guarantee its usable or even that it exists. Robust NMS software

Re: [netmod] revised-datastores and commonality of schemas

Hi - On 11/2/2017 2:12 PM, Sterne, Jason (Nokia - CA/Ottawa) wrote: I can’t think of a specific problem immediately.  But I think it means templates would be considered as “applied” always right ?  Or do you see cases where templates don’t show up when is read ? Pure speculation... consider

Re: [netmod] Action and RPC statements

Hi - On 10/31/2017 10:14 AM, Andy Bierman wrote: ... The system side effects are irrelevant, but both the same for rpc and action. Knowing what the system side effects are is *ESSENTIAL* if these things are to be of any use operationally. The only issues relevant to YANG are:    -

Re: [netmod] Action and RPC statements [was Re: augment YANG 1.0 with YANG 1.1 OK?]

Hi - On 10/26/2017 11:42 AM, Andy Bierman wrote: On Thu, Oct 26, 2017 at 11:22 AM, Randy Presuhn <randy_pres...@alumni.stanford.edu <mailto:randy_pres...@alumni.stanford.edu>> wrote: Hi - On 10/26/2017 10:44 AM, Robert Wilton wrote: Hi , Separating o

Re: [netmod] Action and RPC statements [was Re: augment YANG 1.0 with YANG 1.1 OK?]

Hi - On 10/26/2017 10:44 AM, Robert Wilton wrote: Hi , Separating out the issue regarding which datastore action and RPC apply to, we propose the following NEW text to the datastores draft: 6.2 Invocation of Actions and RPC Operations This section updates section 7.15. of RFC 7950.

Re: [netmod] upcoming adoptions - this appendix is normative

Hi - On 10/2/2017 7:18 AM, Robert Wilton wrote: This discussion may be conflating two issues: (i) Does RFC text have to use RFC2119 terms to be normative? RFC 8174 categorically states that text can still be normative without using RFC 2119 terms. Thus it's clear that their usage is not

Re: [netmod] draft-ietf-netmod-entity issue #13

Hi - On 12/21/2016 6:56 AM, Martin Bjorklund wrote: ... This procedure would change how serial-num currently is handled. I don't have a strong opinion on this, but I note that serial-num is writable in the ENTITY-MIB. Maybe someone can comment on why it is writable in the MIB, and if this is

Re: [netmod] draft-ietf-netmod-entity issue #11

Hi - On 12/16/2016 12:53 AM, Martin Bjorklund wrote: Randy Presuhn <randy_pres...@alumni.stanford.edu> wrote: Hi - My recollection is that part of the motivation for the use of zero-length strings as sentinel values in situations like this in MIB modules (rather than skipping the

Re: [netmod] draft-ietf-netmod-entity issue #11

Hi - My recollection is that part of the motivation for the use of zero-length strings as sentinel values in situations like this in MIB modules (rather than skipping the object instance) was to permit a clear distinction between "information not available" and "access denied". Randy On

Re: [netmod] RFC 6087bis guidance re use of revision statements in drafts

each time a new version (e.g., of the Internet-Draft) is posted. Lada —— Comments? On 11 Aug 2016, at 17:26, Randy Presuhn <randy_pres...@alumni.stanford.edu> wrote: Hi - I read the text as intended to make a distinction between the *date* portion and the rest of the revision state

Re: [netmod] RFC 6087bis guidance re use of revision statements in drafts

unpublished versions (e.g., Internet-Drafts), but the revision date (i.e., the revision statement’s argument) MUST be updated to a higher value each time a new version (e.g., of the Internet-Draft) is posted. —— Comments? On 11 Aug 2016, at 17:26, Randy Presuhn <randy_pres...@alumni.stanford.

Re: [netmod] RFC 6087bis guidance re use of revision statements in drafts

dates in YANG modules contained within IDs. William PS, I think that the removal of this text removes the contradiction because in order to make sense of the sentence the reader will be forced to the conclusion that IDs are not regarded as being “unpublished”. On 11 Aug 2016, at 17:07, Randy

Re: [netmod] RFC 6087bis guidance re use of revision statements in drafts

Hi - The situation with Internet-Drafts is what motivated this text in the first place, so I think it is important to retain that information. However, it seems to me that the "i.e." is too limiting, and should be replaced with an "e.g.". Randy On 8/11/2016 2:06 AM, William Lupton wrote:

Re: [netmod] Request to review the YANG compiler annotations draft.

Hi - Some lessons learned from annotating SMI files for code generation are probably applicable here. (1) doing annotations "in-line", regardless of the grammatical tricks used to support those annotations, is problematic from a software configuration management perspective.

Re: [netmod] list keys out of order

Hi - > From: Andy Bierman > Sent: Jun 22, 2016 8:47 AM ... > Subject: Re: [netmod] list keys out of order ... > I checked our server and it accepts any node out of order, > including keys,so I agree out-of-order keys SHOULD be accepted. "SHOULD" isn't helpful from an interoperability

Re: [netmod] Stephen Farrell's No Objection on draft-ietf-netmod-yang-json-09: (with COMMENT)

Hi - >From: Juergen Schoenwaelder >Sent: Mar 22, 2016 9:23 AM >To: Eliot Lear >Cc: "netmod-cha...@ietf.org" , "netmod@ietf.org" >, "draft-ietf-netmod-yang-j...@ietf.org"

Re: [netmod] I-D Action: draft-ietf-netmod-opstate-reqs-02.txt

Hi - >From: Ladislav Lhotka >Sent: Jan 26, 2016 6:50 AM >To: Robert Wilton >Cc: "netmod@ietf.org" >Subject: Re: [netmod] I-D Action: draft-ietf-netmod-opstate-reqs-02.txt >... >This can IMO work only if the schemas of configuration and >state

Re: [netmod] whitespace characters

Hi - This got me thinking - would "U+202A U+202B" thus be a valid argument, distinct from, say, "U+202B U+202A"? Randy -Original Message- >From: Ladislav Lhotka >Sent: Dec 28, 2015 12:23 AM >To: NETMOD WG >Subject: [netmod] whitespace characters > >Hi,

Re: [netmod] NETMOD WG LC: draft-ietf-netmod-opstate-reqs-01

Hi - >From: Juergen Schoenwaelder >Sent: Dec 28, 2015 6:24 AM >To: Robert Wilton >Cc: "netmod@ietf.org" >Subject: Re: [netmod] NETMOD WG LC: draft-ietf-netmod-opstate-reqs-01 > >On Wed, Dec 23, 2015 at

Re: [netmod] NETMOD WG LC: draft-ietf-netmod-opstate-reqs-01

Hi - > From: Robert Wilton > Sent: Dec 17, 2015 1:12 PM > To: Andy Bierman > Cc: "netmod@ietf.org" > Subject: Re: [netmod] NETMOD WG LC: draft-ietf-netmod-opstate-reqs-01 ... > Your requirement is a bit too strong for my liking. > > To paraphrase your requirement text, it is forcing that

Re: [netmod] JSON encoding of anyxml

Hi - > From: Robert Wilton > Sent: Nov 17, 2015 2:19 AM ... >As a possible compromise, what about something like: > >The JSON encoding defines that anyxml may be encoded in whatever way >the implementor finds useful, or even not at all. If a preferred >custom encoding is not

Re: [netmod] JSON encoding of anyxml

Hi - >From: Juergen Schoenwaelder >Sent: Nov 11, 2015 5:44 AM >To: Ladislav Lhotka >Cc: netmod@ietf.org >Subject: Re: [netmod] JSON encoding of anyxml ... >Observations: > > - Except b), none of the options is interoperable. Option d) is >

Re: [netmod] general permission on metadata

Hi - >From: Juergen Schoenwaelder >Sent: Nov 3, 2015 9:50 PM >To: Ladislav Lhotka >Cc: NETMOD WG >Subject: Re: [netmod] general permission on metadata > >Lada, > >I do not think this belongs into the YANG specification. NC

Re: [netmod] netmod-opstate-reqs: Are 2.A. and 4.C. the same thing ? (derived + non-derived)

Hi - > From: "Sterne, Jason (Jason)" > Sent: Nov 3, 2015 12:02 AM > To: "netmod@ietf.org" > Subject: [netmod] netmod-opstate-reqs: Are 2.A. and 4.C. the same thing ? > (derived + non-derived) ... > But isn’t 4.C. also a repeat of 2.A. ? > > 2.A.: The ability to retrieve the applied

Re: [netmod] leaf-list uniqueness requirement for non-config nodes

Hi - >From: Juergen Schoenwaelder >Sent: Oct 29, 2015 1:06 AM >To: netmod@ietf.org >Subject: [netmod] leaf-list uniqueness requirement for non-config nodes > >Hi, > >RFC 6020 say: > > The values in a leaf-list MUST be unique. > >While this may have a

Re: [netmod] Yang 1.0/1.1 ABNF Grammar:

Hi - >From: Martin Bjorklund <m...@tail-f.com> >Sent: Oct 23, 2015 12:24 AM >To: randy_pres...@mindspring.com >Cc: netmod@ietf.org >Subject: Re: [netmod] Yang 1.0/1.1 ABNF Grammar: rule ...> > >Randy Presuhn <randy_pres...@mindspring.com> wrote: >> Hi -

Re: [netmod] Yang 1.0/1.1 ABNF Grammar:

Hi - >From: Martin Bjorklund >Sent: Oct 22, 2015 6:20 AM >To: lho...@nic.cz >Cc: netmod@ietf.org >Subject: Re: [netmod] Yang 1.0/1.1 ABNF Grammar: rule ...> ... >> > 2. Similarly for import-stmt. Should this have a comment indicating that >> > prefix-stmt or revision-date-stmt

Re: [netmod] opstate-reqs #5: Support for situations when structure of intended configuration is not the same as applied

Hi - >From: "Einar Nilsen-Nygaard (einarnn)" >Sent: Oct 20, 2015 5:17 AM >To: Martin Bjorklund >Cc: "netmod@ietf.org" >Subject: Re: [netmod] opstate-reqs #5: Support for situations when structure >of intended configuration is not the same

Re: [netmod] 6020bis extensions

Hi - >From: Juergen Schoenwaelder >Sent: Oct 18, 2015 5:52 AM >To: Martin Bjorklund >Cc: a...@yumaworks.com, randy_pres...@mindspring.com, netmod@ietf.org >Subject: Re: [netmod] 6020bis extensions ... >I could copy the text of the

Re: [netmod] opstate-reqs #3: Is there a requirement for asynchronous systems to provide a blocking config update?

Hi - > From: Robert Wilton > Sent: Oct 16, 2015 5:12 AM > To: Kent Watsen , Nadeau Thomas > Cc: "netmod@ietf.org" > Subject: Re: [netmod] opstate-reqs #3: Is there a requirement for > asynchronous systems to provide a blocking config update? ... >Here is my attempt at word smithing section

Re: [netmod] 6020bis more than one revision of a module

Hi - >From: David Reid >Sent: Oct 9, 2015 2:03 PM >To: netmod@ietf.org >Subject: [netmod] 6020bis more than one revision of a module > >I'm reviewing 6020bis since it is in working group last call. >I see a new requirement that a server MUST NOT implement >more than one revision

Re: [netmod] 6020bis more than one revision of a module

Hi - >From: Juergen Schoenwaelder <j.schoenwael...@jacobs-university.de> >Sent: Oct 13, 2015 1:06 PM >To: Randy Presuhn <randy_pres...@mindspring.com> >Cc: netmod@ietf.org >Subject: Re: [netmod] 6020bis more than one revision of a module > >On Tue, Oct 13, 2015 a

Re: [netmod] opstate-reqs issue #1 - Define/Clarify "fully synchronized" in "Requirement 1.D"

Hi - >From: Robert Wilton >Sent: Oct 1, 2015 10:01 AM >To: "netmod@ietf.org" >Subject: [netmod] opstate-reqs issue #1 - Define/Clarify "fully synchronized" >in "Requirement 1.D" > >To clarify what I failed to eloquently express in the interim meeting. > >I

Re: [netmod] 6020bis - anydata

Hi - >From: Ladislav Lhotka <lho...@nic.cz> >Sent: Oct 1, 2015 12:24 AM >To: Juergen Schoenwaelder <j.schoenwael...@jacobs-university.de> >Cc: Randy Presuhn <randy_pres...@mindspring.com>, netmod@ietf.org >Subject: Re: [netmod] 6020bis - anydata ... >Fine b

Re: [netmod] I-D Action: draft-ietf-netmod-rfc6020bis-07.txt

Hi - >From: Martin Bjorklund >Sent: Sep 28, 2015 3:15 AM >To: jern...@mg-soft.si >Cc: netmod@ietf.org >Subject: Re: [netmod] I-D Action: draft-ietf-netmod-rfc6020bis-07.txt ... >Ok; the intention was "replace if it exists, and create otherwise" >(i.e., "replace" as in NETCONF

Re: [netmod] Fwd: New Version Notification for draft-ietf-netmod-yang-json-05.txt

Hi - >From: Ladislav Lhotka <lho...@nic.cz> >Sent: Sep 15, 2015 11:03 PM >To: Randy Presuhn <randy_pres...@mindspring.com>, NETMOD Working Group ><netmod@ietf.org> >Subject: Re: [netmod] Fwd: New Version Notification for >draft-ietf-netmod-yang-json-05.txt

Re: [netmod] Fwd: New Version Notification for draft-ietf-netmod-yang-json-05.txt

Hi - >From: Juergen Schoenwaelder >Sent: Sep 14, 2015 11:41 PM >To: Ladislav Lhotka >Cc: NETMOD Working Group >Subject: Re: [netmod] Fwd: New Version Notification for >draft-ietf-netmod-yang-json-05.txt ... >My question is

Re: [netmod] Y26 again, sorry

Hi - >From: Ladislav Lhotka <lho...@nic.cz> >Sent: Sep 10, 2015 2:02 AM >To: Randy Presuhn <randy_pres...@mindspring.com>, netmod@ietf.org >Subject: Re: [netmod] Y26 again, sorry > >Randy Presuhn <randy_pres...@mindspring.com> writes: > >> Hi - >&

Re: [netmod] Motivations for Structuring Models

Hi - >From: "Alexander Clemm (alex)" <a...@cisco.com> >Sent: Sep 1, 2015 2:21 PM >To: Randy Presuhn <randy_pres...@mindspring.com>, "netmod@ietf.org" ><netmod@ietf.org> >Subject: RE: [netmod] Motivations for Structuring Models > >Hi R

Re: [netmod] Y26 again, sorry

Hi - From: Ladislav Lhotka lho...@nic.cz Sent: Aug 24, 2015 11:44 AM To: Andy Bierman a...@yumaworks.com Cc: netmod@ietf.org netmod@ietf.org Subject: Re: [netmod] Y26 again, sorry ... YANG does not provide any mechanism to REQUIRE modules A and B to both be implemented on a server. You may

Re: [netmod] Y34 - root node

Hi - From: Andy Bierman Sent: Aug 18, 2015 10:22 AM To: Robert Wilton Cc: NETMOD Working Group Subject: Re: [netmod] Y34 - root node On Tue, Aug 18, 2015 at 9:59 AM, Robert Wilton rwil...@cisco.com wrote: ... I think that having fixed paths may end up being too restrictive. This is how

Re: [netmod] Constraint on mandatory on nodes as part of augmentation in RFC6020bis

Hi - From: Ladislav Lhotka lho...@nic.cz Sent: Aug 16, 2015 12:52 AM To: Randy Presuhn randy_pres...@mindspring.com, netmod@ietf.org netmod@ietf.org Subject: Re: [netmod] Constraint on mandatory on nodes as part of augmentation in RFC6020bis ... I think a better analogy would be to how row

Re: [netmod] Constraint on mandatory on nodes as part of augmentation in RFC6020bis

Hi - I know netmod isn't object-oriented, but I think viewing this through the lens of conformance might be causing us to miss the conflicting requirements that lead the group to this impasse. RFC 6020 effectively presents us with a way of defining instantiable classes, and augment functions as

Re: [netmod] Constraint on mandatory on nodes as part of augmentation in RFC6020bis

Hi - From: Andy Bierman Sent: Aug 15, 2015 10:55 AM To: Randy Presuhn Cc: netmod@ietf.org Subject: Re: [netmod] Constraint on mandatory on nodes as part of augmentation in RFC6020bis ... I have been trying to change the meta-model (with YANG packages). But that does not fix the problem