Re: [netmod] WG adoption poll for draft-clemm-netmod-nmda-diff-00

We agree that the diff-format should be client-selectable, modulo what the server supports. yang-patch and edit-config both are viable. Should we document them both? That said, since neither edit-config nor yang-patch are diffing formats, so much as formats for converting one data tree to

Re: [netmod] WG adoption poll for draft-clemm-netmod-nmda-diff-00

Support. Kent // contributor -Original Message- From: Kent Watsen Date: Monday, October 1, 2018 at 2:48 PM To: "netmod@ietf.org" Subject: WG adoption poll for draft-clemm-netmod-nmda-diff-00 The IETF 102 in-room poll showed really good support to adopt this draft, and no

Re: [netmod] WG adoption poll for draft-clemm-netmod-nmda-diff-00

ork on. I hope this is okay with everyone. With respect to the adoption poll. The important thing here is if anyone objects. Do you or anyone else object? Kent // chair -Original Message- From: "Reshad Rahman (rrahman)" Date: Tuesday, October 2, 2018 at 8:21 AM To: K

Re: [netmod] New Version Notification for draft-kwatsen-netmod-artwork-folding-07.txt

> At least remove YANG from the example, and I also think that > auto-folding of tree diagrams should be strongly discouraged, so find > a better example for (b). Removed "YANG" and s/(e.g., tree diagrams)/, using a tool that doesn't observe line lengths. FWIW, pyang's --tree-line-length

[netmod] WG adoption poll for draft-clemm-netmod-nmda-diff-00

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.org/html/draft-clemm-netmod-nmda-diff-00 Please indicate your support or objection to the adoption poll. If objecting, please state your

[netmod] IPR poll on draft-clemm-netmod-nmda-diff-00

This mail starts the IPR poll for draft-clemm-netmod-nmda-diff-00. Are you aware of any IPR that applies to this draft? If so, has this IPR been disclosed in compliance with IETF IPR rules? Note, you do not have to be an author or a contributor to make everyone aware of an IPR. See RFC 3669,

Re: [netmod] YANG module security considerations template - TLS reference

Benoit is the progenitor of the template. I took it to be an "AD thing" has since passed to Ignas. Kent -Original Message- From: "Acee Lindem (acee)" Date: Monday, October 1, 2018 at 10:25 AM To: Martin Bjorklund , "netmod-cha...@ietf.org" , "netmod-...@ietf.org" ,

Re: [netmod] New Version Notification for draft-kwatsen-netmod-artwork-folding-07.txt

>> Now, to take it forward, I would like to constrain our efforts to >> solving the problem at hand. If our solution has wider applicability, >> that's great. But can we recognise that the overwhelming bulk of case >> we see today are in YANG documents and that's up to us to solve. > >That

Re: [netmod] New Version Notification for draft-kwatsen-netmod-artwork-folding-07.txt

Hi Tom, As contributor, I agree with you. The only reason that it is here now is because draft-wu-netmod-yang-xml-doc-conventions did. As chair, let me discuss with my co-chairs. Meanwhile, would love to hear others opinions. Kent - Original Message - Kent Stepping back, I think

Re: [netmod] New Version Notification for draft-kwatsen-netmod-artwork-folding-07.txt

Hi Tom, >> Good enough? > > No:-) The authors of YANG modules seem not to understand that it > applies to them, or incorrectly use the tools that would apply > were they correctly used. This seems to be a problem outside the scope of this draft. I was thinking to strengthen Section 4.2

Re: [netmod] perfect extraction, tabs, and long lines - oh my

> This is not an improvement. Just more complexity and noise. Disagree. The RFC should not mandate the tool exits, that would be overreaching. How about this simpler language? NEW: Scan the artwork for horizontal tab characters. If any horizontal tab characters appear, either

Re: [netmod] perfect extraction, tabs, and long lines - oh my

> Given that 2) has a)-c), I do not understand what the recommendation > actually is. The recommendation is hopefully 2a) and we are done. For the script that we include in the Appendix, the authors wish to keep the current "2a" behavior and have no plans to change that. The only change

Re: [netmod] perfect extraction, tabs, and long lines - oh my

I recommend that we select "option-2" (see bottom). - it easy to do. - there's no current support for having tabs in folded output. - doing so doesn't preclude an "option-3" someday in the future. The authors will assume that this is WG consensus if there are no objections within a week's

Re: [netmod] New Version Notification for draft-kwatsen-netmod-artwork-folding-07.txt

Hi Tom, > I would like a paragraph in this I-D to the effect that editors should > take care of this and that this phenomenon is nothing to do with the > technique described here, a sort of non-Applicability statement so that > we do not, in future, get too long lines as > > /* optical

[netmod] perfect extraction, tabs, and long lines - oh my

[new subject line] It is one thing for an editor to use tabs during the creation of text, and another to publish text with an expectation that consumers will render the tabs the same way. Either the source editor converts tabs to spaces, which is interoperable today, or keep the tabs while

[netmod] FW: New Version Notification for draft-kwatsen-netmod-artwork-folding-07.txt

Message- A new version of I-D, draft-kwatsen-netmod-artwork-folding-07.txt has been successfully submitted by Kent Watsen and posted to the IETF repository. Name: draft-kwatsen-netmod-artwork-folding Revision: 07 Title: Handling Long Lines in Artwork in Internet-Drafts an

Re: [netmod] backward compatibility requirements in draft-verdt-netmod-yang-versioning-reqs-00

> So do we hit a requirement (which is independent of versioning) that a > mechanism is needed to select different module sets (or views), given > that the reality gives us overlapping and competing models? And then > as a side effect, such a mechanism may also be used to select between >

Re: [netmod] backward compatibility requirements in draft-verdt-netmod-yang-versioning-reqs-00

Before RESTCONF, I implemented a versioned REST API that maintained constant object URIs, while allowing the objects themselves to be versioned, by using the Content-Type and Accept headers (yes, we created a media type for every "object" in the system). The server always natively understood

Re: [netmod] removing a node from a grouping

;bar-etc" { container-or-leaf "bar" { ... } ... // the "etc" ;) } grouping "foo-bar-etc" { grouping "foo"; grouping "bar-etc"; } Thanks, Rob On 11/07/2018 18:30, Kent Watsen wrote: > Say there is: > >

[netmod] removing a node from a grouping

Say there is: grouping "foo-bar-etc" { container-or-leaf "foo" { ... } container-or-leaf "bar" { ... } ... // the "etc" ;) } And the goal is to use the grouping sans the "foo" node. Can a "when" statement that always evaluates to "false" do it? grouping "bar-etc" { uses

Re: [netmod] Call for adoption request of draft-kwatsen-netmod-artwork-folding-04

Hi Robert, >>> 2) The proposed solution always left indents the wrapped line. Often for >>> artwork (e.g. a YANG tree diagram), where whitespace is not significant, >>> and the wrapping is relatively minor, then right indenting the wrapped >>> line can make the results look more visually

Re: [netmod] IETF 102 presentation requests

Per the Important Dates [1], the draft submission cutoff deadline in this Monday, July 2nd. Please be sure sure to submit updates for your drafts before then! [1] https://datatracker.ietf.org/meeting/important-dates/ Thanks, Kent // co-chair Just a quick reminder for folks to send

Re: [netmod] Call for adoption request of draft-kwatsen-netmod-artwork-folding-04

>>But with variable placement of the '\' character you can do: >> >>        This very long line happens to have a space character \ >>        immediately after the fold column."; >> This would not work, since the line is one character too long >> or >> >>        This very long line happens to

Re: [netmod] Call for adoption request of draft-kwatsen-netmod-artwork-folding-04

All, I just posted -06 that addresses some comments from Rob, Martin, and Jonathan. I realize that there are still open issues, but a rapid iteration for some of these things seems like it might be good: https://tools.ietf.org/html/draft-kwatsen-netmod-artwork-folding-06. Hi Robert, > A couple

Re: [netmod] [Netconf] Editorial comments on draft-kwatsen-netmod-artwork-folding-05

Hi Jonathan, I have applied all your suggestions for -06 - thanks! Regarding this exchange: >> Section 5.3, 4th paragraph: Arguably this should be from bottom-to-top >> as, going from top-to-bottom, once you have concatenated two lines the >> '\' will not be on the folding-column From a

Re: [netmod] Call for adoption request of draft-kwatsen-netmod-artwork-folding-04

>> Those are torture tests, but they due illustrate the one case where having >> the '\\n' on the fold column would've been illegal input (and hence the '\' >> was replaced with a 'x'). Great for internal algorithm validation, but >> perhaps unnecessary for the example in the text. Or maybe

Re: [netmod] Call for adoption request of draft-kwatsen-netmod-artwork-folding-04

> (The exmaples with just a string of '\' are highy confusing. Unclear > what they try to tell me... probably that the alg is much more > difficult than I originally thought ;-) Those are torture tests, but they due illustrate the one case where having the '\\n' on the fold column would've

Re: [netmod] Call for adoption request of draft-kwatsen-netmod-artwork-folding-04

Hi Martin, First, I just posted -05 to address the missing artwork: https://tools.ietf.org/html/draft-kwatsen-netmod-artwork-folding-05. See below for more comments. Kent // contributor = original message = > Hi, > > I support this work. See below for some comments. > > Qin Wu

Re: [netmod] IETF 102 presentation requests

Just a quick reminder for folks to send presentation requests. Please have requests in no later than this Sunday (July 1st). K. = original message = Dear WG, The chairs notice that the preliminary IETF 102 Agenda has been posted [1]. NETMOD is scheduled to meet Tuesday afternoon and

Re: [netmod] yang-data-ext issues

>> The authors of yang-data-ext met today to discuss how to move this >> draft forward. After about an hour, we decided that the best course >> of action is to: >> >> * clarify RFC 8040 rc:yang-data for the zerotouch use case >> - and update the zerotouch draft to use rc:yang-data >>

Re: [netmod] yang-data-ext issues

The authors of yang-data-ext met today to discuss how to move this draft forward. After about an hour, we decided that the best course of action is to: * clarify RFC 8040 rc:yang-data for the zerotouch use case - and update the zerotouch draft to use rc:yang-data * request this WG

[netmod] IETF 102 presentation requests

Dear WG, The chairs notice that the preliminary IETF 102 Agenda has been posted [1]. NETMOD is scheduled to meet Tuesday afternoon and Friday morning, both sessions are two hours. *** Yes, NETMOD is meeting on Friday, the last day of the conference! *** If you are interested in presenting to

[netmod] handling long lines in artwork in drafts

As those in London recall, I suggested an alternative solution for handling long lines in artwork in drafts. FWIW, I have captured this idea in the following I-D: https://tools.ietf.org/html/draft-kwatsen-netmod-artwork-folding-00 Kent // contributor

Re: [netmod] yang-data-ext issues

[resurrecting this thread] Currently the zerotouch draft has a normative reference to this draft. I will this week post an update to the zerotouch draft to resolve the netconf list thread "a couple zerotouch-21 issues". It would be easy for me to also switch back to using rc:yang-data, but I

Re: [netmod] draft-ietf-netconf-rfc7895bis-06 deviation query

> Co-authors, if you agree, how do we track this? As co-author, I agree and view it as an editorial update. As co-chair, I recommend the authors commit the fix to GitHub now and wait for AD and/or IESG reviews to trigger an update that it will get swept into. I don't think that it's worth

Re: [netmod] Query about draft-ietf-netconf-rfc7895bis-06

[+netconf, since this discussion regards a netconf draft] > But possibly a useful discussion to have may be what the members of the > NETCONF WG perceives is the future for the IETF network management > protocols. I'm an advocate for RESTCONF being as capable as NETCONF, and perhaps more

Re: [netmod] yang-data-ext issues

Juergen writes: > Kent writes: >> I don't understand talk about abandoning this draft. There is no question >> that it is needed (e.g., anima vouch, zerotouch, tail-f's "structure"), >> and RFC 8040 is unsatisfactory because 1) it doesn't allow a top-level >> 'choice' between two containers and

Re: [netmod] yang-data-ext issues

Lada writes: > Andy writes: >>IMO, the yang-data defined in RFC 8040 has a clear purpose, and it >>is sufficient for that purpose, which is a YANG representation of >>an instance document (such as a protocol message or file). > > The same is basically true even without the extension. For example,

Re: [netmod] yang-data-ext issues

>Martin wrote before: > No I was thinking along the lines of: > > ydx:yang-data my-first-rpc-error-info { >... > } > > rpc my-first-rpc { >... >opx:error-info-structure my-first-rpc-error-info; > } > > I.e., use yang-data to define a structure, and use another statement > to tie

[netmod] Publication has been requested for draft-ietf-netmod-acl-model-18

Kent Watsen has requested publication of draft-ietf-netmod-acl-model-18 as Proposed Standard on behalf of the NETMOD working group. Please verify the document's state at https://datatracker.ietf.org/doc/draft-ietf-netmod-acl-model/ ___ netmod mailing

[netmod] ACL (-18) issues found during shepherd write-up

Authors, Just a few minor things found while going through the shepherd checklist. These won't block the write-up, but should be fixed before we submit for publication. For now, the write-up will explain that these will be fixed, and I'll clear these comments as soon as an update is posted:

[netmod] IPR call on draft-ietf-netmod-acl-model-18

Authors, Contributors, WG, As part of Shepherd write-up for the acl-model draft, we need to ensure that all IPR has been declared. There was an IPR-call before, when there was a different set of authors involved, but not since, so it seems prudent to do another call now. Are you aware of

Re: [netmod] yang-data-ext issues

> People want to use YANG to define the schema for an XML or JSON > representation of a stand-alone document. Agreed > The only data needed must be module + local-name. Or maybe: module + local-name + context, where context is one of: - data nodes - RPC/actions - notifications -

Re: [netmod] yang-data-ext issues

Another and somewhat radical idea is to think of 'yang-data' as defining a data node, like a 'container', but not a config or opstate node. Yes, this is different from rc:yang-data, which defines a transparent node, like 'choice', but maybe it's okay if we can get the substitution groups part

Re: [netmod] yang-data-ext issues

I like Andy's proposal below, for the argument of the 'yang-data' statement to encode some meta-information regarding the context/namespace in which it's used, but I wonder how it really works. For instance, would "top" and "error-info" be the only allowed base-path values for the argument?

Re: [netmod] draft-ietf-netmod-acl-model

[just back from PTO] I'll be doing the shepherd write-up shortly. Kent // shepherd = original message = status on this draft? ___ netmod mailing list netmod@ietf.org

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

[Reducing to just the open threads] >> 3.1: >> a) 2nd paragraph, s/defines a label for/defines the label for/ > > Is this really correct? If we say "the label", it seems that we > first have to say that such a label exists; otherwise, which label > does "the label" refer to? I think so, in

[netmod] kw review of draft-ietf-netmod-schema-mount-09

1: paragraph starting w/ "In some cases", 1st sentence, s/often/sometimes/ 2: add ref to RFC 8174 2.1: s/defines a label for/defines the label for/ 3.1: a) 2nd paragraph, s/defines a label for/defines the label for/ b) 4th paragraph, add ref to RFC 6020 3.2, 1st paragraph: a) 1st

Re: [netmod] I-D Action: draft-ietf-netmod-acl-model-17.txt

Hi Mahesh, Two instances of <<>> below. Kent // shepherd On 3/14/18, 3:27 PM, "Mahesh Jethanandani" <mjethanand...@gmail.com<mailto:mjethanand...@gmail.com>> wrote: On Mar 14, 2018, at 10:42 AM, Kent Watsen <kwat...@juniper.net<mailto:kwat...@junip

Re: [netmod] I-D Action: draft-ietf-netmod-acl-model-17.txt

Hi Mahesh, please look for <> below. All, please take a look at the question around renaming the "access-lists" container. Thanks, Kent On 3/13/18, 9:46 PM, "Mahesh Jethanandani" <mjethanand...@gmail.com<mailto:mjethanand...@gmail.com>> wrote: On

Re: [netmod] I-D Action: draft-ietf-netmod-acl-model-17.txt

Hi Mahesh, Please look for below. Thanks, Kent On 3/8/18, 7:40 PM, "Mahesh Jethanandani" <mjethanand...@gmail.com<mailto:mjethanand...@gmail.com>> wrote: Kent, On Mar 7, 2018, at 1:55 PM, Kent Watsen <kwat...@juniper.net<mailto:kwat...@juniper.net>&g

Re: [netmod] Adam Roach's No Objection on draft-ietf-netmod-rfc6087bis-18: (with COMMENT)

> I came up with 2 sentences to add to 6087bis: > > #1) > > If the patterns used in a type definition have known limitations > such as false positive matches, then these limitations > SHOULD be documented within the typedef or data definition. I like this, but it would be better to also mention

Re: [netmod] I-D Action: draft-ietf-netmod-acl-model-17.txt

[To all those that said this draft was ready, really?] Hi Mahesh, Thanks for the update. I found some more issues. Some must be fixed, others are nits, and might be caught by the RFC Editor. But I think that it's embarrassing to receive comments for such things from the IESG, as is

Re: [netmod] [Technical Errata Reported] RFC6020 (5272)

>From RFC 7950, Section 7.20.2, first sentence: The "if-feature" statement makes its parent statement conditional. Thus: feature aaa { if-feature bbb; ... } means that feature "aaa" depends on feature "bbb". The current text is correct. Kent The following errata report

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

Thanks Clyde. Benoit, it's ready now. Kent // shepherd On 3/1/18, 10:29 AM, "Clyde Wildes (cwildes)" <cwil...@cisco.com<mailto:cwil...@cisco.com>> wrote: Kent, I published a new draft that fixes the last two points. Thanks, Clyde From: Kent Watsen <kwat...@jun

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

of Section 1.4. Clyde, can you please post a v23 that fixes these last two points? Thanks, Kent // shepherd On 2/23/18, 1:05 PM, "Mahesh Jethanandani" <mjethanand...@gmail.com<mailto:mjethanand...@gmail.com>> wrote: Kent, On Feb 23, 2018, at 8:02 AM, Kent Watsen <kwat..

Re: [netmod] Proposal for minimalist full NMDA support in schema mount

So it this a possible way out of the current situation? We publish a trimmed down document that just defines the mount point extension and we do an update of this document that adds all the details needed to obtain the schema information? /js +1 This was something I suggested a while back.

Re: [netmod] reference statement examples in draft-ietf-netmod-rfc6087bis-18

Juergen writes: > I think it was common practice to write > > reference "RFC 6991: Common YANG Data Types"; > > instead of just > > reference "RFC 6991"; Agreed, I always do. > that is to include the RFC title (this can be especially useful with > longer lists of references and less

Re: [netmod] ACL draft issues found during shepherd writeup

Hi Mahesh, Please search for below (6 instances) Thanks, Kent // shepherd On 2/17/18, 8:26 PM, "Mahesh Jethanandani" <mjethanand...@gmail.com<mailto:mjethanand...@gmail.com>> wrote: Kent, Thanks for a detailed review. See inline. On Feb 13, 2018, at 2:30

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

t. Kent // shepherd = original message = Kent, Tom, Yaron, and Ron, A new version of the draft-ietf-netmod-syslog-model has been published that addresses your concerns. Thanks, Clyde On 2/20/18, 9:06 AM, "netmod on behalf of Kent Watsen" <netmod-boun...@ietf.org on beh

Re: [netmod] Secdir last call review of draft-ietf-netmod-syslog-model-21

> Security Comments > > * I think almost all writable data nodes here are sensitive, because a network > attacker's first move is to block any logging on the host, and many of the data > nodes here can be used for this purpose. > > [clw1]

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

> Kent > > You illustrate beautifully the problem I would like a solution to. > > The current thinking AFAICT is that tree-diagrams > should be an Informative Reference. > > Therefore, the RFC Editor will not hold publication until an RFC number > is assigned. > > Therefore, a note asking the

Re: [netmod] [Netconf] LC on YANG Library (bis)

Alex, What you want makes sense to me. How about putting it into an I-D that augments the yang library bis? It doesn't have to be in this document, right? Kent = original message = Well, we need a general solution for that. YANG-push is just one use case. There are other cases

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

Buggers, I thought we caught that tree-diagrams informative/normative thing before. Regardless, Clyde, please note that I think I was wrong before from the shepherd write-up regarding idnits having a problem: """ == Unused Reference: 'I-D.ietf-netconf-keystore' is defined on line 1340,

[netmod] ACL draft issues found during shepherd writeup

[sorry, wrong WG, moving netconf to BCC!] ACL Authors, Below are some issues I found while looking at doing the Shepherd write-up today. Please take a look. Also, with regards to the request for those having Last Call comments to please verify that their comments were addressed, I only saw

[netmod] Publication has been requested for draft-ietf-netmod-syslog-model-20

Kent Watsen has requested publication of draft-ietf-netmod-syslog-model-20 as Proposed Standard on behalf of the NETMOD working group. Please verify the document's state at https://datatracker.ietf.org/doc/draft-ietf-netmod-syslog-model/ ___ netmod

Re: [netmod] [Netconf] New Version Notification for draft-lengyel-netmod-yang-instance-data-00.txt

[removing netconf] On 2/12/18, 12:20 PM, "Netconf on behalf of Kent Watsen" <netconf-boun...@ietf.org<mailto:netconf-boun...@ietf.org> on behalf of kwat...@juniper.net<mailto:kwat...@juniper.net>> wrote: Hi Balazs, I'm unclear about the scope of the probl

Re: [netmod] New Version Notification for draft-lengyel-netmod-yang-instance-data-00.txt

Hi Balazs, I'm unclear about the scope of the problem. Is it limited to server capabilities?It seems that the idea is to move from having a stateful connection to a live server to having a way to pass the equivalent state even when not connected to the server. Related, but probably not

Re: [netmod] draft-ietf-netmod-rfc6087bis-16

Hi Tom, I know where you're going with this, and I agree, but as we're past AD-review, maybe this is a good candidate for guidelines-next? https://github.com/netmod-wg/guidelines-next/issues Kent // shepherd - Original Message - From: "Andy Bierman" Sent:

Re: [netmod] [OPSAWG] Minor change in ietf-access-control-l...@2018-02-02.yang

Yes, it may be a bug in ODL, but I also think that there is something wrong to use such a long relative path. In that case, the relative path is actually longer than the absolute path! That said, there is no guidance in rfc6087bis currently, so we may need to let it go this time. K. //

Re: [netmod] I-D Action: draft-ietf-netmod-syslog-model-19.txt

g Messages over TCP > > Creation_date: 2010-09-30 > > > > Abstract: > > There have been many implementations and deployments of > legacy syslog > > over TCP for many years. That protocol has evolved without being > > standardized and has proven to be quite i

Re: [netmod] I-D Action: draft-ietf-netmod-syslog-model-19.txt

make those changes, but most importantly, you need to make sure it passes idnits. BTW, I was wrong before, there is an error in the 2119 boilerplate (idnits verbose output shows it) > Thanks, > Clyde Kent == original message = On 2/6/18, 4:49 PM, "Kent Watsen" <kwat

Re: [netmod] Draft Normative references in a YANG module

I think that there should be a note attached to such references occurring inside of a YANG module. I think that all of my drafts do this, though I tend to use a single large Note to Editor at the beginning of the draft, rather than a number of smaller notes sprinkled throughout the document.

Re: [netmod] I-D Action: draft-ietf-netmod-syslog-model-19.txt

in -19. Tom Petch - Original Message - From: "Kent Watsen" <kwat...@juniper.net> To: <netmod@ietf.org> Sent: Tuesday, January 16, 2018 4:59 PM > Clyde, > > This draft still isn't passing idnits. I provided the link to idnits previousl

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

All, This message closes the Last Call on the ACL draft. After a number of run-ups, it seems that we now have a draft that folks are happy with. Thank you everyone involved. It's understood that object groupings are desirable. Though we're not adding object groupings now, we are adding

Re: [netmod] [Netconf] LC on YANG Library (bis)

As co-author, I am not aware of any IPR related to this document. As a contributor, I have read this document and think that it is ready for advancement. Kent On 2/2/18, 4:30 AM, "Netconf on behalf of Robert Wilton" on behalf of

[netmod] schema-mount pre09 branch

All, The authors created a "pre09" branch on GitHub a few weeks back. On this branch, they completed a full update of the draft. While waiting for details on how to proceed with regards to a SM-bis, we thought it would be helpful to make this text available now so that the technical parts

Re: [netmod] [Netconf] LC of NDMA NETCONF/RESTCONF drafts

I have read and support both drafts for advancement. Kent // co-author = original message = Authors and WG, We have not received any explicit support for this LC on this email thread. If you believe these drafts are important and should proceed, please state your support by

[netmod] FW: WG: Adoption Poll: draft-bierman-netmod-yang-data-ext-01

[forwarding yang-data-ext posted to the netconf list] K. Eric Voit writes: I think this work is excellent. I would like to see it adopted. > Please take a moment to post support for the adoption of the yang-data-ext > draft in the NETMOD working group. > > Recall that one of the zerotouch

Re: [netmod] WG: Adoption Poll: draft-bierman-netmod-yang-data-ext-01

support, as a contributor this draft is needed to resolve a zerotouch last call issue K. On 25/01/2018 13:26, Lou Berger wrote: > Hi, > > This is the start of a *two* week poll on making > draft-bierman-netmod-yang-data-ext a working group document. Please > send email to the list indicating

Re: [netmod] AD review of draft-ietf-netmod-rfc6087bis-16 Part 1

I see a lot of suggestions to reference other drafts as examples. I would discourage doing that. I recommend this draft clearly stating the desire, including its own examples if needed. Regarding referencing the tree-diagrams draft, I don't agree that having a "Tree Diagrams" section in the

Re: [netmod] moving forward with schema mount

> So do you believe that this decision reflects rough consensus > in the WG? Not currently, as there are two vocal groups with opposing viewpoints. However, there was strong for advancing it before. The chairs had to make a decision and, as you can imagine, it wasn't easy. Ultimately, to

[netmod] moving forward with schema mount

Thank you all for the important discussion since the completion of WGLC on Nov 6th. Per normal process, drafts typically progress once LC comments are address unless significant faults are found. Post LC comments have been made, which needed consideration, notably the relationship with NMDA

Re: [netmod] schema mount and YANG library

Dean writes: " At the end, if we need to we can revise to support future publications." I write: "Just a clarification on your last sentence, my understanding is that a revision is necessary in order for schema-mount to work on NMDA-based servers. Should we publish the current draft as is

Re: [netmod] schema mount and YANG library

Hi Dean, "As Lou mentioned, schema mount can be used with or without YANG library. As author who uses the schema mount in a draft and in product, don’t want to hold back the publication. We, IETF, are too slow. Getting data model RFCs published takes too much time and we are not getting

Re: [netmod] Regarding IPR on draft-bierman-netmod-yang-data-ext-01

No, I'm not aware of any IPR that applies to this draft Kent // co-author = original message = Authors, Contributors, WG, As part of the preparation for WG adoption: Are you aware of any IPR that applies to drafts identified above? Please state either: "No, I'm not aware of any IPR

[netmod] Publication has been requested for draft-ietf-netmod-rfc6087bis-16

Kent Watsen has requested publication of draft-ietf-netmod-rfc6087bis-16 as Best Current Practice on behalf of the NETMOD working group. Please verify the document's state at https://datatracker.ietf.org/doc/draft-ietf-netmod-rfc6087bis/ ___ netmod

Re: [netmod] rfc6087bis shepherd writeup issues

eference for RFC 5378. The idnits tool is wrong. It ignores usage in an appendix. Andy On Mon, Jan 15, 2018 at 2:15 PM, Kent Watsen <kwat...@juniper.net<mailto:kwat...@juniper.net>> wrote: Hi Andy, 1) before I forget, could you please confirm one more time (the last time

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

to address all the comments received during the LC. Thanks. > On Jan 17, 2018, at 3:33 PM, Kent Watsen <kwat...@juniper.net> wrote: > > > H Mahesh, > >>> - There is an open issue in the document (section 8) - are we going >>> to resolve that du

Re: [netmod] schema mount and YANG library

>On Thu, Jan 18, 2018 at 08:25:35AM -0800, joel jaeggli wrote: >> >> Perhaps I apply a different discount rate on the future particularly >> when timelines are involved. e.g. 3 months turns into a year and half >> pretty quickly. > > I provided a reasoning why 3 months may be feasible, I doubled

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

H Mahesh, >> - There is an open issue in the document (section 8) - are we going >> to resolve that during WG last call or is this a leftover? > > This will be resolved in the next version of the module. It is > documented under Issues tab in GitHub. Should we remove it from > the draft? Most

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

All, This starts a two-week working group last call on draft-ietf-netmod-acl-model-15. This working group last call ends on January 31st. 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

Re: [netmod] I-D Action: draft-ietf-netmod-acl-model-15.txt

Yes, good job Mahesh and team! My previous Last Call closing message [1] said that we'd evaluate if that Last Call was successful or not based on the result of the ensuing discussion regarding the model's structure. As the diff [2] for this update shows, the draft has changed significantly

Re: [netmod] [Netconf] LC of NDMA NETCONF/RESTCONF drafts

I'm not aware of any IPR impacting either of these two drafts. Kent // as co-author = original message = The authors of draft-ietf-netconf-nmda-netconf and draft-ietf-netconf-nmda-restconf have posted updates to their drafts, and believe that the documents are ready for LC. This

Re: [netmod] I-D Action: draft-ietf-netmod-syslog-model-19.txt

18 1:46 PM > To: Benoit Claise <bcla...@cisco.com>; Kent Watsen > <kwat...@juniper.net>; netmod@ietf.org > Subject: Re: [netmod] I-D Action: draft-ietf-netmod-syslog-model-19.txt > > By the same reasoning surely UDP should not

Re: [netmod] I-D Action: draft-ietf-netmod-syslog-model-19.txt

Hi Clyde, One quick follow-up, it seems that all drafts are moving over to reference the tree-diagrams draft these days. As such, I think Section 1.3 (Tree Diagram Notation) should now be removed and Section 3.1 should change as follows: OLD Please see Section 1.3 for tree diagram

Re: [netmod] I-D Action: draft-ietf-netmod-syslog-model-19.txt

Clyde, This draft still isn't passing idnits. I provided the link to idnits previously, but here it is again: https://www.ietf.org/tools/idnits. Below is the idnits output for -19 with inlined comments. PS: I didn't also checked the other issues we're tracking, but will when we get past

[netmod] rfc6087bis shepherd writeup issues

Hi Andy, 1) before I forget, could you please confirm one more time (the last time being in 2016, sheesh!) that you are unaware of any IPR that needs to be filed for this draft, according to BCPs 78 and 79? 2) Idnits found three warnings, only the first might require thought for how best

[netmod] syslog-model-18 shepherd writeup issues

[Welcome to 2018!] Hi Clyde, In reviewing the -18 draft for Shepherd write-up, I found the following issues that I think need to be addressed before the document can be sent to Benoit for AD review: 1. I believe that there is a pending request from Tom on that has yet to be addressed:

Re: [netmod] Joel Jaeggli as a third NETMOD co-chair

Indeed, congrats! K. Sent from my iPhone On Dec 15, 2017, at 12:19 PM, Lou Berger > wrote: Joel, Welcome aboard! Lou On 12/15/2017 12:21 PM, Benoit Claise wrote: Dear all, A lot is happening these days in the world of data modeling-driven

<    1   2   3   4   5   6   7   8   9   10   >