Re: [netmod] WG Last Call: draft-ietf-netmod-rfc7223bis-00

All, This last call is now closed. Since the comments were minor, this last call is considered successful. Authors, Please address any/all comments received during the LC. Once you've published the version that you believe addresses all comments/pending changes, I'll perform

Re: [netmod] WG Last Call: draft-ietf-netmod-rfc7277bis-00

All, This last call is now closed. Since the comments were minor, this last call is considered successful. Authors, Please address any/all comments received during the LC. Once you've published the version that you believe addresses all comments/pending changes, I'll perform

Re: [netmod] intended status of the tree diagram document

BCP for tree-diagrams? This doesn't seem like an appropriate application of that designation. I don't view the format for tree diagrams to be a "practice", whereas it definitely seems "informational". Looking more deeply at RFC2026, I can see how Section's 4.2.2's "...does not represent an

[netmod] referencing the tree-diagrams draft

All, Looking at a few drafts going through last call currently, I notice that they all define their own "Tree Diagrams" section rather than reference the tree-diagrams draft: https://tools.ietf.org/html/draft-ietf-netmod-entity-05#section-1.1.1

Re: [netmod] WG Last Call: draft-ietf-netmod-entity-05

All, Picking up on Juergen's comment: > If these deprecated objects are essential for BBF (please confirm), > then it might be better to define them in a separate module... I agree that the objects should be defined in a separate module. The request, as I understand it, is for there be an

[netmod] WG Last Call: draft-ietf-netmod-rfc7277bis-00

All, This starts a two-week working group last call on draft-ietf-netmod-rfc7277bis-00. Please recall that this update's intention is to modify the YANG module to be in line with the NMDA guidelines [1]. Reviewing the diff between the two drafts [2] should reveal just this. The working

[netmod] WG Last Call: draft-ietf-netmod-rfc7277bis-00

[resending] All, This starts a two-week working group last call on draft-ietf-netmod-rfc7277bis-00. Please recall that this update's intention is to modify the YANG module to be in line with the NMDA guidelines [1]. Reviewing the diff between the two drafts [2] should reveal just this.

[netmod] WG Last Call: draft-ietf-netmod-rfc7223bis-00

All, This starts a two-week working group last call on draft-ietf-netmod-rfc7223bis-00. Please recall that this update's intention is to modify the YANG module to be in line with the NMDA guidelines [1]. Reviewing the diff between the two drafts [2] should reveal just this. The working group

[netmod] FW: [100all] IETF 100 Final Agenda Changes

All, Per the message below, please note that both NETMOD sessions tomorrow are now in Sophia. In particular, the first session is no longer in Padang. Thanks, Kent (and Lou) -- Hi Everyone! Below are changes to the final agenda. As always, the most up to date version of the agenda is

Re: [netmod] review of draft-ietf-netmod-schema-mount-08

> Hi Kent, > > thanks for the thorough review, see my responses inline. Hi Lada, please see below. >> 1. From Section 4: >> >>Routing configuration inside an NI often needs to refer to interfaces (at >>least those that are assigned to the NI), which is impossible unless such >>a

Re: [netmod] WG Last Call: draft-ietf-netmod-acl-model-14

This closes the Last Call on this document. There is clearly a lot of interest in the publication of an ACL model, but there also seems to be significant concern for how this model is structured. It seems that we need to spend some more time to ensure the current structure is okay. Based on

Re: [netmod] WG Last Call: draft-ietf-netmod-schema-mount-08

This closes the schema-mount Last Call. Looking at the responses, there is strong support for publication after a variety of Last Call comments have been addressed, some threads of which may still be ongoing. The authors should post an update addresses the Last Call comments followed by a

[netmod] review of draft-ietf-netmod-schema-mount-08

Hi, I have read this document and think that is almost ready for publication. I have five discuss items and a bunch of nits. Kent // contributor 1. From Section 4: Routing configuration inside an NI often needs to refer to interfaces (at least those that are assigned to the NI), which

[netmod] draft agenda posted

The draft agenda for the NETMOD sessions has been posted: https://datatracker.ietf.org/meeting/100/materials/agenda-100-netmod/ There are no sessions listed for the three NMDA-update model drafts (rfc7223bis, rfc7277bis, rfc8022bis). They will be covered together by the chairs in the

Re: [netmod] Action and RPC statements

Hi Robert, > 6.2 Invocation of RPC Operations > > This section updates section 7.14 of RFC 7950. > > RPCs MAY be defined as affecting the contents of a specific datastore, > any configuration datastore (e.g., ), or any datastore > (e.g., ).  The RPC definition specifies how the RPC input >

Re: [netmod] WG adoption poll draft-acee-netmod-rfc8022bis-03

This poll is now closed. draft-acee-netmod-rfc8022bis-03 is adopted. Authors, as discussed below, please resubmit acee-03 as ietf-00. Since the submission window has closed, the chairs will ask for a submission-exception. Please, shortly after submitting the -00, submit a -01 per below

Re: [netmod] I-D Action: draft-ietf-netmod-yang-tree-diagrams-02.txt

complexity of trees substantially and directs focus to the forest, not the trees - really ultimately the intent of this. --- Alex > -Original Message- > From: netmod [mailto:netmod-boun...@ietf.org] On Behalf Of Kent Watsen > Sent: Wednesday, October 25, 2017 5:06 PM > To:

Re: [netmod] I-D Action: draft-ietf-netmod-yang-tree-diagrams-02.txt

>From another thread in NETCONF, Juergen writes: I do not know whether the official tree diagram formats will have ways to show say a container with used groupings collapsed. This may actually be useful sometimes, but this is not what you are look for here either. I am thinking about

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

Added. https://github.com/netmod-wg/yang-next/issues/30 K. On 10/23/17, 1:41 PM, "Andy Bierman" > wrote: Hi, To be clear, I am withdrawing this errata because existing implementations may not accept a numeric literal in an instance-identifier. I

Re: [netmod] WG Last Call: draft-ietf-netmod-schema-mount-08

[changing subject line] All, Please use the just-posted -08 version instead. In addition to changing the subject line, I also changed the text below. The end date remains unchanged. Regards, Kent // co-chair -- All, This starts a two-week working group last call on

[netmod] WG Last Call: draft-ietf-netmod-schema-mount-07

All, This starts a two-week working group last call on draft-ietf-netmod-schema-mount-07. The working group last call ends on November 3. Please send your comments to the netmod mailing list. Positive comments, e.g., "I've reviewed this document and believe it is ready for publication", are

[netmod] WG Last Call: draft-ietf-netmod-acl-model-14

All, This starts a two-week working group last call on draft-ietf-netmod-acl-model-14. The working group last call ends on November 3. Please send your comments to the netmod mailing list. Positive comments, e.g., "I've reviewed this document and believe it is ready for publication", are

[netmod] can a 'must' statement point to a 'choice' node?

I'm getting mixed results from pyang and yanglint. Can the XPath used in a 'must' statement point to a 'choice' node? In the below YANG snippet from the zerotouch draft, the idea is that, if at least one URI is specified, then a hash needs to be present as well, but any hash is okay,

Re: [netmod] WG Last Call: draft-ietf-netmod-rfc6087bis-14

ine canonical order of YANG statements. Thanks --- Alex -Original Message----- From: netmod [mailto:netmod-boun...@ietf.org] On Behalf Of Kent Watsen Sent: Tuesday, September 12, 2017 11:22 AM To: netmod@ietf.org Cc: netmod-cha...@ietf.org; draft-ietf-netmod-rfc6087...@ietf.org Subject: [netmo

Re: [netmod] draft-ietf-netmod-rfc6087bis as a BCP?

Hi Benoit, et al., As a contributor, I support your proposal to move rfc6087bis to BCP, and I know that Lou does as well (I just asked him). As co-chair, reading Section 6.1.1 of RFC 2026, I feel that we need to formally run the decision past the WG. So, without further ado: This is the

[netmod] FW: Liaison letter to IETF Netmod Working Group regarding NMDA modelling

All, We received this liaison a couple weeks ago. Although it has not yet been formally submitted, we like to provide a response anyway. As this request equally impacts both the NETMOD and NETCONF working groups, we request that that both working groups collaborate on a response. Thanks, Kent

[netmod] WG adoption poll draft-acee-netmod-rfc8022bis-03

All, Now that we have resolved the module naming issue on the list (i.e. that keeps the original rfc module names and updates the unwanted legacy nodes to have status 'obsolete'), rather than wait for the changes to be made in the individual document, we'd like to move ahead with the adoption

Re: [netmod] ietf-routing or ietf-routing-2? module naming convention for NMDA transition. Re: upcoming adoptions

I agree - let's keep the module name and mark the nodes obsolete. Kent // any hat Robert Wilton wrote: > > > On 09/10/2017 22:06, Benoit Claise wrote: > > On 10/6/2017 6:01 PM, Robert Wilton wrote: > >> > >> > >> On 06/10/2017 16:32, Martin Bjorklund wrote: > >>> Benoit

Re: [netmod] Retrieving Information Pointed by leafref

[Sorry, fat-fingered the send button] Here's how the paths might be altered: - ../../../../../explicit-paths/explicit-path/name + /explicit-paths/explicit-path/name Back to your question, I guess that something could be done, but I'm unsure if how important it would be relative to other work

Re: [netmod] Retrieving Information Pointed by leafref

My experience is that clients get the entire config in one call, and then can perform such resolutions locally. BTW, really long relative paths are harder to read than an absolution path. ../../../../../explicit-paths/explicit-path/name On 10/6/17, 5:11 PM, "netmod on behalf of Xufeng Liu"

Re: [netmod] handling module incompatibility

>> As part of the my Routing Directorate review of >> draft-wu-l3sm-rfc8049bis I noted that there were several incompatible >> changes being made to the ietf-l3vpn-svc module without changing the >> name. I raised this with the YANG doctors and others involved with the >> draft and it

Re: [netmod] WG Last Call: draft-ietf-netmod-rfc6087bis-14

The Last Call for this document has completed with *no* responses, other than Benoit's question regarding if it should be a BCP, which also had no responses, other than my own wondering if YANG (and hence the guidelines) was stable enough. Lou and I discussed. It is our opinion that, given

Re: [netmod] Backward Compatibility Question

Hi Joey, Your proposal looks fine to me, since it doesn't change the semantics of the data model. Note that https://tools.ietf.org/html/rfc7950#section-11 says: o Any set of data definition nodes may be replaced with another set of syntactically and semantically equivalent nodes.

Re: [netmod] upcoming adoptions

> A new module name mandates a new namespace, so they go together. > Abandoning the old module is fine, except leaving that module with > status "current" is not fine. IMO you need to republish the old module > as well, with everything status obsolete. Agreed. If a new module-name is used

Re: [netmod] Adding system configuration to running [was: Re: Comments on NMDA-04]

> I agree with Balazs that system-created nodes in running are quite common and > the vendors doing it have no intention of changing it. Of course, what else were they going to do pre-NMDA…and also before require-instance false? Green-field deployments wouldn't be encumbered with

Re: [netmod] syslog-model-17 shepherd writeup issues -references

I meant to say something about the .1 vs .2 difference. My comment assumes that it's supposed to be .1, but we of course should use whatever is correct. I also don't know much about that standards body. K. - Original Message - From: "Kent Watsen" <kwat...@juniper.net>

Re: [netmod] upcoming adoptions

> So rfc8022bis-02 publishes the v2 module, and the the deprecated version > of the v1 module as an appendix? Lou and I were just discussing if appendix can be normative or not. I always thought no, but I haven't checked. This is a grey area, in that understanding that the old module is

Re: [netmod] upcoming adoptions

chanisms than just replacing the RFC, e.g., by updating the old modules with all nodes marked as deprecated. I think you're right that this could be done post adoption. Of course others are free to disagree. I check with Kent and see what he thinks. Thanks, Lou > > Thanks, > Rob > >

Re: [netmod] syslog-model-17 shepherd writeup issues -references

ibed here: http://www.regular-expressions.info/catastrophic.html Thanks, Rob On 13/09/2017 18:08, Kent Watsen wrote: > Hi Tom, > > Thanks. The fix I'm looking for is for the 'pattern-match' leaf > to have a 'reference' statement to Std-1003.1-2008, and for S4.1 > to also list Std-

[netmod] syslog-model-17 shepherd writeup issues

Clyde, all, In reviewing the draft for Shepherd writeup, I found the following issues that I think need to be addressed before the document can be sent to Benoit for AD review: 1. Idnits found the following: Summary: 3 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). **

Re: [netmod] draft-ietf-netmod-rfc6087bis as a BCP?

Hi Benoit, BCP seems right, but I wonder if there is some sort of stability metric that applies to BCPs. YANG still seems to be evolving, so I can only imagine yet another update to this document in the not too distant future. Does that disqualify it in any way? Kent On 9/11/17, 10:16 AM,

[netmod] WG Last Call: draft-ietf-netmod-rfc6087bis-14

This starts a two-week working group last call on: Guidelines for Authors and Reviewers of YANG Data Model Documents https://tools.ietf.org/html/draft-ietf-netmod-rfc6087bis-14 Please send email to the list indicating your support or concerns. We are particularly interested in

Re: [netmod] AD review: draft-ietf-netmod-syslog-model-17

> I understand that draft-ietf-netmod-syslog-model should be on my plate very > soon (waiting for the WriteUp) Yep, this one's on me - I'm looking into it today. > In terms of YANG doctor > review, > Kent,

Re: [netmod] WG Last Call: draft-ietf-netmod-revised-datastores-04

As an author, I believe the draft is ready for publication. Regarding Robert's editorial suggestions: 1) how moving "all" like this? (i.e., must have same modules, deviations, etc.) - datastores that all share exactly the same schema, allowing data to be copied + datastores that share

Re: [netmod] [NETMOD] YANG Data Module

Hi Sudhanshu, Welcome to NETMOD! I'm sure the WG is looking forward to learning more about your ideas. In order to bring a YANG module to the WG's attention, you should write a draft that describes your YANG module and submit it using the draft- submission tool

Re: [netmod] two options for removing /foo-state trees?

>>Does this mean you're okay reposting your ID similar to Martin's? >>I ask as a chair interested in starting the adoption process on >>these nmda-update drafts. > > I would hope this is not a prerequisite? We are evaluating how bad this > will be. I’d ask how many implementations there are of

Re: [netmod] two options for removing /foo-state trees?

Hi Acee, > Ok - it is less painful if we only have to deprecate the *-state nodes. Does this mean you're okay reposting your ID similar to Martin's? I ask as a chair interested in starting the adoption process on these nmda-update drafts. > However, what about secondary and tertiary

Re: [netmod] upcoming adoptions

>> /netconf-state and /restconf-state don't seem to follow the general >> pattern we're correcting with the various NMDA updates.  Particularly, >> these -state trees are NOT for the purpose to providing the opstate >> value for configured nodes.  These modules have the misfortune of >> having

[netmod] two options for removing /foo-state trees?

[changing subject line, was "upcoming adoptions"] We've been primarily focused on updating modules by deprecating the /foo-state tree in situ. This is what the nmda-guidelines draft said to do and is much of what the "status statement needed on every node" thread regards. However, the RTG YANG

Re: [netmod] upcoming adoptions

>> I guess the NMDA transition plan to move the child nodes to a config=true >> node >> name /restconf that has only config=false nodes in it. This seems quite >> disruptive >> and not a productive use of engineering resources, or support and customer >> re-training. > > I agree with you. We've

Re: [netmod] 'status' statement needed on every node

>> I still don't know what it means to define hierarchical data and say the >> parent is deprecated but not the descendant nodes. > > It is odd but can happen anyway. A current augmentation of something > that got deprecated likely stays current. I would hope that tools warn > if they see this

[netmod] 'status' statement needed on every node

With all the deprecating of "-state" trees going on these days, the 'status' statement is getting lots of use. I understand that some feel that the status statement needs to be placed on every node, since it is not inherited. This sentiment likely stems from RFC 7950 stating "If no status is

Re: [netmod] regarding draft-bierman-netmod-yang-data-ext-00

>> Gotcha. What do other people think, would a "uses-yang-data" >> statement be generally more useful? > > But does this mean we also do uses-yang-container, uses-yang-list, > uses-yang-xyz to other definitions as well? I do not think this is > desirable and why would yang-data be any

Re: [netmod] regarding draft-bierman-netmod-yang-data-ext-00

> I am not sure any new construct is needed at all. > The current definition covers it. Right, this is what is currently being done, but it is neither intuitive nor conducive to downstream extensions… > We went through that issue at least twice before RFC 8040. > There was no concern about

[netmod] regarding draft-bierman-netmod-yang-data-ext-00

I'd like to start a discussion about adopting this draft...or something like it (see below). The primary driver for wanting to expedite this draft is that it is being discussed as a required aspect of a chartered NETCONF WG effort to define a new encoding for YANG's 'notification' statement.

Re: [netmod] Potential additions to rfc6087bis: RegEx guidelines

As Andy says, readability is #1, and it follows that a restricted subset would be more understandable. Standardizing this would require an update to RFC 7950 (read: not going to happen anytime soon). Maybe we could start with just having a tool detect when something outside the common-subset

[netmod] upcoming adoptions

Hey folks, As discussed at the last meeting, we are heading to revising existing RFCs to align them with NMDA. The first batch have been published as individual drafts: 1. https://tools.ietf.org/html/draft-bjorklund-netmod-rfc7223bis-00 2.

Re: [netmod] rfc6087bis S4.23 replacement text

> rather confusing, since this notation is not defined anywhere. A bit, yes. I tried to get the syntax defined in RD, but my co-authors didn't think it was necessary. I acquiesced as well just to move things along. > If the term 'state' added any value, we would use it more often, but I

Re: [netmod] rfc6087bis S4.23 replacement text

>> I know that we tend to be sloppy in meetings and often in emails but >> in written RFCs (specifications) I would personally prefer to use a >> single term. > > So change it in the RD draft to the term we actually use "operational > datastore". A lot of effort went into defining the terms.

Re: [netmod] Regarding IPR on draft-ietf-netmod-revised-datastores-04

No, I'm not aware of any IPR that applies to this draft. K. Sent from my iPhone > On Aug 25, 2017, at 4:20 PM, Lou Berger wrote: > > Authors, Contributors, WG, > > As part of the preparation for WG Last Call: > > Are you aware of any IPR that applies to drafts identified

Re: [netmod] rfc6087bis S4.23 replacement text

On 8/25/17, 2:21 PM, "Andy Bierman" > wrote: > Obviously NMDA cannot be used for objects where the configuration value set > and the operstate value set differ, such as with the interface > admin-status/oper-status. > Do you want a sentence added

Re: [netmod] rfc6087bis S4.23 replacement text

g., for typedef > definitions) > - modify any imports, used for leafrefs or identityrefs, to > import the -state version of the module > - remove any 'typedef' or 'identity' definitions > - prefix any uses of the typedefs and identities accordingly > -

Re: [netmod] rfc6087bis S4.23 replacement text

e > >> original module's name > >> - Change the namespace by postpending "-state" to the original > >> namespace value > >> - Change the prefix by postpending "-s" to the original prefix > >> value &

[netmod] rfc6087bis S4.23 replacement text

Hi, During the meeting in Chicago, the NMDA authors took an action to propose some text for S4.23. After a little review, the following emerged. Yes, it's short, but was anything left anything out? =START= 4.23 Operational Data Operational data includes both config "false" nodes

Re: [netmod] WG Last Call for draft-ietf-netmod-syslog-model-15

Hi Clyde, Trimming down to just the active discussion points. > 12. S3, P8: I'm having trouble understanding the pseudocode. What >happens if S and/or F are not present? Can S or F ever not be >present? - looking at the tree diagram, it seems like they might >

Re: [netmod] WG Last Call for draft-ietf-netmod-syslog-model-15

>5. S1 as a whole. I'm a bit unclear what this section is doing. It >seems to be a general summary of Syslog (RFC5424). Do we need this here? > > [clyde] Suggestions appreciated. I wanted to provide a high level overview > of the syslog process. I cleaned it up a little. Move

Re: [netmod] WG Last Call for draft-ietf-netmod-syslog-model-15

Today's activity on this thread necessitates another response as well: The WG LC is closed. Authors, please address any comments that have been received, and let the WG know how the issues have been addressed, and when a version is available that is ready to be submitted for publication.

Re: [netmod] WG Last Call for draft-ietf-netmod-syslog-model-15

> "This container describes the configuration parameters for >forwarding syslog messages to remote relays or collectors."; > > I will revise the description of these terms in the next draft. > > Thanks, > > Clyde &g

[netmod] ietf 99 minutes posted

The minutes for the IETF 99 NETMOD sessions have been posted. https://datatracker.ietf.org/meeting/99/materials/minutes-99-netmod Thank-you Michael for reviewing the recordings to ensure completeness and accuracy! Kent ___ netmod mailing list

Re: [netmod] [Netconf] NMDA comments

Hi Balazs, > General: It should be more clearly describe how legacy devices that do > not wish to support NMDA should behave. They still need part of the > operational datastore, but might not (will probably not) have a separate > operational state for configuration from running/intended.

Re: [netmod] accessible tree for rpcs?

> That's what I meant. > RPC input MUST be honored by the server or it is not implementing > correctly. > > Constraints on RPC output and notification output are for documentation > purposes. > A client could try to evaluate them with its own copies of the server's > running and >

Re: [netmod] accessible tree for rpcs?

Hi Alex, > Why would it not make sense? Firstly, it seems outside the norm. At least, I'm unaware of any other IDL that allows for such linkage. Second, I'm trying to understand the value. For instance, how does it benefit the module designer, the server developer, the client developer?

Re: [netmod] nmda-guidelines-01: value space for config vs state

Hi Lada, I agree that there is a close alignment but then I guess NETMOD should have started with a different approach, perhaps object-oriented rather than document-oriented, where configuration could play the role of "methods" intended for changing the object's state. (If Randy Presuhn was

Re: [netmod] nmda-guidelines-01: value space for config vs state

> Do we need to call this/these scenarios out directly > in the NMDA draft? Or is this more of an FAQ item? I support putting it in the NMDA draft. Already I looked for an example in the Appendix, which I thought might be there, given how often I know the NMDA-authors discussed it. But,

Re: [netmod] datastore conformance

> I am still concerned that the datastore conformance requirements are > under-specified and too server-centric. Okay. > The YANG definitions defined for NETCONF and RESTCONF operations > do not actually require the "real" datastore identities to be used by a > server. > The server

Re: [netmod] nmda-guidelines-01: value space for config vs state

Related, revised-datastores-03#section-4.7 says: As a result of remnant configuration, the semantic constraints defined in the data model cannot be relied upon for , since the system may have remnant configuration whose constraints were valid with the previous configuration and that

Re: [netmod] draft netmod agenda posted

>> Could all the presenters please have a slide on their module's NMDA >> compatibility status? Things to consider: >> >> - is the operational state of configured values important? >> - is there is a need to support system generated entries? >> - note: if yes to either, the module SHOULD

Re: [netmod] WG Last Call for draft-ietf-netmod-syslog-model-15

As shepherd, yang doctor, and individual contributor, following is my LC/YD review. 1. Because I know this draft will not be presented in Prague, I first checked to see if it was NMDA-compatible. The draft contains just one module, and it only contains config true nodes (no config false nodes).

Re: [netmod] draft netmod agenda posted

Could all the presenters please have a slide on their module's NMDA compatibility status? Things to consider: - is the operational state of configured values important? - is there is a need to support system generated entries? - note: if yes to either, the module SHOULD be NMDA-compatible.

Re: [netmod] I-D Action: draft-ietf-netmod-rfc6087bis-13.txt

everything that could possibly change the behavior of the device. Andy On Tue, Jul 11, 2017 at 1:31 PM, Kent Watsen <kwat...@juniper.net<mailto:kwat...@juniper.net>> wrote: Hi Andy, I confirmed with Lou and Benoit that we want 6.23 to have the normative text within it, as w

Re: [netmod] I-D Action: draft-ietf-netmod-rfc6087bis-13.txt

rences will be to RFCs, not I-Ds. That is usually what is meant by the comment below I think > I don't expect the guidelines doc is going to progress independently. Agreed. Andy On Tue, Jun 20, 2017 at 8:20 AM, Kent Watsen <kwat...@juniper.net<mailto:kwat...@juniper.net>> wro

Re: [netmod] Wg use of github (was Re: [netmod-wg/acl-model] TCP flags values not defined and only single flag allowed (#5))

I have done it both ways, and it seems that folks prefer it more when the discussion appears to be less formalized. My current/personal thoughts are, use github internally, only as an author's aid. That is, don't mention the GitHub issue to the WG list at all. I have no issue with there being

[netmod] draft netmod agenda posted

The draft agenda for the NETMOD sessions at IETF 99 has been posted: https://datatracker.ietf.org/meeting/99/agenda/netmod/ Please let us know if any adjustments are needed. Thanks, NETMOD WG Chairs ___ netmod mailing list netmod@ietf.org

Re: [netmod] WG Last Call for draft-ietf-netmod-acl-model-11

Can the authors please start a thread on each of these open-issues ASAP? Thanks, Kent // shepherd -- Kent, what is the plan concerning the open issues listed in section 8? /js On Fri, Jul 07, 2017 at 06:34:28PM +, Kent Watsen wrote: > > > This is a notice to start a three we

[netmod] WG Last Call for draft-ietf-netmod-acl-model-11

This is a notice to start a three week NETMOD WG last call for the document: Network Access Control List (ACL) YANG Data Model https://tools.ietf.org/html/draft-ietf-netmod-acl-model-11 Note: Three weeks is more than needed, especially given this draft has been through Last Call

[netmod] WG Last Call for draft-ietf-netmod-syslog-model-15

This is a notice to start a three week NETMOD WG last call for the document: A YANG Data Model for Syslog Configuration https://tools.ietf.org/html/draft-ietf-netmod-syslog-model-15 Note: Three weeks is more than needed, especially given this draft has been through Last Call

Re: [netmod] draft-vallin-netmod-alarm-module status and plans

Hi William, Please be aware that this draft is moving to the CCAMP WG. I don't think the ccamp-version of the draft has been posted yet, but it will be discussed in that WG (and not NETMOD) in Prague. Regards, Kent > On Jun 22, 2017, at 6:25 AM, William Lupton

Re: [netmod] I-D Action: draft-ietf-netmod-rfc6087bis-13.txt

Regarding the suggestion to add this text: > Guidelines for > moving existing data modules to the NMDA are defined in > [I-D.dsdt-nmda-guidelines]. I'm hoping that we do not progress the guidelines doc. Ideally 6087bis can just state what people should do, without providing a formula for

Re: [netmod] I-D Action: draft-ietf-netmod-rfc6087bis-13.txt

Regarding the suggestion to add this text: > Guidelines for > moving existing data modules to the NMDA are defined in > [I-D.dsdt-nmda-guidelines]. I'm hoping that we do not progress the guidelines doc. Ideally 6087bis can just state what people should do, without providing a formula for

Re: [netmod] Important: Guidelines for YANG module authors

ocument main body and the non-NMDA modules in an Appendix. The use of the non-NMDA model will allow temporary bridging of the time period until NMDA implementations are available. The non-NMDA module names should include ’-state’ appended. We would like to thank Kent Watsen, Lou Berger, Rob Wilton,

Re: [netmod] draft-ietf-netmod-syslog-model-14 Signing Options

Hi Clyde, Since no concerns have been raised, should we be expecting an updated syslog draft shortly? Kent // as shepherd -- Hi, As part of the last few steps before again calling for last call for draft-ietf-netmod-syslog-model-14, we are adding certificate support to the signing-options

Re: [netmod] schema-mount virtual interim

=m87b080addaf71be419f67f2a893cfe94 Etherpad: http://etherpad.tools.ietf.org:9000/p/notes-2017-may-interim-netmod Attendees: Kent Watsen Lou Berger Lada Lhotka Martin Bjorklund Andy Bierman Acee Lindem Balazs Lengyel Joe White Xufeng Liu Igor (B?) Robert Varga Agenda: Schema Mount

Re: [netmod] schema-mount virtual interim

Some more useful links for today's virtual interim. * Etherpad: http://etherpad.tools.ietf.org:9000/p/notes-2017-may-interim-netmod * Slides from Chicago: https://www.ietf.org/proceedings/98/slides/slides-98-netmod-sessb-schema-mount-00.pdf K. -ORIGINAL MESSAGE- Gentle reminder:

Re: [netmod] schema-mount virtual interim

Gentle reminder: this Monday, May 22nd from 1pm to 3pm EST. Draft: https://tools.ietf.org/html/draft-ietf-netmod-schema-mount-05 Slides: https://datatracker.ietf.org/meeting/interim-2017-netmod-01/session/netmod WebEx: https://ietf.webex.com/ietf/j.php?MTID=m87b080addaf71be419f67f2a893cfe94

[netmod] schema-mount virtual interim

Dear WG, Please note that the NETMOD WG will be holding a virtual interim meeting to discuss open issues and usage scenarios for draft-ietf-netmod-schema-mount on May 22nd from 1pm to 3pm EST. Please see attached Calendar invite for WebEx details. Thanks, Kent (and Lou)

Re: [netmod] WG adoption poll draft-bjorklund-netmod-yang-tree-diagrams

This concludes the 2-week adoption poll for yang-tree-diagrams. There seems to be sufficient WG interest to move this draft forward at this time. And we have already determined that there is no known IPR pertaining to this work. Thereby this draft is now adopted as a WG chartered work item.

Re: [netmod] WG adoption poll draft-lhotka-netmod-yang-markup-00

This concludes the 2-week adoption poll for yang-markup. There does not seem to be sufficient interest to move this draft forward at this time. These results are similar to comments in the Chicago meeting. Let's keep this one on the back burner for now. Thanks, Kent (and Lou) --ORIGINAL

[netmod] doodle poll for schema-mount virtual interim

[please forward to other lists as needed] As discussed in Chicago, Lou and I want to schedule a virtual interim to discuss the schema-mount draft. Here is a doodle poll for it: https://doodle.com/poll/3v6q2yxes23sr7zk The dates and times have been selected by the draft authors. Please

Re: [netmod] draft minutes posted

The minutes have been posted: https://www.ietf.org/proceedings/98/minutes/minutes-98-netmod-00 Kent --ORIGINAL MESSAGE-- All, (especially presenters!), Please take a look at the meeting minutes here: http://etherpad.tools.ietf.org:9000/p/notes-ietf-98-netmod Michael, Lou, and I

Re: [netmod] Query on Announcing Conformance Information in the Message

Is there a typo in your capability line? s/netocnf/netconf/ Is your server also advertising jnx-ietf-netocnf-monitoring-dev in its hello message? BTW, be aware that servers supporting RFC7950 no longer have "deviations=" in the capability string, as the server is now expected to use YANG

<    2   3   4   5   6   7   8   9   10   >