[netmod] Draft Minutes IETF 114 netmod session

[Joel Jaeggli]

Greetings folks,

draft minutes from IETF 114 are imported here

https://datatracker.ietf.org/doc/minutes-114-netmod-202207271500/

Additional changes or corrections can be added in the note taking tool here:

https://notes.ietf.org/notes-ietf-114-netmod?edit

The youtube video of it's sessions and the associated transcript are at:

https://www.youtube.com/watch?v=qIIQwK3qNgc


Thanks

Joel


___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

[netmod] Draft-minutes for ietf 113

[joel jaeggli]

are posted at

https://datatracker.ietf.org/doc/minutes-113-netmod/

I am still sourcing  the commentary for from System defined configuration
from the youtube video  so there is an update forthcoming.

Thanks
joel
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

[netmod] Draft Agenda Posted for IETF 111 - Tuesday, July 27, 2021, Session II (21:30-22:30 UTC, 14:30-15:30 PDT)

[Joel Jaeggli]

The draft Agenda was posted,

Based on currently extant slot requests it is relatively short. Please
take a look at whether changes are required.

Presenters please remember that Slides would be greatly appreciated not
less than 24 hours prior to Tuesday july 27th 21:30 for inclusion in the
meeting materials.

Thanks

Netmod Chairs.

---
Agenda for the NETMOD 111 WG Session
---
https://datatracker.ietf.org/meeting/111/materials/agenda-111-netmod

Session:
   Tuesday, July 27, 2021
   Session II (21:30-22:30 UTC, 14:30-15:30 PDT)

WG Chairs:
   Lou Berger    (lberger at labs dot net)
   Kent Watsen (kent plus ietf at watsen dot net)
   Joel Jaeggli    (joelja at bogus dot com)

Available During Session:
   WG ICS: https://datatracker.ietf.org/meeting/111/sessions/netmod.ics
   ICS: https://datatracker.ietf.org/meeting/111/session/28884.ics
   MeetEcho: https://meetings.conf.meetecho.com/ietf111/?group=netmod
   Jabber:  xmpp:net...@jabber.ietf.org?join

Available During / After Session:
   CodiMD:    https://codimd.ietf.org/notes-ietf-111-netmod
   Slides: https://datatracker.ietf.org/meeting/111/session/netmod
   Drafts (TGZ):
https://datatracker.ietf.org/meeting/111/agenda/netmod-drafts.tgz
   Drafts (PDF):
https://datatracker.ietf.org/meeting/111/agenda/netmod-drafts.pdf

Available After Session:
   Recording: http://www.meetecho.com/ietf111/recordings#NETMOD
   Jabber Logs:   https://www.ietf.org/jabber/logs/netmod

Introduction
   Chairs (10 minutes)
   Session Intro & WG Status

Chartered items:
   YANG Versioning Update (30 min)
https://datatracker.ietf.org/doc/draft-ietf-netmod-yang-module-versioning/
   https://datatracker.ietf.org/doc/draft-ietf-netmod-yang-semver/
   https://datatracker.ietf.org/doc/draft-ietf-netmod-yang-packages/
https://datatracker.ietf.org/doc/draft-ietf-netmod-yang-ver-selection/
https://datatracker.ietf.org/doc/draft-ietf-netmod-yang-schema-comparison/
   Overview - Jason Sterne
   YANG Module Versioning Draft - Jason Sterne
   YANG Semver Draft - Joe Clarke

Remaining 20 min.

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

[netmod] draft minutes ietf 110

[Joel Jaeggli]

We had posted an initial set, I have subsequently updated the draft
minutes for ietf 110.

they are viewable here:

https://datatracker.ietf.org/meeting/110/materials/minutes-110-netmod-01

and remain editable in the codimd

https://codimd.ietf.org/notes-ietf-110-netmod?edit

The transcript exceeds the line length for a codimd note with or with
out timstamps, (perils of talking for 125 minutes) but is viewable on
the youtube file at

https://www.youtube.com/watch?v=glLcpQ9kpv0

joel

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] AD review of draft-ietf-netmod-nmda-diff-07

[joel jaeggli]

yeah when there is an update we'll probably drop a  reminder in the list
along with a link to the diff, but unless it looks major  there's not
reason to ask for re-approval.

thanks
joel

On Mon, Mar 15, 2021 at 10:26 AM Rob Wilton (rwilton) 
wrote:

> Hi Andy,
>
>
>
> FYI, this issue was discussed in the Netmod session on Friday.
>
>
>
> My interpretation of the chairs position is (
> https://www.youtube.com/watch?v=glLcpQ9kpv0, starts at 6.10) is : As long
> as the WG is copied on my AD review comments and proposed changes (which
> they have been), then the WG has the opportunity to comment or object to
> the proposed changes if they wish, and lack of comment from the WG is taken
> as a tacit acceptance of the proposed changes.
>
>
>
> Given this, I think that the authors can apply the mark ups based on the
> agreements below (and my original nits), republish, and then hopefully we
> should be ready to progress this to IETF LC.
>
>
>
> Regards,
> Rob
>
>
>
>
>
> *From:* Andy Bierman 
> *Sent:* 05 March 2021 18:46
> *To:* Rob Wilton (rwilton) 
> *Cc:* NetMod WG Chairs ; joel jaeggli <
> joe...@gmail.com>; draft-ietf-netmod-nmda-diff@ietf.org;
> netmod@ietf.org
> *Subject:* Re: AD review of draft-ietf-netmod-nmda-diff-07
>
>
>
>
>
>
>
> On Fri, Mar 5, 2021 at 10:18 AM Rob Wilton (rwilton) 
> wrote:
>
> Hi Andy,
>
>
>
> I’m not sure which one you think is s a design change:  Do you mean issue
> 3 or issue 4 below?
>
>
>
> I see that my response to issue 4 may not have been clear, so to clarify:
>
>
>
> By “okay”, I meant, that I am okay with how it is written in the current
> draft.  My presumption is that this could be addressed as a future version
> of the module if this turns out be an issue, or vendors can define their
> own augmentation if needed.
>
>
>
> If you think issue 3 is a design change that requires WG consensus that I
> will leave it to the WG chairs to decide if they wish to issue a consensus
> call for it.
>
>
>
>
>
>
>
> The change:
>
>
>
>Current: default is to include origin attributes and client adds
> exclude-origin leaf to turn this off
>
>Proposed: default is to exclude origin attributes and client adds
> report-origin leaf to turn this on
>
> Also, report-origin has an if-feature because origin support in NMDA
> is optional.
>
>
>
> I have no objections to this proposal.
>
> My point all along has been that this is not my decision to make, it is a
> WG decision.
>
> It does not seem that there are any objections to making this change.
>
>
>
>
>
> Regards,
>
> Rob
>
>
>
>
>
> Andy
>
>
>
>
>
> *From:* Andy Bierman 
> *Sent:* 05 March 2021 16:36
> *To:* Rob Wilton (rwilton) 
> *Cc:* joel jaeggli ;
> draft-ietf-netmod-nmda-diff@ietf.org; netmod@ietf.org
> *Subject:* Re: AD review of draft-ietf-netmod-nmda-diff-07
>
>
>
>
>
>
>
> On Fri, Mar 5, 2021 at 5:58 AM Rob Wilton (rwilton) 
> wrote:
>
> Hi Andy, authors,
>
>
>
>
>
>
>
> I think you mean to address this to the WG since the redesign issues need
> WG approval.
>
> I have no objections to any changes.
>
>
>
>
>
> Andy
>
>
>
> Sorry for the long delay in replying.
>
>
>
> Please see [RW] inline below …
>
>
>
>
>
> *From:* Andy Bierman 
> *Sent:* 30 October 2020 01:43
> *To:* joel jaeggli 
> *Cc:* Rob Wilton (rwilton) ;
> draft-ietf-netmod-nmda-diff@ietf.org; netmod@ietf.org
> *Subject:* Re: AD review of draft-ietf-netmod-nmda-diff-07
>
>
>
>
>
>
>
> On Thu, Oct 29, 2020 at 6:09 PM joel jaeggli  wrote:
>
> Rob,
>
>
>
> These seem like reasonable suggestions.
>
>
>
> Lets see what the authors say.
>
>
>
> Thanks for this
>
> joel
>
>
>
> On Thu, Oct 29, 2020 at 6:47 AM Rob Wilton (rwilton) 
> wrote:
>
> Hi,
>
> Here is my AD review for draft-ietf-netmod-nmda-diff-07.  Apologies for
> the delay.
>
> Thank you for writing this document, I think that it is useful, and looks
> like it is in good shape.
>
>
> Main comments:
>
> 1. Should there be any text about how to find out what datastores are
> supported by a device?  E.g., pointing them to either YANG library, or
> protocol specific mechanisms in the case of RESTCONF.
>
>
>
> Do you have a section in mind and suggested text?
>
> *[RW] *
>
> *Perhaps somewhere in section 4, either as part of the description of
> source, or perhaps before the parameters are described.*
>
>
>
> *Proposed t

[netmod] draft minutes for 2/1/2020 Interim

[joel jaeggli]

ed.
... lots of debate around use of mandatory in config false...
Balazs: state has been best effort historically
Kent: agree but maybe that isn't great and we should start getting more
formal. Perhaps we should have been setting mandatory true on more state
data.  Let's not reverse the default of mandatory for state (that would
need YANG NEXT).
Balazs: 1 - how strict should we be?  2 - do we mark a removal of
optional leafs as NBC just because of current expectations
Rob: RFC7950 doesn't allow removal of optional state leafs today (you
could deprecate or obsolete).
Jason: we should avoid mandatory for state
Kent: perhaps YANG NEXT is needed for new state rules (esp if we go
against RFC7950)
Balazs: we need to do something now, e.g. we should be allowed to add a
mandatory state leaf
Balazs: we should be more careful with state markings (mandatory). 2nd
bullet should just be NBC for now (easier to get accepted).  And
reducing value space for mandatory is NBC.
Rob: solving this properly is likely YANG NEXT. But we need something
for the interim.  So bullet 2 should be NBC for now with where we are today.
Kent: client validating RPC reply could be seen as a developer aid for
the server
Rob: worth checking NMDA spec.  Allows server to break those restraints
(at least temporarily).  Ok to flag up warnings, but refusing to accept
data could be a problem in general.  (consider config true & config
false for this point)



 T4) SemVer: gaps in history, removing revision statements
> https://github.com/netmod-wg/yang-ver-dt/issues/61
>
https://datatracker.ietf.org/doc/slides-interim-2021-netmod-01-sessa-version-gaps/

Joe Clarke presenting
15:45

Kent: why strip any history at all? how is it possible that 1.2 isn't
present?
Joe: why strip? -> large amount of revision is cumbersome for humans. We
don't recommend it, but wouldn't want to block it.  why 1.2 missing? ->
1.2 might have been some internal revision.
Kent: I don't believe we should worry about the human problem. I don't
think we should allow gaps.
Balazs: one important reason for gaps -> branching.  1.5 may be in a
side branch.
Kent: that sounds like internal merging issue. It is about managing
expectations. I don't know any library that skips.  A missing value is
not expected.
Joe: maybe a system publishes every odd version
Jason: some publishers may have internal versions, and it would be
painful to have a mapping from internal to external
Rob: I see Kent's point and maybe a publisher doesn't have to actually
publish all those versions. But they could keep those versions in the
history.
Jason: it could cause a lot of bloat in the history
Joe: maybe soften the wording to encourage keeping all revisions?  Then
again if you went a year before publishing do you really want all those
internal versions listed?

1600 conclusion


# Virtual Bluesheet
NAME   AFFILIATION
--
1. Lou BergerLabN Consulting, L.L.C.
1. Jason Sterne  Nokia
1. Italo BusiHuawei
1. Reshad Rahman None
1. Robert Wilton Cisco
1. Kent Watsen   Watsen Networks
1. Balazs LengyelEricsson
1. Joel Jaeggli  Fastly
1. Jan Lindblad
1. Joe ClarkeCisco
1. Tom Hill
1. Xufeng Liu



OpenPGP_signature
Description: OpenPGP digital signature
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

[netmod] Congratulations... Re: RFC 8819 on YANG Module Tags

[Joel Jaeggli]

On getting this one out the door.

The utility of this work to all of us is greatly appreciated.

joel

On 1/4/21 15:06, rfc-edi...@rfc-editor.org wrote:
> A new Request for Comments is now available in online RFC libraries.
>
> 
> RFC 8819
>
> Title:  YANG Module Tags 
> Author: C. Hopps,
> L. Berger,
> D. Bogdanovic
> Status: Standards Track
> Stream: IETF
> Date:   January 2021
> Mailbox:cho...@chopps.org, 
> lber...@labn.net, 
> ivand...@gmail.com
> Pages:  19
> Updates:RFC 8407
>
> I-D Tag:draft-ietf-netmod-module-tags-10.txt
>
> URL:https://www.rfc-editor.org/info/rfc8819
>
> DOI:10.17487/RFC8819
>
> This document provides for the association of tags with YANG modules.
> The expectation is for such tags to be used to help classify and
> organize modules. A method for defining, reading, and writing modules
> tags is provided. Tags may be registered and assigned during module
> definition, assigned by implementations, or dynamically defined and
> set by users. This document also provides guidance to future model
> writers; as such, this document updates RFC 8407.
>
> This document is a product of the Network Modeling Working Group of the IETF.
>
> This is now a Proposed Standard.
>
> STANDARDS TRACK: This document specifies an Internet Standards Track
> protocol for the Internet community, and requests discussion and suggestions
> for improvements.  Please refer to the current edition of the Official
> Internet Protocol Standards (https://www.rfc-editor.org/standards) for the 
> standardization state and status of this protocol.  Distribution of this 
> memo is unlimited.
>
> This announcement is sent to the IETF-Announce and rfc-dist lists.
> To subscribe or unsubscribe, see
>   https://www.ietf.org/mailman/listinfo/ietf-announce
>   https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist
>
> For searching the RFC series, see https://www.rfc-editor.org/search
> For downloading RFCs, see https://www.rfc-editor.org/retrieve/bulk
>
> Requests for special distribution should be addressed to either the
> author of the RFC in question, or to rfc-edi...@rfc-editor.org.  Unless
> specifically noted otherwise on the RFC itself, all RFCs are for
> unlimited distribution.
>
>
> The RFC Editor Team
> Association Management Solutions, LLC
>
> ___
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
>

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

[netmod] IETF 109 draft minutes

[Joel Jaeggli]

draft minutes are visible in the tracker 

https://datatracker.ietf.org/meeting/109/materials/minutes-109-netmod-01

and for edits and corrections they are available live here

https://codimd.ietf.org/notes-ietf-109-netmod?edit

the real-time transcript from youtube is pasted at the bottom of the codimd 
notes.

Thanks
joel
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] AD review of draft-ietf-netmod-nmda-diff-07

[joel jaeggli]

Rob,

These seem like reasonable suggestions.

Lets see what the authors say.

Thanks for this
joel

On Thu, Oct 29, 2020 at 6:47 AM Rob Wilton (rwilton) 
wrote:

> Hi,
>
> Here is my AD review for draft-ietf-netmod-nmda-diff-07.  Apologies for
> the delay.
>
> Thank you for writing this document, I think that it is useful, and looks
> like it is in good shape.
>
>
> Main comments:
>
> 1. Should there be any text about how to find out what datastores are
> supported by a device?  E.g., pointing them to either YANG library, or
> protocol specific mechanisms in the case of RESTCONF.
>
> 2. It might be helpful to add a comment about potential issues that could
> arise by comparing  to , i.e., additional differences
> could be reported due to inactive configuration and template processing
> between  and .
>
> 3. I would prefer if 'exclude=origin' was in the reverse sense and perhaps
> called 'report-origin' instead.  With the reverse sense it seems to be
> safer if new datastores are defined, where otherwise the behaviour could
> end being under specified.
>
> 4. Should there be an option to filter on origin metadata?  E.g., only
> include values that come from intended.  Otherwise, things like IP
> addresses learned from DHCP may always turn up as differences.
>
> 5. I'm not that keen on the "Possible Future Extensions" section of an
> RFC.  Personally, I would prefer that this section is deleted, but if you
> wish to retain it, then please can you move it to an appendix.
>
>
> I've also included some minor comments inline below, and some nits at the
> end:
>
> Abstract
>
>This document defines an RPC operation to compare management
>datastores that comply with the NMDA architecture.
>
> The abstract is perhaps somewhat terse.  Perhaps:
>
> This document defines a YANG RPC operation to compare the
> contents of network management datastores that comply with
> the NMDA architecture and return the differences in the
> YANG-Patch format.
>
>
> 1.  Introduction
>
>The revised Network Management Datastore Architecture (NMDA)
>[RFC8342] introduces a set of new datastores that each hold YANG-
>defined data [RFC7950] and represent a different "viewpoint" on the
>data that is maintained by a server.  New YANG datastores that are
>introduced include , which contains validated
> configuration
>data that a client application intends to be in effect, and
>, which contains at least conceptually operational
> state
>data (such as statistics) as well as configuration data that is
>actually in effect.
>
> I would suggest deleting "at least conceptually", since the 
> datastore does contain all operational state, but it may be implemented as
> a virtual construct that spans multiple nodes (e.g., linecards) and
> processes.
>
>
>NMDA introduces in effect a concept of "lifecycle" for management
>data, allowing to clearly distinguish between data that is part of a
>configuration that was supplied by a user, configuration data that
>has actually been successfully applied and that is part of the
>operational state, and overall operational state that includes both
>applied configuration data as well as status and statistics.
>
> "allowing to clearly distinguish" => distinguishing"
> "status and statistics" => "status information and statistics"
>
>
>As a result, data from the same management model can be reflected in
>multiple datastores.  Clients need to specify the target datastore
> to
>be specific about which viewpoint of the data they want to access.
>This way, an application can differentiate whether they are (for
>example) interested in the configuration that has been applied and
> is
>actually in effect, or in the configuration that was supplied by a
>client and that is supposed to be in effect.
>
> Perhaps reword the last sentence to match the logical data flow in the
> server:
>
>For example, a client application can differentiate whether they are
>interested in the configuration supplied to a server and that is
>supposed to be in effect, or the configuration that has been applied
> and is
>actually in effect on the server.
>
>
>When configuration that is in effect is different from configuration
>that was applied, many issues can result.  It becomes more difficult
>to operate the network properly due to limited visibility of actual
>status which makes it more difficult to analyze and understand what
>is going on in the network.  Services may be negatively affected
> (for
>example, breaking a service instance resulting in service is not
>properly delivered to a customer) and network resources be
>misallocated.
>
> Perhaps change "actual status" to "actual operational status".
>
> I also suggest changing the last sentence to:
>
>

[netmod] Publication has been requested for draft-ietf-netmod-nmda-diff-04

[Joel Jaeggli via Datatracker]

Joel Jaeggli has requested publication of draft-ietf-netmod-nmda-diff-04 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-nmda-diff/


___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] WGLC - Comparison of NMDA datastores - draft-ietf-netmod-nmda-diff-03

[Joel Jaeggli]

diff-04 should address the wglc comments

https://www.ietf.org/rfcdiff?url1=draft-ietf-netmod-nmda-diff-03=draft-ietf-netmod-nmda-diff-04
 
<https://www.ietf.org/rfcdiff?url1=draft-ietf-netmod-nmda-diff-03=draft-ietf-netmod-nmda-diff-04>

so we will progress to iesg.

> On Mar 8, 2020, at 17:10, Joel Jaeggli  wrote:
> 
> This working group last call completed on March 2nd.
> 
> Some corrections, and adjustments were requested in the discussion
> between Juergen and Alex. 
> 
> While the last call window did not see a lot of postive or negative
> support it aligns well with the dicussion at the last meeting on
> readiness to advance. I think we can call consensus on this point.
> 
> if a draft 04 appears shortly addressing the changes that were made I
> think we can move it along.
> 
> Thanks
> 
> joel
> 
> On 2/17/20 11:42, Joel Jaeggli wrote:
>> Greetings,
>> 
>> This was supposed to get processed shortly after IETF 106, however I lost 
>> track of it. We are therefore running a 2 week WGLC on 
>> draft-ietf-netmod-nmda-diff-03.
>> 
>> https://datatracker.ietf.org/doc/draft-ietf-netmod-nmda-diff/
>> 
>> the 02 - 03 diff is available here:
>> 
>> https://www.ietf.org/rfcdiff?url1=draft-ietf-netmod-nmda-diff-02=draft-ietf-netmod-nmda-diff-03
>> 
>> Please send email to the list indicating your support or concerns.
>> 
>> This WGLC will conclude Monday March 2nd.
>> 
>> 
>> Thank you,
>> NETMOD WG Chairs
>> 
> ___
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

[netmod] draft minutes culled from etherpad

[Joel Jaeggli]

FCs
Martin Mjorklund - module versioning draft makes this possible
Joe - moving on to github issues #48

---

Bo wu  -  presenting versioned yang schema

Jason Sterne design team has already taken an hour we should abreviate
or push to the end the remaining two dt docs
Lou - wouldlike feedback from the working group comments to the list.

Jason - yang schema selection

Kent - a similar dicussion will take place in the netconf meeting on monday

Lou - chairs will talk on how best to coordinate between groups.

---

Reshad - presenting yang schema comparison

>
> Not-Yet-Adopted items:
>
>    TITLE: A YANG Data model for ECA Policy Management
>    PRESENTER:  Authors
>    DRAFT(s)
>  https://tools.ietf.org/html/draft-wwx-netmod-event-yang-06

---

Qin Wu presenting a yang policy model for eca policy management.

Joel - 06 working group adaption revealed some issues that we should
address before considering adoption again igor / andy issues.

>    TITLE: YANG Data Node Self Explanation Tags
>    PRESENTER: Tao,Ran
>    DRAFT(s)
>  https://tools.ietf.org/html/draft-tao-netmod-yang-node-tags-01

---

Qin Wu presenting

Lou -  this is the normal point where we would ask for a hum will do it
on the list

>
>    TITLE: 3GPP's UML to YANG Object Module Mapping
>    PRESENTER: Balazs Lengyel
>    DRAFT(s)
>  

---

Balazas presenting

>    TITLE: CORECONF
>    PRESENTER: Carsten Bormann
>    DRAFT(s)
>  https://tools.ietf.org/html/draft-ietf-core-yang-cbor-12
>  https://tools.ietf.org/html/draft-ietf-core-sid-11
>  https://tools.ietf.org/html/draft-ietf-core-comi-09
>  https://tools.ietf.org/html/draft-ietf-core-yang-library-01

---

Carsten Bormann presenting

Virtual Bluesheet -- please add your name and affiliation

 NAME    AFFILIATION
Warren Kumari Google
Kent Watsen Watsen Networks
Lou Berger    LabN Consulting, LLC
Rob Wilton    Cisco
Jason Sterne Nokia
Carsten Bormann, TZI
Guangying zheng    Huawei
Martin Björklund
Bo Wu   Huawei
Dhruv Dhody Huawei-India
Ivaylo Petrov Acklio
Jan Lindblad  Cisco
Arunprabhu Kandasamy Acklio
Sergio Belotti  NOKIA
Balazs Lengyel  Ericsson
Yoshifumi Atarashi   　　　Alaxala
Tim Carey, Nokia
Joe Clarke   Cisco
Charles Eckel,  Cisco
Ray Atarashi   　　　IIJ-II
William Lupton  Broadband Forum
Joel Jaeggli Fastly
Yuji Tochio   Fujitsu
Susan Hares    Huawei
Reshad Rahman Cisco
Italo Busi    Huawei
Xufeng Liu    Volta Networks
David Sinicrope Ericsson
Qin Wu    Huawei
Gabriele Galimberti Cisco
Peng Liu   China Mobile



pEpkey.asc
Description: application/pgp-keys
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

[netmod] Agenda Items - Re: Network Modeling (netmod) WG Virtual Meeting: 2020-04-02

[Joel Jaeggli]

Netmod folks, now that this is scheduled if you have an item you'd like
on the agenda for this meeting which you had not previously gotten in to
us please send it along to netmod chairs netmod-cha...@ietf.org.

Agenda items proposed so far:

Netmod Ver DT presentation

draft-tao-netmod-yang-node-tags

YANG in 3GPP presentation

draft-ietf-netmod-yang-instance-file-format


If I've missed something please let me know.

Thanks

Chairs

On 3/26/20 15:11, IESG Secretary wrote:
> The Network Modeling (netmod) Working Group will hold
> a virtual interim meeting on 2020-04-02 from 11:00 to 13:00 UTC.
>
> Agenda:
> Agenda is forthcoming on https://mailarchive.ietf.org/arch/browse/netmod/ 
>
> Information about remote participation:
> Remote participation information will be obtained at the time of approval
>
> ___
> IETF-Announce mailing list
> ietf-annou...@ietf.org
> https://www.ietf.org/mailman/listinfo/ietf-announce
>


pEpkey.asc
Description: application/pgp-keys
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] WGLC - Comparison of NMDA datastores - draft-ietf-netmod-nmda-diff-03

[Joel Jaeggli]

This working group last call completed on March 2nd.

Some corrections, and adjustments were requested in the discussion
between Juergen and Alex. 

While the last call window did not see a lot of postive or negative
support it aligns well with the dicussion at the last meeting on
readiness to advance. I think we can call consensus on this point.

if a draft 04 appears shortly addressing the changes that were made I
think we can move it along.

Thanks

joel

On 2/17/20 11:42, Joel Jaeggli wrote:
> Greetings,
>
> This was supposed to get processed shortly after IETF 106, however I lost 
> track of it. We are therefore running a 2 week WGLC on 
> draft-ietf-netmod-nmda-diff-03.
>
> https://datatracker.ietf.org/doc/draft-ietf-netmod-nmda-diff/
>
> the 02 - 03 diff is available here:
>
> https://www.ietf.org/rfcdiff?url1=draft-ietf-netmod-nmda-diff-02=draft-ietf-netmod-nmda-diff-03
>
> Please send email to the list indicating your support or concerns.
>
> This WGLC will conclude Monday March 2nd.
>
>
> Thank you,
> NETMOD WG Chairs
>


pEpkey.asc
Description: application/pgp-keys
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

[netmod] NETMOD IETF 107 update and call for agenda items

[Joel Jaeggli]

All,

This note is somewhat late, but we felt the need to get it out this week.

According to the IETF 107 meeting agenda [1], NETMOD is
scheduled to meet a total of 3 hours across 2 sessions, both on
Monday:
    13:30-15:30    Monday Afternoon session I
    18:10-19:10    Monday Afternoon session III

This is clearly will be an atypical meeting, with more remote
attendees than usual.  This includes all three WG chairs.

If you are interested in presenting to the WG, please send your
request not later than COB Monday March 9 to the "netmod-chairs"
alias (CC-ed). Please include the following information for each
presentation request:

 - name of the drafts (if any)
 - name of presentation (usually the title of the draft)
 - name of the presenter(s)
 - desired time request (in minutes)
 - local or remote?

Please be advised that the draft submission cutoff deadline [2] is
this coming Monday.  Please update your drafts before then!

Thank you,
NETMOD Chairs

[1] https://datatracker.ietf.org/meeting/107/agenda.html
[2] https://datatracker.ietf.org/meeting/107/important-dates



pEpkey.asc
Description: application/pgp-keys
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] draft-ietf-netmod-nmda-diff - IPR verfication request

[Joel Jaeggli]

thanks

joel

On 2/25/20 12:17, Alexander Clemm wrote:
> Yes, the IPR has been disclosed in compliance with IETF IPR rules.  
> (Back in 2017; see datatracker)
> --- Alex
>
>> -Original Message-
>> From: netmod  On Behalf Of Joel Jaeggli
>> Sent: Monday, February 17, 2020 11:45 AM
>> To: draft-ietf-netmod-nmda-d...@ietf.org; netmod@ietf.org
>> Subject: [netmod] draft-ietf-netmod-nmda-diff - IPR verfication request
>>
>> Authors, Contributors, WG,
>>
>> As part of the preparation for WG Last Call:
>>
>> Are you aware of any IPR that applies to drafts identified above?
>>
>> Please state either:
>>
>> "No, I'm not aware of any IPR that applies to this draft"
>> or
>> "Yes, I'm aware of IPR that applies to this draft"
>>
>> If so, has this IPR been disclosed in compliance with IETF IPR rules (see 
>> RFCs
>> 3669, 5378 and 8179 for more details)?
>>
>> If yes to the above, please state either:
>>
>> "Yes, the IPR has been disclosed in compliance with IETF IPR rules"
>> or
>> "No, the IPR has not been disclosed"
>>
>> If you answer no, please provide any additional details you think 
>> appropriate.
>>
>> If you are listed as a document author or contributor please answer the above
>> by responding to this email regardless of whether or not you are aware of any
>> relevant IPR. This document will not advance to the next stage until a 
>> response
>> has been received from each author and listed contributor. NOTE: THIS
>> APPLIES TO ALL OF YOU LISTED IN THIS MESSAGE'S TO LINES.
>>
>> If you are on the WG email list or attend WG meetings but are not listed as 
>> an
>> author or contributor, we remind you of your obligations under the IETF IPR
>> rules which encourages you to notify the IETF if you are aware of IPR of 
>> others
>> on an IETF contribution, or to refrain from participating in any 
>> contribution or
>> discussion related to your undisclosed IPR. For more information, please see
>> the RFCs listed above and
>> https://nam03.safelinks.protection.outlook.com/?url=http%3A%2F%2Ftrac.to
>> ols.ietf.org%2Fgroup%2Fiesg%2Ftrac%2Fwiki%2FIntellectualPropertydat
>> a=02%7C01%7Calex%40futurewei.com%7C48a1503b85ce4447c93008d7b3e1d
>> 732%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637175654901969
>> 545sdata=2AeUnZCMLnT4c34lcAQ0j4PAjb%2F%2BwAavkLfcXvptQv4%3
>> Dreserved=0.
>>
>> Thank you,
>> NetMod WG Chairs
>>
>> PS Please include all listed in the headers of this message in your response.
>>
>


pEpkey.asc
Description: application/pgp-keys
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

[netmod] IPR poll on draft-wwx-netmod-event-yang

[Joel Jaeggli]

Authors, Contributors, WG,

As part of 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 that applies to this draft"
or
"Yes, I'm aware of IPR that applies to this draft"

If so, has this IPR been disclosed in compliance with IETF IPR rules
(see RFCs 3669, 5378 and 8179 for more details)?

If yes to the above, please state either:

"Yes, the IPR has been disclosed in compliance with IETF IPR rules"
or
"No, the IPR has not been disclosed"

If you answer no, please provide any additional details you think
appropriate.

If you are listed as a document author or contributor please answer the
above by responding to this email regardless of whether or not you are
aware of any relevant IPR. This document will not advance to the next
stage until a response has been received from each author and listed
contributor. NOTE: THIS APPLIES TO ALL OF YOU LISTED IN THIS MESSAGE'S
TO LINES.

If you are on the WG email list or attend WG meetings but are not listed
as an author or contributor, we remind you of your obligations under
the IETF IPR rules which encourages you to notify the IETF if you are
aware of IPR of others on an IETF contribution, or to refrain from
participating in any contribution or discussion related to your
undisclosed IPR. For more information, please see the RFCs listed above
and
http://trac.tools.ietf.org/group/iesg/trac/wiki/IntellectualProperty.

Thank you,
NetMod WG Chairs

PS Please include all listed in the headers of this message in your
response.



pEpkey.asc
Description: application/pgp-keys
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

[netmod] Adoption poll for draft-wwx-netmod-event-yang

[Joel Jaeggli]

This email begins a 2 week working group adoption poll for:

https://tools.ietf.org/html/draft-wwx-netmod-event-yang-06

Please voice your support or objections before the poll completes on
March 3rd.

Thanks
joel


pEpkey.asc
Description: application/pgp-keys
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

[netmod] draft-ietf-netmod-nmda-diff - IPR verfication request

[Joel Jaeggli]

Authors, Contributors, WG,

As part of the preparation for WG Last Call:

Are you aware of any IPR that applies to drafts identified above?

Please state either:

"No, I'm not aware of any IPR that applies to this draft"
or
"Yes, I'm aware of IPR that applies to this draft"

If so, has this IPR been disclosed in compliance with IETF IPR rules
(see RFCs 3669, 5378 and 8179 for more details)?

If yes to the above, please state either:

"Yes, the IPR has been disclosed in compliance with IETF IPR rules"
or
"No, the IPR has not been disclosed"

If you answer no, please provide any additional details you think
appropriate.

If you are listed as a document author or contributor please answer the
above by responding to this email regardless of whether or not you are
aware of any relevant IPR. This document will not advance to the next
stage until a response has been received from each author and listed
contributor. NOTE: THIS APPLIES TO ALL OF YOU LISTED IN THIS MESSAGE'S
TO LINES.

If you are on the WG email list or attend WG meetings but are not listed
as an author or contributor, we remind you of your obligations under
the IETF IPR rules which encourages you to notify the IETF if you are
aware of IPR of others on an IETF contribution, or to refrain from
participating in any contribution or discussion related to your
undisclosed IPR. For more information, please see the RFCs listed above
and
http://trac.tools.ietf.org/group/iesg/trac/wiki/IntellectualProperty.

Thank you,
NetMod WG Chairs

PS Please include all listed in the headers of this message in your
response.




pEpkey.asc
Description: application/pgp-keys
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

[netmod] WGLC - Comparison of NMDA datastores - draft-ietf-netmod-nmda-diff-03

[Joel Jaeggli]

Greetings,

This was supposed to get processed shortly after IETF 106, however I lost track 
of it. We are therefore running a 2 week WGLC on draft-ietf-netmod-nmda-diff-03.

https://datatracker.ietf.org/doc/draft-ietf-netmod-nmda-diff/

the 02 - 03 diff is available here:

https://www.ietf.org/rfcdiff?url1=draft-ietf-netmod-nmda-diff-02=draft-ietf-netmod-nmda-diff-03

Please send email to the list indicating your support or concerns.

This WGLC will conclude Monday March 2nd.


Thank you,
NETMOD WG Chairs



pEpkey.asc
Description: application/pgp-keys
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] netmod - New Meeting Session Request for IETF 107

[joel jaeggli]

fyi,

made this request based on the last one.

On 1/12/20 11:04, IETF Meeting Session Request Tool wrote:
> 
> 
> A new meeting session request has just been submitted by Joel Jaeggli, a 
> Chair of the netmod working group.
> 
> 
> -
> Working Group Name: Network Modeling
> Area Name: Operations and Management Area
> Session Requester: Joel Jaeggli
> 
> Number of Sessions: 2
> Length of Session(s):  2 Hours, 1 Hour
> Number of Attendees: 100
> Conflicts to Avoid: 
>  Chair Conflict: netconf
>  Technology Overlap: rtgwg i2rs teas
>  Key Participant Conflict: saag
> 
> 
> People who must be present:
>   Lou Berger
>   Joel Jaeggli
>   Kent Watsen
>   Ignas Bagdonas
> 
> Resources Requested:
> 
> Special Requests:
>   
> -
> 




signature.asc
Description: OpenPGP digital signature
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] Conclusion WG Last Call: draft-ietf-netmod-yang-data-ext version 4

[Joel Jaeggli]

> On Oct 13, 2019, at 08:28, Andy Bierman  wrote:
> 
> 
> 
> On Sat, Oct 12, 2019 at 12:08 PM Joel Jaeggli  <mailto:joe...@bogus.com>> wrote:
> This concludes the netmod WG last call for 
> 
> draft-ietf-netmod-yang-data-ext version 4...
> 
> There was a modest amount of commentary generally positive, during the last 
> call period with some requests for clarification (Qin wu) and some minor nits 
> (Robert Wilton). 
> 
> It might be good to have closure on the last email in that cycle.
> 
> https://mailarchive.ietf.org/arch/msg/netmod/QRWFS4fnd-jJ8Ajhxpr3pG0nuvY 
> <https://mailarchive.ietf.org/arch/msg/netmod/QRWFS4fnd-jJ8Ajhxpr3pG0nuvY>
> 
> 
> 
> It is not clear which issues remain open from this review.
> The main issues seem to be:
> 
>1) Put this functionality in yang-next instead of this document
> * The WG decided several times to go forward with this document
> 
>2) When there is a yang-next, these extensions will not change or go away
> * This issue was not discussed as part of this draft. The WG should make
>these decisions if and when yang-next is a work item
> 
>3) There needs to be machine-readable statements to define where a 
> structure can be used
> * The WG decided to just use description-stmt for this purpose
> 
> I do not know if this list is complete or correct.

That sounds like closure to me.

Thank you.

> That is for the WG Chairs to decide.
> 
> The 'structure' extension is basically a copy of container-stmt with some 
> stuff removed.
> It is not a data node, rpc, or notification. Its use is 
> implementation-dependent.
> A container-stmt is tightly coupled to protocols and datastores.  A structure 
> is
> not coupled to anything.  There can be notifications and actions defined 
> nested within
> a structure's data-def-stmts. (Who knows what this means - it is 
> implementation-specific.)
> 
> 
> 
> but it looks like the document is ready to advance based on this and prior wg 
> discussion.
> 
> Thanks
> Joel
> 
> Andy
>  
> 
>> On Sep 26, 2019, at 22:32, Joel Jaeggli > <mailto:joe...@bogus.com>> wrote:
>> 
>> All,
>> 
>> This starts a two week working group last call for  
>> draft-ietf-netmod-yang-data-ext-04
>> 
>> The working group last call ends on  Friday October 11th 2019.  Please send 
>> your comments to the working group mailing list.
>> 
>> Positive comments, e.g., "I've reviewed this document and believe it is 
>> ready for publication", are welcome!  This is useful and important, even 
>> from authors.
>> 
>> https://tools.ietf.org/html/draft-ietf-netmod-yang-data-ext-04 
>> <https://tools.ietf.org/html/draft-ietf-netmod-yang-data-ext-04>
>> 
>> The diff from 03, produced prior to IETF 105 is available here:
>> 
>> https://tools.ietf.org/rfcdiff?difftype=--hwdiff=draft-ietf-netmod-yang-data-ext-04.txt
>>  
>> <https://tools.ietf.org/rfcdiff?difftype=--hwdiff=draft-ietf-netmod-yang-data-ext-04.txt>
>> 
>> Thanks
>> Joel
>> 
> 
> ___
> netmod mailing list
> netmod@ietf.org <mailto:netmod@ietf.org>
> https://www.ietf.org/mailman/listinfo/netmod 
> <https://www.ietf.org/mailman/listinfo/netmod>
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

[netmod] Publication has been requested for draft-ietf-netmod-yang-data-ext-04

[Joel Jaeggli via Datatracker]

Joel Jaeggli has requested publication of draft-ietf-netmod-yang-data-ext-04 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-yang-data-ext/

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

[netmod] Conclusion WG Last Call: draft-ietf-netmod-yang-data-ext version 4

[Joel Jaeggli]

This concludes the netmod WG last call for 

draft-ietf-netmod-yang-data-ext version 4...

There was a modest amount of commentary generally positive, during the last 
call period with some requests for clarification (Qin wu) and some minor nits 
(Robert Wilton). 

It might be good to have closure on the last email in that cycle.

https://mailarchive.ietf.org/arch/msg/netmod/QRWFS4fnd-jJ8Ajhxpr3pG0nuvY 
<https://mailarchive.ietf.org/arch/msg/netmod/QRWFS4fnd-jJ8Ajhxpr3pG0nuvY>

but it looks like the document is ready to advance based on this and prior wg 
discussion.

Thanks
Joel

> On Sep 26, 2019, at 22:32, Joel Jaeggli  wrote:
> 
> All,
> 
> This starts a two week working group last call for  
> draft-ietf-netmod-yang-data-ext-04
> 
> The working group last call ends on  Friday October 11th 2019.  Please send 
> your comments to the working group mailing list.
> 
> Positive comments, e.g., "I've reviewed this document and believe it is ready 
> for publication", are welcome!  This is useful and important, even from 
> authors.
> 
> https://tools.ietf.org/html/draft-ietf-netmod-yang-data-ext-04 
> <https://tools.ietf.org/html/draft-ietf-netmod-yang-data-ext-04>
> 
> The diff from 03, produced prior to IETF 105 is available here:
> 
> https://tools.ietf.org/rfcdiff?difftype=--hwdiff=draft-ietf-netmod-yang-data-ext-04.txt
>  
> <https://tools.ietf.org/rfcdiff?difftype=--hwdiff=draft-ietf-netmod-yang-data-ext-04.txt>
> 
> Thanks
> Joel
> 

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] [Editorial Errata Reported] RFC7950 (5642)

[Joel Jaeggli]

> On Sep 6, 2019, at 12:27, Warren Kumari  wrote:
> 
> On Thu, Feb 21, 2019 at 1:53 PM Andy Bierman  > wrote:
>> 
>> 
>> 
>> On Thu, Feb 21, 2019 at 10:33 AM Martin Bjorklund  wrote:
>>> 
>>> Andy Bierman  wrote:
 On Thu, Feb 21, 2019 at 10:07 AM Peter Loborg 
 wrote:
 
> 
> 
> Your example is fine – but the gammar is ch14 specifies something
> different:
> 
> 
> 
> enum-stmt   = enum-keyword sep string optsep
> 
> (";" /
> 
>  "{" stmtsep
> 
>  ;; these stmts can appear in any order
> 
>  *if-feature-stmt
> 
>  [value-stmt]
> 
>  [status-stmt]
> 
>  [description-stmt]
> 
>  [reference-stmt]
> 
>   "}") stmtsep
> 
> 
> 
> It clearly states  string, not quoted-string. These two have the following
> rules:
> 
> 
> 
> quoted-string   = (DQUOTE string DQUOTE) / (SQUOTE string SQUOTE)
> 
> 
> 
> string  = < an unquoted string, as returned by >
> 
> < the scanner, that matches the rule >
> 
> < yang-string >
> 
> 
> 
 
 
 The text in 9.6.4 is correct.
 The ABNF is wrong.
>>> 
>>> No, the ABNF is correct.  The ABNF doens't handle concatenation etc.
>>> The idea is that the scanner handles quotes and concatenation and
>>> returns a "string".
>>> 
>> 
>> 
>> OK -- it is confusing that the rule quoted-string exists, but it
>> is only for key and leaf-list predicates.
> 
> Hi all,
> 
> I'm trying to go through and do some cleanup of the dangling Errata.
> I'm *certainly* not an expert here, and so am relying on y'all.
>> From what I've been able to figure out, the consensus is that this
> Errata should be rejected, yes?
> W

yes,

this is done.

as Lada noted some time ago the explanation could be more clear.

I guess the explanation could be improved. Section 6.1.3 talks about unquoted,
single- and double-quoted strings, but then the term "string" is used in the
ABNF to mean the argument string, i.e. the result of scanner preprocessing
(concatenation, substitution of escaped characters). Maybe we can use another
term, such as "argstring", for the latter.

Also, the term scanner only appears in the ABNF appendix. Some explanation of
the preprocessing stage in the main text would also help.

but Juergen and Martin's point contentions still hold that ABNF works as 
described.

>> 
>> 
>>> 
>>> 
>>> /martin
>>> 
>> 
>> Andy
>> 
>>> 
>>> 
>>> 
 
 
 
> …and in 6.1.3 we can read that:
> 
>   An unquoted string is any sequence of characters that does not
> 
>   contain any space, tab, carriage return, or line feed characters, a
> 
>   single or double quote character, a semicolon (";"), braces ("{" or
> 
>   "}"), or comment sequences ("//", "/*", or "*/").
> 
> 
> 
>   Note that any keyword can legally appear as an unquoted string.
> 
> 
> 
> Since the section so clearly writes about single quoted strings and double
> quoted strings, there can unfortunately be no interpretation that would
> allow “identifier” to be called an unquoted string – even though it 
> follows
> the rules about limited character contents.
> 
> 
> 
> Hence – this is not a matter of opinion – it’s a matter of reading what’s
> actually written in the RFC.
> 
> 
> 
> But on the subject of opinion…
> 
> 
> 
>  enum "This is also legal";   // should definitely always be illegal
> 
> 
> 
> …as we cannot create a language binding to enum constructs in any major
> programming languages.
> 
> 
> 
 
 There are many aspects of YANG that do not map directly to programming
 languages,
 such as allowing '.' in identifiers.
 
 
 
> Br,
> 
> Peter
> 
 
 
 Andy
 
 
> 
> 
> 
> 
> *From:* Andy Bierman 
> *Sent:* den 21 februari 2019 18:45
> *To:* Martin Bjorklund 
> *Cc:* RFC Editor ; Ignas Bagdonas <
> ibagd...@gmail.com>; NetMod WG ; Peter Loborg <
> peter.lob...@ericsson.com>; Warren Kumari 
> *Subject:* Re: [netmod] [Editorial Errata Reported] RFC7950 (5642)
> 
> 
> 
> 
> 
> 
> 
> On Thu, Feb 21, 2019 at 8:53 AM Martin Bjorklund  wrote:
> 
> RFC Errata System  wrote:
>> The following errata report has been submitted for RFC7950,
>> "The YANG 1.1 Data Modeling Language".
>> 
>> --
>> You may review the report below and at:
>> 

[netmod] IPR check draft-ietf-netmod-yang-data-ext-04

[Joel Jaeggli]

Authors, Contributors, WG,

As part of WG Last Call for  draft-ietf-netmod-yang-data-ext-04

Are you aware of any IPR that applies to drafts identified above?

Please state either:

"No, I'm not aware of any IPR that applies to this draft"
or
"Yes, I'm aware of IPR that applies to this draft"

If so, has this IPR been disclosed in compliance with IETF IPR rules
(see RFCs 3669, 5378 and 8179 for more details)?

If yes to the above, please state either:

"Yes, the IPR has been disclosed in compliance with IETF IPR rules"
or
"No, the IPR has not been disclosed"

If you answer no, please provide any additional details you think
appropriate.

If you are listed as a document author or contributor please answer the
above by responding to this email regardless of whether or not you are
aware of any relevant IPR. This document will not advance to the next
stage until a response has been received from each author and listed
contributor. NOTE: THIS APPLIES TO ALL OF YOU LISTED IN THIS MESSAGE'S
TO LINES.

If you are on the WG email list or attend WG meetings but are not listed
as an author or contributor, we remind you of your obligations under
the IETF IPR rules which encourages you to notify the IETF if you are
aware of IPR of others on an IETF contribution, or to refrain from
participating in any contribution or discussion related to your
undisclosed IPR. For more information, please see the RFCs listed above
and
http://trac.tools.ietf.org/group/iesg/trac/wiki/IntellectualProperty 
.

Thank you,
NetMod WG Chairs

PS Please include all listed in the headers of this message in your
response.

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

[netmod] WG Last Call: draft-ietf-netmod-yang-data-ext version 4

[Joel Jaeggli]

All,

This starts a two week working group last call for  
draft-ietf-netmod-yang-data-ext-04

The working group last call ends on  Friday October 11th 2019.  Please send 
your comments to the working group mailing list.

Positive comments, e.g., "I've reviewed this document and believe it is ready 
for publication", are welcome!  This is useful and important, even from authors.

https://tools.ietf.org/html/draft-ietf-netmod-yang-data-ext-04 


The diff from 03, produced prior to IETF 105 is available here:

https://tools.ietf.org/rfcdiff?difftype=--hwdiff=draft-ietf-netmod-yang-data-ext-04.txt
 


Thanks
Joel

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

[netmod] Upcoming important Dates leading to IETF 106

[Joel Jaeggli]

Folks, 

It's worth noting that there are several important upcoming dates between the 
present and IETF 106 November 16-22 2019.


The early bird deadline for registration is this coming  Monday, September 30th.

October 18th is publication of the initial agenda

November 4th is Draft submission cutoff

November 6th the chairs have to publish the initial meeting agenda.

These are dates that we are going to be working towards and around for 
currently in the queue documents as well as new work.

Thanks
The NETMOD Chairs
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] Processing open errata in the the netmod working group

[Joel Jaeggli]

> On Sep 23, 2019, at 01:08, Martin Bjorklund  wrote:
> 
> Joel Jaeggli  wrote:
>> Folks,
>> 
>> Over the course of this we we intend to process reported errata that
>> we have outstanding in netmod
> 
> I started to go through the list and comment, but then I realized that
> you probably didn't ask for comments?  This was just a FYI?

Largely, you have commented on some of them already. I am reading through them 
with respect to outstanding comments.

joel

> 
> 
> /martin
> 

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

[netmod] Open Errata 5517 RFC 7950 https://www.rfc-editor.org/errata/eid5517

[Joel Jaeggli]

Reported By: Rohit R Ranade

Section 10.4.2 says:

   The derived-from-or-self() function returns "true" if any node in the
   argument "nodes" is a node of type "identityref" and its value is an
   identity that is equal to or derived from (see Section 7.18.2) the
   identity "identity"; otherwise, it returns "false".

It should say:

 The derived-from-or-self() function returns "true" if any node in the
 argument "nodes" is a node of type equal to or derived 
 from "identityref" and its value is an identity that is equal to or
 derived from (see Section 7.18.2) the identity "identity"; 
 otherwise, it returns "false".

Martin Bjorklund wrote

I agree that the text needs clarification.  However, I propose this
text instead:

 The derived-from-or-self() function returns "true" if any node in the
 argument "nodes" is a node of type "identityref" or a type derived
 from "identityref", and its value is an identity that is equal to or
 derived from (see Section 7.18.2) the identity "identity"; 
 otherwise, it returns "false".


Ladislav Lhotka wrote

This formulation is better.

It is somewhat confusing that "derived from" has two unrelated meanings in the
same sentence.


This errata is processed as accepted,  the errata clarifies that the function 
returns true from the case where "a node is of a type derived
 from "identityref"" in addition to the case where the node is of type 
indetityref. this is a clarification and can we believe be read properly in 
conjunction with the existing RFC.


Thanks
Joel


___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

[netmod] Processing open errata in the the netmod working group

[Joel Jaeggli]

Folks,

Over the course of this we we intend to process reported errata that we have 
outstanding in netmod

currently in the queue are the following:

https://www.rfc-editor.org/errata_search.php?rec_status=2_acronym=netmod=table
 


RFC7950 (5517 )  10.4.2  
Technical   netmod (ops)Rohit R Ranade  TEXT2018-10-08
RFC7950 (5617 )  14  
Technical   netmod (ops)Marek Michalak, Pawel Koch  TEXT
2019-01-30
RFC7950 (5663 )  14  
Technical   netmod (ops)Ebben Aries TEXT2019-03-18
RFC7950 (5642 )  9.6.4   
Editorial   netmod (ops)Peter LoborgTEXT2019-02-21
RFC8342 (5514 )  C.1 
Technical   netmod (ops)Rohit R Ranade  TEXT2018-10-05
RFC8519 (5762 )  4.1 
Technical   netmod (ops)Qin WU  TEXT2019-06-24

the first 4 concern yang 1.1 5514 concerns nmda, and the  last one  concerns 
the act model.



___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

[netmod] draft-ietf-netmod-module-tags needs a correction

[Joel Jaeggli]

Folks Ignas,

draft-ietf-netmod-module-tags, currently in IESG review is in need of a
a fairly significant edit, notably the addition of an appendix covering
the nmda state. It seems wiser to pull it back and add that rather than
proceed forward with the document as is.

Thanks

joel



pEpkey.asc
Description: application/pgp-keys
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

[netmod] Netmod Errata posted since IETF 104

[Joel Jaeggli]

The following errata have been lodged since IETF 104. Well will have a
brief section of the agenda devoted to the errata. If you have strong
opinions for or against any of the unverified errata please come
prepared to discuss them.  The two with recent list discussion are noted
with proposed outcomes.

RFC 6244

verified editorial - https://www.rfc-editor.org/errata/eid5760

RFC 7950

unverified technical - https://www.rfc-editor.org/errata/eid5517

unverified technical - https://www.rfc-editor.org/errata/eid5617

unverified editorial - https://www.rfc-editor.org/errata/eid5642

unverified technical - https://www.rfc-editor.org/errata/eid5663

unverified technical - https://www.rfc-editor.org/errata/eid5784
(changes the specification should be rejected)

RFC 8407

verified editorial - https://www.rfc-editor.org/errata/eid5693

RFC 8519

unverified technical - https://www.rfc-editor.org/errata/eid5762
(changes the specification should be rejected)

Thanks
Netmod Chairs



pEpkey.asc
Description: application/pgp-keys
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

[netmod] Reminder Slides for Monday 7/22

[Joel Jaeggli]

Reminder,

Our meeting is pretty early in this IETF Meeting at 13:30 on Monday
7/22. As a result of the timing having slides sent to the chairs this
weekend so that they can be uploaded and included in the agenda for
consumption prior to and during the meeting is greatly appreciated.

Thanks

Netmod Chairs




pEpkey.asc
Description: application/pgp-keys
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

[netmod] Reminder IETF 105 - document submission deadline

[Joel Jaeggli]

Folks,


Quick reminder that the internet draft submission deadline for IETF 105 is 
2019-07-08  the following (Monday) at UTC 23:59.  

Thanks
Netmod Chairs
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

[netmod] ietf 105 prelimary agenda - netmod

[joel jaeggli]

Folks,

In the preliminary agenda NETMOD has two back to back sessions on Monday
July 22, 13:30 - 15:30 and then 15:50 - 17:50. This is could be subject
to change.

NETCONF is also scheduled for Monday Jully 22 in the morning.

It's time to start thinking about meeting submissions for netmod. The
chairs had to submit a preliminary agenda in in a little more than 2
weeks on 2019-07-10.


Thanks
NETMOD chairs



signature.asc
Description: OpenPGP digital signature
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

[netmod] IETF 105 key dates

[joel jaeggli]

This week we are coming up on a month out from the The IETF 105 meeting
in Montreal.

Some milestones between now and then.

06/21 (friday) we will get the preliminary agenda and 6/28 the final
version of the scehedule will be published.

07/08 Is the cutoff date for draft submission. It would be best if we
are to reserve time on the agenda that documents be submitted and
surfaced on the mailing list well before then.

07/10 Our preliminary agenda is due.

07/20 IETF 105 commences.

Thanks for keeping these in mind.
Joel




signature.asc
Description: OpenPGP digital signature
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] draft item 104 meeting 1/2 minutes

[joel jaeggli]

I posted a lightly edited version of this as the meeting minutes in the
tracker.

regards
joel

On 4/13/19 15:35, Joel Jaeggli wrote:
> IETF 104 netmod meeting minutes
> 
> Monday Session 1 - Second half of netconf slot, 2019/03/25 1000
> https://www.youtube.com/watch?v=aw0fRh1pvec
> 
> Monday Session 2 - 2019/03/25 1350
> https://www.youtube.com/watch?v=GVSYk_PLPNY
> 
> * Monday Session 1 *
> 
>   Rob Wilton and Company (55 min)
>   YANG Versioning Design Team Update
> 
> Requirements Draft update – Joe Clarke (5 mins)
> draft-verdt-netmod-yang-versioning-reqs-02
> • Design Team update & Solution overview – Rob Wilton (10 mins)
> • Semantic versioning for modules – Balazs Lengyel (20 mins)
> draft-verdt-netmod-yang-semver-00
> • Semantic versioning for YANG schema – Rob Wilton (10 mins)
> draft-rwilton-netmod-yang-packages-01
> • Schema version selection – Reshad Rahman (10 mins)
> draft-wilton-netmod-yang-ver-selection-00
> 
> Joe presenting on requirements - 
> https://datatracker.ietf.org/meeting/104/materials/slides-104-netmod-sessa-yang-versioning-design-team-update-00.pdf
> 
> slide 10: who feels rfc7950 section 11 is sufficient and does not require 
> changes?
> 
> Martin: Is the question really about NBC
> 
> Joe: That is later
> 
> Lada: Section 11 doesn't belong in yang definition
> 
> Joe: Interesting observation, that was not discussed as part of the solution 
> discussion. 
> 
> Lou: Would be more comfortable with question if it didn't include section 11 
> in the question
> 
> Joe: The question is a bit rough, but wanted to scope the question, e.g., 
> exclude yang next discussion
> 
> On questions 2: "Are NBC changes required?"
> 
> Juergen: question is under specified.
> 
> joe: are nbc changes required (allowed) to an existing node in a given yang 
> module?
> 
> Martin: (Andy's solution from the list) They happen, might be better to 
> describe them as sometime more like a deviation, i.e. a way to express them, 
> but don't indicate that they are good.
> 
> Acee: It would be useful to describe the workflow for clients and servers.
> 
> Joe: We are trying to describe this as guidelines in the solutions document.
> 
> lou: I think we all agree that we need a better solution about non-backward 
> compatible changes.
> 
> joe: do you object to what the requirements documents?
> 
> lou: not but it could be improved to not specify the solution.
> 
> statement I don't really care if it's published an RFC I think it's very 
> important that we have
> a working group document that establishes consensus on or defines the 
> consensus of what it is we're trying to solve
> 
> martin b: agreed, but want it understand if it will be published or not?
> 
> Kent: (Polling)
>   Should requirements doc be published as an RFC - very few
>   Sould requirements doc NOT be published as an RFC -  the same
>   Should we defer this decision - most (~2x more, but still few in the room)
>   
> slide 14
> 
> joe:  is branching required, and if so how much branching is needed and for 
> clarity?
> 
> Christian Hopps:(For branching) Should narrow down the scope? Focus on vendor 
> specific modules. don't see any  need for branching in standards models. 
> vednor models have release trains and other requirements.
> 
> joe: just because something is supported doesn't mean one has to use it.
> 
> I don't know if it's still valid but this was heard on the design team a few 
> months ago so maybe there is a need maybe not here in ops area that we've 
> heard but in routing area that was something that came up on one of our calls
> 
> lada: agree that ietf shouldn't need branches
> 
> joe: from requirements standpoint yes branching should be supported.
> 
> lou: replace required with allowed
> 
> rob: l2sm is an example. the just published a new revision to get around lots 
> of bugs.
> 
> andy: multiple release trains only for vendors and other sdos. 
> 
> joe: sounds like this should be allowed.
> 
> tim c: we do have this model in place in the bbf
> 
> runs out of time for additonal presentations on the agenda.
> 
> scheduling of informal open YANG versioning Design Team meeting 03/28 at ietf.
> 
> meeting ends.
> 
> * Monday Session 2 *
> 
>Introduction
> 
>  Chairs (10 minutes)
>  Session Intro & WG Status
> 
> Chairs: the following will be LCed after the meeting 
> –draft-ietf-netmod-intf-ext-yang-07
> –draft-ietf-netmod-sub-intf-vlan-model-05 
> 
> Robert Sparks: IETF is managing YANG Catalog 
> 
>WG documents items:
> 
>  Balazs Lengyel (10 min)
>  YANG Instance Data File Format

[netmod] draft item 104 meeting 1/2 minutes

[Joel Jaeggli]

IETF 104 netmod meeting minutes

Monday Session 1 - Second half of netconf slot, 2019/03/25 1000
https://www.youtube.com/watch?v=aw0fRh1pvec

Monday Session 2 - 2019/03/25 1350
https://www.youtube.com/watch?v=GVSYk_PLPNY

* Monday Session 1 *

  Rob Wilton and Company (55 min)
  YANG Versioning Design Team Update

Requirements Draft update – Joe Clarke (5 mins)
draft-verdt-netmod-yang-versioning-reqs-02
• Design Team update & Solution overview – Rob Wilton (10 mins)
• Semantic versioning for modules – Balazs Lengyel (20 mins)
draft-verdt-netmod-yang-semver-00
• Semantic versioning for YANG schema – Rob Wilton (10 mins)
draft-rwilton-netmod-yang-packages-01
• Schema version selection – Reshad Rahman (10 mins)
draft-wilton-netmod-yang-ver-selection-00

Joe presenting on requirements - 
https://datatracker.ietf.org/meeting/104/materials/slides-104-netmod-sessa-yang-versioning-design-team-update-00.pdf

slide 10: who feels rfc7950 section 11 is sufficient and does not require 
changes?

Martin: Is the question really about NBC

Joe: That is later

Lada: Section 11 doesn't belong in yang definition

Joe: Interesting observation, that was not discussed as part of the solution 
discussion. 

Lou: Would be more comfortable with question if it didn't include section 11 in 
the question

Joe: The question is a bit rough, but wanted to scope the question, e.g., 
exclude yang next discussion

On questions 2: "Are NBC changes required?"

Juergen: question is under specified.

joe: are nbc changes required (allowed) to an existing node in a given yang 
module?

Martin: (Andy's solution from the list) They happen, might be better to 
describe them as sometime more like a deviation, i.e. a way to express them, 
but don't indicate that they are good.

Acee: It would be useful to describe the workflow for clients and servers.

Joe: We are trying to describe this as guidelines in the solutions document.

lou: I think we all agree that we need a better solution about non-backward 
compatible changes.

joe: do you object to what the requirements documents?

lou: not but it could be improved to not specify the solution.

statement I don't really care if it's published an RFC I think it's very 
important that we have
a working group document that establishes consensus on or defines the consensus 
of what it is we're trying to solve

martin b: agreed, but want it understand if it will be published or not?

Kent: (Polling)
  Should requirements doc be published as an RFC - very few
  Sould requirements doc NOT be published as an RFC -  the same
  Should we defer this decision - most (~2x more, but still few in the room)
  
slide 14

joe:  is branching required, and if so how much branching is needed and for 
clarity?

Christian Hopps:(For branching) Should narrow down the scope? Focus on vendor 
specific modules. don't see any  need for branching in standards models. vednor 
models have release trains and other requirements.

joe: just because something is supported doesn't mean one has to use it.

I don't know if it's still valid but this was heard on the design team a few 
months ago so maybe there is a need maybe not here in ops area that we've heard 
but in routing area that was something that came up on one of our calls

lada: agree that ietf shouldn't need branches

joe: from requirements standpoint yes branching should be supported.

lou: replace required with allowed

rob: l2sm is an example. the just published a new revision to get around lots 
of bugs.

andy: multiple release trains only for vendors and other sdos. 

joe: sounds like this should be allowed.

tim c: we do have this model in place in the bbf

runs out of time for additonal presentations on the agenda.

scheduling of informal open YANG versioning Design Team meeting 03/28 at ietf.

meeting ends.

* Monday Session 2 *

   Introduction

 Chairs (10 minutes)
 Session Intro & WG Status

Chairs: the following will be LCed after the meeting 
–draft-ietf-netmod-intf-ext-yang-07
–draft-ietf-netmod-sub-intf-vlan-model-05 

Robert Sparks: IETF is managing YANG Catalog 

   WG documents items:

 Balazs Lengyel (10 min)
 YANG Instance Data File Format
 https://tools.ietf.org/html/draft-ietf-netmod-yang-instance-file-format-02

Balazs Presenting.

kent: could I get a sense for the room how many people have read this draft 
raise your hand please this version of the draft yes so it's a few oh good 

after we see some more review comments we can gauge where we are on 
last call so it's really


 Martin or Andy (10 min)
 YANG Data Structure Extensions
 https://tools.ietf.org/html/draft-ietf-netmod-yang-data-ext-02

martin presenting


lada - don't see benfit of using restconf yang data model

joe: yang catalog would be of benifit from instance data

erick: would use it for yang push

kent: is it important to maintain the -ext structure?

rob: why does the instance document need to use yang data at all? (lada's 
comment)

Re: [netmod] Question on draft-wu-netmod-factory-default

[joel jaeggli]

On 3/25/19 07:14, Joe Clarke wrote:
> I support the need for being able to reset a DS to its factory default.
> However, I have a question on the current design of the model and the
> "factory-default" DS.
> 
> It seems to me that this is a single DS that might have been intended to
> reset running or startup.  However, what if I have different DSes that
> each have unique factory default data?  If I choose to extend
> factory-default with a new identity of my other DS, how can I indicate
> that the target DS will be reset to _that_ DS?  Does that make sense?
> 
> Or if I do a  on a factory-default DS, how do I know what
> other DSes does this DS pertain?  Perhaps the server will use this to
> reset a given DS, but how would a user know that (other than perhaps
> naming of the factory-default DS)?
> 
> Maybe the module needs a mapping to let the client know what DS will be
> used to reset what other DS?

the germ of the idea is sensible enough. reset a DS to it's factory state.

When it meets reality of course is that there seem to be a bunch of
variants that seem like pretty compelling use cases.

reset the whole device being one of them.

the specification of a factory-default datastore and then

   o  startup configuration datastore

   o  candiate configuration datastore

   o  running configuration datastore

actually sound a bit implementation specific though I recognize that
most network operating systems due tend to follow models that at least
superficially resembled that.

I'm generally sympathetic to the application the draft proposes.

> 
> Joe
> 
> ___
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
> 




signature.asc
Description: OpenPGP digital signature
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] Adoption poll for draft-wu-netmod-factory-default-02

[joel jaeggli]

On 3/25/19 13:34, Kent Watsen wrote:
> This email begins a 2-week adoption poll for:
> 
>     https://tools.ietf.org/html/draft-wu-netmod-factory-default-02
> 
> Please voice your support or objections before April 8.
> 

support.

I would note that it probably needs a security considerations section
that addresses the two points raised in the security considerations
section of the informatively referenced  rfc 5870.

> Kent (and Lou)
> 
> ___
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
> 




signature.asc
Description: OpenPGP digital signature
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] adoption poll for yang-versioning-reqs-02

[Joel Jaeggli]

> On Mar 22, 2019, at 12:07, Lou Berger  wrote:
> 
> Hi,
> 
> Thank you all for the good input on this thread.
> 
> With the understanding that a 00 working group document is a starting point 
> for the working group rather than a document that is ready for last call - we 
> believe there is sufficient support to adopt this document as a starting 
> point for the requirements we wish to address on this topic.
> 
> It is clear that there is still work to be done on this document before we 
> can declare consensus on it and, not surprisingly, that there is more work to 
> be done on the solution.
> 
> Authors, 
> 
> Please resubmit this document as draft-ietf-netmod-yang-revision-reqs-00 with 
> the only change being the name and publication date.  The -01 version should 
> focus on resolving issues raised during adoption.  Of course the document is 
> subject to normal WG input and processing.
> 
> Please note the 'file' name change -this is to indicate that the requirements 
> are not presupposing a specific solution. It is also consistent with how 
> versioning is defined within the document currently.
> 
> Note: we would like to try to continue the list discussion in next week's 
> session and ask the Authors/DT to summarize issues raised during the adoption 
> call and lead a discussion to help resolve these issues.
> 
I think this meeting is great opportunity to decide what steps need to be taken 
to advance the document within the working group.

Martin specifically objects to the presence of of Non-Backward-Compatible 
changes. 

Many modules outside the IETF are already incompatible with roc 7950 yang 1.1 
revision rules. So that cat may be out of the bag at least with respect to the 
real world. the question remains what to do about that?




___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] artwork folding: dual support modes?

[Joel Jaeggli]

Sent from my iPhone

> On Feb 27, 2019, at 08:30, Kent Watsen  wrote:
> 
> I'm hoping to optimize for this common case scenario.
> 
> I do not agree that having having two folding approaches is an issue.   I 
> would like to see this 
> BCP have the broadest appeal possible.

It comes up due to the rigor required to preserve white space. In that sense it 
is very closely related to interpretation of tabs or the requirement to avoid 
them entirely. IMHO we should be rigorous about the preservation of whites 
space in folded artwork so my preference should reflect that. I’m not convinced 
that if one rigorous that the second slash is required.

> 
> Kent // contributor
> 
> 
>> On Feb 27, 2019, at 5:09 AM, Rob Wilton (rwilton)  wrote:
>> 
>> Hi Adrian,
>>  
>> I mostly agree with your last sentence.
>>  
>> I think that if you always preserve whitespace then a single slash is fine.  
>> I.e. the single slash just breaks the line, and I think that this matches 
>> how editors, programming languages, etc normally behave.
>>  
>> What I’m not keen on is using a single slash, and then automatically 
>> stripping leading whitespace on the line following a slash.
>>  
>> If we want to have control of layout and be able to strip extra whitespace 
>> then my argument is that it is better to be explicit, and using two slashes 
>> is one way of achieving this.
>>  
>> Thanks,
>> Rob
>>  
>>  
>>  
>> From: netmod  On Behalf Of Adrian Farrel
>> Sent: 27 February 2019 09:41
>> To: 'Joel Jaeggli' 
>> Cc: netmod@ietf.org
>> Subject: Re: [netmod] artwork folding: dual support modes?
>>  
>> Complete agreement, Joel.
>>  
>> What follows may look better in proportional fonts.
>>  
>> With a single slash we can wrap as follows
>>  
>> 12345679012345
>>  
>> Goes to…
>>  
>> 1234567\
>> 9012345
>>  
>> …and unwrapping is easy.
>>  
>> However, if I want to manually wrap the line with indentation
>>  
>> The quick brown fox jumps over the lazy dog
>>  
>> ..going to…
>>  
>> The quick brown fox\
>>   jumps over the lazy dog
>>  
>> …I am going to unfold as…
>>  
>> The quick brown fox  jumps over the lazy dog
>>  
>>  
>> Conversely, if I resolve this second case by stripping leading spaces I get…
>>  
>> The quick brown foxjumps over the lazy dog
>>  
>> So I have to fold as…
>>  
>> The quick brown fox \
>>   jumps over the lazy dog
>>  
>> But this causes the first case to unfold as
>>  
>> 12345679012345
>>  
>> …i.e., with missing spaces.
>>  
>> This is what caused the use of the second slash so…
>>  
>> 1234567\
>> \9012345
>>  
>> …and…
>>  
>> The quick brown fox\
>>  \ jumps over the lazy dog
>>  
>>  
>> So, my point is, if and only if we do not care about these “spaces on the 
>> fold” cases, we can operate with a single slash.
>>  
>> Cheers,
>> Adrian
>>  
>> From: Joel Jaeggli  
>> Sent: 27 February 2019 06:31
>> To: Adrian Farrel 
>> Cc: Kent Watsen ; netmod@ietf.org
>> Subject: Re: [netmod] artwork folding: dual support modes?
>>  
>>  
>>  
>> 
>> On Feb 26, 2019, at 14:26, Adrian Farrel  wrote:
>>  
>> Hey.
>>  
>> I’ve been having this discussion with Kent off-line, but thought it should 
>> come to the list.
>>  
>> I don’t think it is a good idea to have two approaches. While it would be 
>> relatively easy to code for both approaches, it seems to add a degree of 
>> confusion if both have to be handled by the same code (consider deciding 
>> whether leading space characters are to be retained or not, something that 
>> can only be decided when the first non-space character is found), or by 
>> having different code for the two different cases.
>>  
>> It doesn’t seem to me that both cases are needed. We can pick one or the 
>> other.
>>  
>> A single slash has been used to wrap long lines in editors and shells for 
>> decades at this point.
>>  
>> and yeah whatever it is one method seems better than two.
>>  
>> 
>>  
>> And *if* we want to allow manual folding so that indents can be made to make 
>> the document more human-readable then we have to use a leading ‘\’ on 
>> continuation lines to show which spaces should be stripped and which 
>> retained.
>>  
>> Cheers,

Re: [netmod] artwork folding: dual support modes?

[Joel Jaeggli]

> On Feb 26, 2019, at 14:26, Adrian Farrel  wrote:
> 
> Hey.
>  
> I’ve been having this discussion with Kent off-line, but thought it should 
> come to the list.
>  
> I don’t think it is a good idea to have two approaches. While it would be 
> relatively easy to code for both approaches, it seems to add a degree of 
> confusion if both have to be handled by the same code (consider deciding 
> whether leading space characters are to be retained or not, something that 
> can only be decided when the first non-space character is found), or by 
> having different code for the two different cases.
>  
> It doesn’t seem to me that both cases are needed. We can pick one or the 
> other.

A single slash has been used to wrap long lines in editors and shells for 
decades at this point.

and yeah whatever it is one method seems better than two.

>  
> And *if* we want to allow manual folding so that indents can be made to make 
> the document more human-readable then we have to use a leading ‘\’ on 
> continuation lines to show which spaces should be stripped and which retained.
>  
> Cheers,
> Adrian
>  
> From: netmod  On Behalf Of Kent Watsen
> Sent: 25 February 2019 22:22
> To: netmod@ietf.org
> Subject: [netmod] artwork folding: dual support modes?
>  
>  
> I had a chat with the tools team recently and, in the course of things, it 
> was implied
> that the double backslash approach we have now was both surprising and 
> non-intuitive. 
>  
> This got me thinking that we may have thrown the proverbial baby out with the 
> bathwater.
> That is, currently we have a header that reads:
>  
>   NOTE: '\\' line wrapping per BCP XX (RFC )
>  
> So why not *also* support a header that reads (note the singe slash):
>  
>   NOTE: '\' line wrapping per BCP XX (RFC )
>  
> Whereby this second form only supports the folded line continuing on column 1 
> (no indents).
>  
> Thoughts?
>  
> Kent // contributor
>  
>  
> ___
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

[netmod] Publication has been requested for draft-ietf-netmod-module-tags-04

[Joel Jaeggli]

Joel Jaeggli has requested publication of draft-ietf-netmod-module-tags-04 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-module-tags/

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] Confirming draft-ietf-netmod-module-tags-03 consensus call

[joel jaeggli]

This confirms the completion of this period.

I think we can conclude the following:

The Question of whether better guidance for usage can be applied was raised and 
discussed. Robert Wilton proposed some text which seems both reasonable and 
which does not change the substance of the draft.

The Question of where tags reside was raised, it appears resolved.

From the meeting, there remains the request for the addition of an example.

Kent - can we add an example

Chris - what format would you like it in.

Kent: xml/netconf or json/restconf is fine, just identify which is used.

On this basis I think we can do a writeup and forward a draft 04 to the IESG 
for review / IETF last call.

Thanks 
Joel 

> On Nov 12, 2018, at 08:46, joel jaeggli  wrote:
> 
> During the Thursday nov 8 session of netmod, we asked if there were any 
> objections to the publication of the Draft-03 version of 
> draft-ietf-netmod-module-tags which addresses comments and concerns raised 
> during the WGLC. In the meeting there were none. This commences a comment 
> period to confirm that call. As this follows closely on the heels of the IETF 
> 103 meeting we’ll let the call run through Monday the 26th of November. 
> 
> https://tools.ietf.org/rfcdiff?url2=draft-ietf-netmod-module-tags-03.txt
> 
> 
> Thanks
> Joel
> ___
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
> 

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] Confirming draft-ietf-netmod-module-tags-03 consensus call

[joel jaeggli]

Something like the text below addresses the question of guidance. I think we 
get a better draft if we close off this discussion on the list.

I think the question about where the tags reside generally is settled.

Thanks
joel

> On Nov 14, 2018, at 09:26, Robert Wilton  wrote:
> 
> 
>> 
>> The answer is:
>> 
>> 1) B/c there's literally no where else they could be stored (no way for a 
>> vendor to add tags)
>> 2) There are other examples of servers storing things they don't use like 
>> comments, so "server not using what it stores" isn't a reason to not store 
>> them on the server in the first place.
>> 
>> Regarding the rest. Maybe we should write a requirements draft and a use 
>> cases draft for the use of meta-data/tags for organizing things.
> That is not what I was suggesting.
> 
> I was suggesting text something like this:
> 
> Introduction:
> 
> OLD:
> 
>   The use of tags for classification and organization is fairly
>ubiquitous not only within IETF protocols, but in the internet itself
>(e.g., #hashtags).  Tags can be usefully standardized, but they can
>also serve as a non-standardized mechanism available for users to
>define themselves.  Our solution provides for both cases allowing for
>the most flexibility.  In particular, tags may be standardized as
>well as assigned during module definition; assigned by
>implementations; or dynamically defined and set by users.
> 
> NEW:
> 
>   The use of tags for classification and organization is fairly
>ubiquitous not only within IETF protocols, but in the internet itself
>(e.g., #hashtags).  One benefit of using tags for organization
>over a rigid structure is that it is more flexible and can more easily
>adapt over time as technologies evolve.  Tags can be usefully
>standardized, but they can also serve as a non-standardized mechanism
>available for users to define themselves. This document provides a
>mechanism to define tags and associate them with YANG modules in a
>flexible manner.  In particular, tags may be standardized as
>well as assigned during module definition; assigned by
>implementations; or dynamically defined and set by users.
> 
> 
> NEW:
>
> 1.1 Some example use cases of YANG module tags
> 
>   Tags can be used to help filter different discrete categories of YANG
>   modules supported by a device.  E.g., if modules are suitably tagged,
>   then an XPath query can be used to list all of the vendor modules
>   supported by a device.
> 
>   Tags can also be used to help coordination when multiple
>   semi-independent clients are interacting with the same devices.  E.g.,
>   one management client could mark that some modules should not be used
>   because they have not been verified to behave correctly, so that other
>   management clients avoid querying the data associated with those
>   modules.
> 
>   Tag classification is useful for users searching module repositories
>   (e.g. YANG catalog).  A query restricted to the 'ietf:routing' module
>   tag could be used to return only the IETF YANG modules associated with
>   routing.  Without tags, a user would need to know the name of all
>   the IETF routing protocol YANG modules.
> 
>   Future management protocol extensions could allow for filtering
>   queries of configuration or operational state on a server based on
>   tags.  E.g., return all operational state related to system-management.
> 
> 
> If you think that this text is helpful, and it allowed, then please add it, 
> refining as required.  If you think that it detracts from the clarify of 
> document, and is superfluous then leave it out, that is also fine with me ... 
> 
> Thanks,
> Rob
> 
> 



___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] Confirming draft-ietf-netmod-module-tags-03 consensus call

[joel jaeggli]

> 
> 
>>  I do not think the tail end of a WGLC is an appropriate time or place to 
>> start wondering out loud about whether it would be a good to have. I admit 
>> to being confused by this since I believe you were actively participating 
>> WRT this work when it had the yang library augmentation as well as after we 
>> removed it.
> 
> My apologies, but I had intended to review this more thoroughly during the WG 
> LC but ran out of time.  If was when I read Alex's comments that I thought 
> that he was raising some valid points. The key one that struck a chord is 
> that this document describes a solution but doesn't seem to clearly describe 
> what problem it is solving (other than tags are good), or how it is intending 
> to be used.  When I reviewed this document after reading Alex's comments, I 
> was asking myself how this was going to be used, and the answer I came up 
> with was that I didn't really know.  Or the case that I had in mind (YANG 
> catalog filtering on module tag) doesn't seem to match the authors envisaged 
> use cases.  Looking back at some of the previous comments on this work (not 
> just Alex), others have also questioned what problem it is solving and how it 
> will be used.
> 

So the backup slides I had for the talk basically asked if more proscriptive 
text was required on their use. Which is a bit different then working how they 
are to be used. 

The three cases of module tags, IETF, Vendor and User come from different 
sources. The IETF source comes with a demand for IETF consensus. The others do 
not. 

Ultimately I can imagine all sorts of user classification schemes that might 
emerge so my general conclusion that that any description should come in the 
form of guidance rather than proscription.


___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] Confirming draft-ietf-netmod-module-tags-03 consensus call

[joel jaeggli]

> On Nov 12, 2018, at 15:36, Alex Campbell  wrote:
> 
> Perhaps my opinion also carries less weight, as someone who's only on the 
> mailing list and didn't actually attend the IETF meeting.
> 


So, the reason we take the discussion back to the list is precisely to insure 
that we capture the opinions of those not present in the working group meeting. 
I think that is a point to be addressed separately from the question of whether 
the document is ready to go or not.

Thanks
Joel

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

[netmod] Confirming draft-ietf-netmod-module-tags-03 consensus call

[joel jaeggli]

During the Thursday nov 8 session of netmod, we asked if there were any 
objections to the publication of the Draft-03 version of 
draft-ietf-netmod-module-tags which addresses comments and concerns raised 
during the WGLC. In the meeting there were none. This commences a comment 
period to confirm that call. As this follows closely on the heels of the IETF 
103 meeting we’ll let the call run through Monday the 26th of November. 

https://tools.ietf.org/rfcdiff?url2=draft-ietf-netmod-module-tags-03.txt


Thanks
Joel
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] Eric Rescorla's No Objection on draft-ietf-netmod-schema-mount-12: (with COMMENT)

[joel jaeggli]

Thanks all

Glad that was acceptable.

Joel 


> On Nov 8, 2018, at 11:27, Eric Rescorla  wrote:
> 
> Eric Rescorla has entered the following ballot position for
> draft-ietf-netmod-schema-mount-12: No Objection
> 
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
> 
> 
> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
> 
> 
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-netmod-schema-mount/
> 
> 
> 
> --
> COMMENT:
> --
> 
> Thank you for addressing my DISCUSS
> 
> 

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] for a future rfc6991bis

[Joel Jaeggli]

> On Oct 30, 2018, at 03:14, Juergen Schoenwaelder 
>  wrote:
> 
> On Tue, Oct 30, 2018 at 12:05:17AM +, Kent Watsen wrote:
>> 
>> 
 In addition, it might be good to introduce [inet?] types for RFC 5322 
 (Internet Message Format) including perhaps:
 
  - email-address(addr-spec, per Section 3.4.1)
  - named-email-address  (name-addr, per Section 3.4)
 
>>> 
>>> Where are these used? Or have these already been used somewhere?
>> 
>> I'm unaware of these ever having been used before.  I am working on a 
>> private module for which I want to configure an email address.  After some 
>> searching, I concluded that no such types have been defined, and thus 
>> thought that they might be good candidates for addition.
>> 
> 
> It would be good to have strong use cases. I fear that defining this
> type won't be easy given that we also have internationalized email
> addresses (RFC 6530 provides an overview) and we might have to create
> a union of RFC 5322 addresses and "SMTPUTF8 (compliant) addresses”.

It would be slightly unfortunate I think if we were to define something that 
was obsolete at the time of definition. So yeah the union of all-ascii 
addresses and non-ascii addresses is in fact SMTPUTF8. To my mind that would be 
what you would specify, and that probably requires discussion.
> 
> /js
> 
> -- 
> Juergen Schoenwaelder   Jacobs University Bremen gGmbH
> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
> Fax:   +49 421 200 3103 
> 
> ___
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
> 

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] WG LC draft-ietf-netmod-module-tags-02 - 10/2/18 - 10/16/18

[Joel Jaeggli]

> On Oct 25, 2018, at 06:12, Christian Hopps  wrote:
> 
> Hi Joel, WG,
> 
> I published a new draft some days ago covering the specific concerns and 
> editorial changes requested during WGLC. This included the addition of an 
> extension statement which covered machine parsing of pre-defined tags which 
> was mentioned by multiple people, and is the only significant change made. I 
> would think we'd have rough consensus (at least) at this point.

Yes, I don’t think we need to belabor the edits since I think that discussion 
tailed of to a reasonable conclusion.

> 
> I do not agree that we should restrict the usefulness of this work by 
> removing the ability of the module author or the vendor/implementer to add 
> tags due to a single persons view of how they might use the technology. 
> There's nothing gained, and there's obvious loss of functionality.

I’m trying not to inject my own opinion into prejudging an outcome here. 

I do see it as significant point of contention in the working group last call. 
If I were asking for consensus on the point specifically I do not believe that 
we have arrived at a point of rough consensus yet.

> Thanks,

Thanks for getting us to this point.

Joel

> Chris.
> 
>> On Oct 25, 2018, at 3:05 AM, Joel Jaeggli  wrote:
>> 
>> This WG LC closed on the 16th. 
>> 
>> Working group last calls serve a useful forcing function even for drafts 
>> that may end up looking unready as a result due to the attention. If I am 
>> making a judgement call here based on the feedback received during this 
>> period and the prior one.
>> 
>> I will try and summarize the major concerns that  see expressed with this 
>> draft.
>> 
>> Jurgen had a significant list of comments and edits
>> 
>> https://mailarchive.ietf.org/arch/msg/netmod/qUGyGIxHJKsEXZsG6r3P7R0nirg
>> 
>> Followed up by Christian
>> 
>> One detail teased out there and in other comments bears revisting
>> 
>>Juergen
>>> I do not like this. YANG has extension statements and having to
>>> parse stuff out of free text description statements seems to be a
>>> movement backwards.
>> 
>> Christian
>> This is used by the human implementer of the module (i.e., they need to 
>> write code to implement the module). As such it was not intended for machine 
>> parsing.
>> 
>> Juergon
>> I am personally not convinced. The whole reason why we have YANG is
>> automation and I believe people will go and write tools to extract
>> tags and having to extract them out of free form text looks like a
>> step backwards.
>> 
>> Andy 
>> 
>> It is more than a step backwards.
>> There is an unexplained procedure for declaring the  module-tag conformance,
>> in addition to the module-tag mappings.
>> 
>> Alex
>> 
>> I have no issue with systems using tags to classify or organize modules, 
>> however this seems to me like something that would be specific to the system 
>> doing the classifying. It would not be something that needs to be specified 
>> in the module itself (except perhaps as freeform description text), and it 
>> certainly would not need to involve the NETCONF server. What would a server 
>> do with module classification data? (unless it is also implementing some 
>> kind of module browsing interface, in which case it might be used to supply 
>> the browser with data)
>> 
>> Wether or not this is intended for or will be parsed by machines remains a 
>> significant unresolved concern. The actual mechanics of restricting what 
>> goes into them however seems fairly straight forward.
>> 
>> Absent consensus on the above concern this document cannot probably advance, 
>> we do have the opportunity for significant face to face discussion in the 
>> near future so using that to arrive at a conclusion would probably allow 
>> this work to progress or stop.
>> 
>> Thanks
>> Joel
>> 
>>> On Oct 2, 2018, at 13:21, joel jaeggli  wrote:
>>> 
>>> This is start of a two week working group last-call for
>>> draft-ietf-netmod-module-tags-02 a current netmod working group
>>> document.
>>> 
>>> You may review at:
>>> https://tools.ietf.org/html/draft-ietf-netmod-module-tags-02
>>> 
>>> Please send email to the list indicating "yes/support" or "no/do not
>>> support".  If indicating no, please state your reservations with the
>>> document.  If yes, please also feel free to provide comments you'd like
>>> to see addressed once the document is a WG document.
>&

Re: [netmod] WG adoption poll draft-kwatsen-netmod-artwork-folding-08

[Joel Jaeggli]

Suupport

   Scan the artwork for horizontal tab characters.  If any horizontal
   tab characters appear, either resolve them to space characters or
   exit, forcing the input provider to convert them to space characters
   themselves first.

Support this only more strongly, e.g.  the general prohibition against tabs is 
fine. it is hard if not impossible to get 4 implementers in a room  to agree  
how many spaces a tab should be.

> On Oct 18, 2018, at 06:03, Lou Berger  wrote:
> 
> All,
> 
> This is start of a two week poll on making
> draft-kwatsen-netmod-artwork-folding-08 a working group
> document. Please send email to the list indicating "yes/support" or
> "no/do not support".  If indicating no, please state your reservations
> with the document.  If yes, please also feel free to provide comments
> you'd like to see addressed once the document is a WG document.
> 
> The poll ends Oct 1.
> 
> Thanks,
> 
> Lou (and co-chairs)
> 
> ___
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
> 

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] Eric Rescorla's Discuss on draft-ietf-netmod-schema-mount-11: (with DISCUSS)

[joel jaeggli]

On 10/16/18 14:51, Eric Rescorla wrote:
> OK, after reading your explanation and the example, I think I am clearer
> on the use case and the text you propose seems appropriate. Why don't
> you provide a new ID and I'll clear my DISCUSS

Thanks I think the authors will have that out shortly.

joel

> -Ekr
> 
> 
> On Tue, Oct 16, 2018 at 9:05 AM joel jaeggli  <mailto:joe...@gmail.com>> wrote:
> 
> On 10/16/18 06:00, Eric Rescorla wrote:
> > I'm sorry, but I still don't think I understand the security
> impacts of
> > this well enough to know if this text is OK.
> >
> > Can you provide a more detailed explanation of what XPath expressions
> > can and cannot do here? Happy to discuss live either on the phone
> or in BKK
> I'm probably grossly simplifying the goal here, but.
> 
> xpath statement allow for referencing another path or applying
> constraints e.g. when / must (rfc 6020)
> 
> the canonical example in 6020 being something like
> 
>   container interface {
>       leaf ifType {
>           type enumeration {
>               enum ethernet;
>               enum atm;
>           }
>       }
>       leaf ifMTU {
>           type uint32;
>       }
>       must "ifType != 'ethernet' or " +
>            "(ifType = 'ethernet' and ifMTU = 1500)" {
>           error-message "An ethernet MTU must be 1500";
>       }
>       must "ifType != 'atm' or " +
>            "(ifType = 'atm' and ifMTU <= 17966 and ifMTU >= 64)" {
>           error-message "An atm MTU must be  64 .. 17966";
>       }
> 
> 
> http://www.yang-central.org/twiki/pub/Main/YangDocuments/rfc6020.html#xpath
> 
> Imposing constraints using nodes in mounted modules is kind of a key
> application of schema-mount.
> 
> > -Ekr
> >
> >
> > On Tue, Oct 16, 2018 at 5:45 AM Martin Bjorklund  <mailto:m...@tail-f.com>
> > <mailto:m...@tail-f.com <mailto:m...@tail-f.com>>> wrote:
> >
> >     Hi,
> >
> >     Eric Rescorla mailto:e...@rtfm.com>
> <mailto:e...@rtfm.com <mailto:e...@rtfm.com>>> wrote:
> >     > That seems like it's going to have some pretty surprising
> >     consequences and
> >     > at minimum needs more information in the Security
> Considerations.
> >
> >     Ok.  Howabout we add a paragraph to the end of the Security
> >     Considerations section:
> >
> >       Care must be taken when the "parent-reference" XPath
> expressions are
> >       constructed, since the result of the evaluation of these
> expressions
> >       is added to the accessible tree for any XPath expression
> found in
> >       the mounted schema.
> >
> >
> >     /martin
> >
> >     > On Thu, Oct 11, 2018 at 12:18 AM Martin Bjorklund
> mailto:m...@tail-f.com>
> >     <mailto:m...@tail-f.com <mailto:m...@tail-f.com>>> wrote:
> >     >
> >     > > Eric Rescorla mailto:e...@rtfm.com>
> <mailto:e...@rtfm.com <mailto:e...@rtfm.com>>> wrote:
> >     > > > I'm sorry but I don't understand this.
> >     > > >
> >     > > > Does the externally visible behavior of any mounted module
> >     depend in any
> >     > > > way on these XPATH references
> >     > >
> >     > > Yes, but note that these XPath expressions
> ("parent-reference") are
> >     > > read-only (config false in the YANG model).  Thus they are set
> >     by the
> >     > > implementation, and used to inform the operator about the
> >     environment
> >     > > in which other XPath expressions are evaluated.
> >     > >
> >     > >
> >     > > /martin
> >     > >
> >     > >
> >     > > >
> >     > > > -Ekr
> >     > > >
> >     > > >
> >     > > >
> >     > > >
> >     > > > On Wed, Oct 10, 2018 at 6:38 AM Martin Bjorklund
> >     mailto:m...@tail-f.com> <mailto:m...@tail-f.com
> <mailto:m...@tail-f.com>>> wrote:
> >     > > >
> >     > > > 

Re: [netmod] Eric Rescorla's Discuss on draft-ietf-netmod-schema-mount-11: (with DISCUSS)

[joel jaeggli]

On 10/16/18 06:00, Eric Rescorla wrote:
> I'm sorry, but I still don't think I understand the security impacts of
> this well enough to know if this text is OK.
> 
> Can you provide a more detailed explanation of what XPath expressions
> can and cannot do here? Happy to discuss live either on the phone or in BKK
I'm probably grossly simplifying the goal here, but.

xpath statement allow for referencing another path or applying
constraints e.g. when / must (rfc 6020)

the canonical example in 6020 being something like

  container interface {
  leaf ifType {
  type enumeration {
  enum ethernet;
  enum atm;
  }
  }
  leaf ifMTU {
  type uint32;
  }
  must "ifType != 'ethernet' or " +
   "(ifType = 'ethernet' and ifMTU = 1500)" {
  error-message "An ethernet MTU must be 1500";
  }
  must "ifType != 'atm' or " +
   "(ifType = 'atm' and ifMTU <= 17966 and ifMTU >= 64)" {
  error-message "An atm MTU must be  64 .. 17966";
  }

http://www.yang-central.org/twiki/pub/Main/YangDocuments/rfc6020.html#xpath

Imposing constraints using nodes in mounted modules is kind of a key
application of schema-mount.

> -Ekr
> 
> 
> On Tue, Oct 16, 2018 at 5:45 AM Martin Bjorklund  > wrote:
> 
> Hi,
> 
> Eric Rescorla mailto:e...@rtfm.com>> wrote:
> > That seems like it's going to have some pretty surprising
> consequences and
> > at minimum needs more information in the Security Considerations.
> 
> Ok.  Howabout we add a paragraph to the end of the Security
> Considerations section:
> 
>   Care must be taken when the "parent-reference" XPath expressions are
>   constructed, since the result of the evaluation of these expressions
>   is added to the accessible tree for any XPath expression found in
>   the mounted schema.
> 
> 
> /martin
> 
> > On Thu, Oct 11, 2018 at 12:18 AM Martin Bjorklund  > wrote:
> >
> > > Eric Rescorla mailto:e...@rtfm.com>> wrote:
> > > > I'm sorry but I don't understand this.
> > > >
> > > > Does the externally visible behavior of any mounted module
> depend in any
> > > > way on these XPATH references
> > >
> > > Yes, but note that these XPath expressions ("parent-reference") are
> > > read-only (config false in the YANG model).  Thus they are set
> by the
> > > implementation, and used to inform the operator about the
> environment
> > > in which other XPath expressions are evaluated.
> > >
> > >
> > > /martin
> > >
> > >
> > > >
> > > > -Ekr
> > > >
> > > >
> > > >
> > > >
> > > > On Wed, Oct 10, 2018 at 6:38 AM Martin Bjorklund
> mailto:m...@tail-f.com>> wrote:
> > > >
> > > > > Eric Rescorla mailto:e...@rtfm.com>> wrote:
> > > > > > On Wed, Oct 10, 2018 at 5:32 AM Martin Bjorklund
> mailto:m...@tail-f.com>>
> > > wrote:
> > > > > >
> > > > > > > Hi,
> > > > > > >
> > > > > > > Eric Rescorla mailto:e...@rtfm.com>> wrote:
> > > > > > > > Eric Rescorla has entered the following ballot
> position for
> > > > > > > > draft-ietf-netmod-schema-mount-11: Discuss
> > > > > > > >
> > > > > > > > When responding, please keep the subject line intact
> and reply
> > > to all
> > > > > > > > email addresses included in the To and CC lines. (Feel
> free to
> > > cut
> > > > > this
> > > > > > > > introductory paragraph, however.)
> > > > > > > >
> > > > > > > >
> > > > > > > > Please refer to
> > > > > > > https://www.ietf.org/iesg/statement/discuss-criteria.html
> > > > > > > > for more information about IESG DISCUSS and COMMENT
> positions.
> > > > > > > >
> > > > > > > >
> > > > > > > > The document, along with other ballot positions, can
> be found
> > > here:
> > > > > > > >
> https://datatracker.ietf.org/doc/draft-ietf-netmod-schema-mount/
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > >
> --
> > > > > > > > DISCUSS:
> > > > > > > >
> > > > >
> --
> > > > > > > >
> > > > > > > > Rich version of this review at:
> > > > > > > > https://mozphab-ietf.devsvcdev.mozaws.net/D3506
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > DETAIL
> > > > > > > > S 4.
> > > > > > > > >
> > > > > > > > >      It is worth emphasizing that the nodes specified in
> > > > > > > > >      "parent-reference" leaf-list are available in
> the mounted
> > > > > schema
> > > > > > > only
> > > > > > > > >      for XPath evaluations.  In particular, they
> cannot be
> > > accessed
> > > > > > > there
>   

[netmod] WG LC draft-ietf-netmod-module-tags-02 - 10/2/18 - 10/16/18

[joel jaeggli]

This is start of a two week working group last-call for
draft-ietf-netmod-module-tags-02 a current netmod working group
document.

You may review at:
https://tools.ietf.org/html/draft-ietf-netmod-module-tags-02

Please send email to the list indicating "yes/support" or "no/do not
support".  If indicating no, please state your reservations with the
document.  If yes, please also feel free to provide comments you'd like
to see addressed once the document is a WG document.

The prior discussion of my mistaken WG adoption call is here

commences here:

https://www.ietf.org/mail-archive/web/netmod/current/msg21290.html

In particular Andy's concerns expressed in that thread here:

https://www.ietf.org/mail-archive/web/netmod/current/msg21348.html

are probably important to tease out in considering this for last call.

so that we are clear on dates. This last call timing resets and runs
from 10/2/18 - 10/16/18

Joel



signature.asc
Description: OpenPGP digital signature
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

[netmod] Mulligan - Re: WG adoption poll draft-ietf-netmod-module-tags-02

[joel jaeggli]

Folks,

This call is a mistake on my part.

I meant to start a two week last call and sent this message instead.

There are important issues that have been teased out in this thread and
we ned to address them but we should be doing that in guise of a working
group last call.

Joel

On 9/26/18 07:40, joel jaeggli wrote:
> This is start of a two week poll on making
> draft-ietf-netmod-module-tags-02 a NetMod working group
> document.
> 
> You may review at:
> https://tools.ietf.org/html/draft-ietf-netmod-module-tags-02
> 
> Please send email to the list indicating "yes/support" or "no/do not
> support".  If indicating no, please state your reservations with the
> document.  If yes, please also feel free to provide comments you'd like
> to see addressed once the document is a WG document.
> 
> 
> 
> ___
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
> 




signature.asc
Description: OpenPGP digital signature
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] WG adoption poll draft-ietf-netmod-module-tags-02

[joel jaeggli]

On 9/26/18 09:23, Andy Bierman wrote:
> 
> 
> On Wed, Sep 26, 2018 at 9:09 AM Juergen Schoenwaelder
>  > wrote:

> 
> It is even worse than a step backwards.
> The draft specifies a lot of details about module tag conformance
> that needs to be present in the description-stmt.

this seems like an important issue to square away  before we  move ahead.

> The idea that tools must screen-scrape description statements goes against
> everything YANG-based management is all about. YANG has extension
> statements, so we don't need to put complex syntax into comments and
> descriptions..

and parse descriptions for meaning.

> IMO all text about module tag conformance and defining tags in
> description-stmts
> should be removed.  There is no explanation why a standard YANG module
> would define multiple module-tags for the same module in the first place,
> let alone why each different tag would have different conformance
> requirements.
> 
>  
> 
> .
> 
> /js
> 
> 
> Andy
>  
> 
> 
> -- 
> Juergen Schoenwaelder           Jacobs University Bremen gGmbH
> Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
> Fax:   +49 421 200 3103         
> 
> 
> 
> ___
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
> 




signature.asc
Description: OpenPGP digital signature
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

[netmod] Important milestones for IETF 103

[joel jaeggli]

Folks,

Important upcoming milestones for the IETF 103 Bankok meeting include:

2018-10-05  - Agenda published, and we will know when we are meeting.

2018-10-22  - Draft submission deadline, 2 weeks out from meeting.

2018-10-24 - Working group agendas due.

2018-11-03 - Meeting commences

Working backwards from that discussion of new submitted drafts aimed at
or before the deadline should really be underway by the time we have to
submit an agenda.

Thanks
Joel



signature.asc
Description: OpenPGP digital signature
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

[netmod] IPR call draft-ietf-netmod-module-tags-02

[joel jaeggli]

Authors, Contributors, WG,

Regarding the document
draft-ietf-netmod-module-tags-02
https://tools.ietf.org/html/draft-ietf-netmod-module-tags-02
Are you aware of any IPR that applies to draft identified above?


Please state either:
"No, I'm not aware of any IPR that applies to this draft"
or
"Yes, I'm aware of IPR that applies to this draft"


If yes, has this IPR been disclosed in compliance with IETF IPR rules
(see RFCs 3979, 4879, 3669 and 5378 for more details)? Please state
either:
"Yes, the IPR has been disclosed in compliance with IETF IPR rules"
or
"No, the IPR has not been disclosed"

If no, please provide any additional details you think appropriate.


If you are listed as a document author or contributor, please answer the
above by responding to this email regardless of whether or not you are
aware of any relevant IPR. This document will not advance to the next
stage until a response has been received from each author and listed
contributor. NOTE: THIS APPLIES TO ALL OF YOU LISTED IN THIS MESSAGE'S
TO LINES.


If you are on the WG email list or attend WG meetings but are not listed
as an author or contributor, we remind you of your obligations under the
IETF IPR rules which encourages you to notify the IETF if you are aware
of IPR of others on an IETF contribution, or to refrain from participating
in any contribution or discussion related to your undisclosed IPR. For
more information, please see the RFCs listed above and
http://trac.tools.ietf.org/group/iesg/trac/wiki/IntellectualProperty.


signature.asc
Description: Message signed with OpenPGP
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

[netmod] WG adoption poll draft-ietf-netmod-module-tags-02

[joel jaeggli]

This is start of a two week poll on making
draft-ietf-netmod-module-tags-02 a NetMod working group
document.

You may review at:
https://tools.ietf.org/html/draft-ietf-netmod-module-tags-02

Please send email to the list indicating "yes/support" or "no/do not
support".  If indicating no, please state your reservations with the
document.  If yes, please also feel free to provide comments you'd like
to see addressed once the document is a WG document.



signature.asc
Description: Message signed with OpenPGP
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

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

[Joel Jaeggli]

> On Sep 10, 2018, at 12:51 AM, Robert Wilton 
>  wrote:
> 
> I've read -07, and would also support an WG adoption call for this draft.  In 
> fact, I think that it would be quite good if we can move this document 
> through to WG LC fairly expediently as well.
> 
> A couple of minor review comments:
> 
> Introduction: RFC7994 reference listed twice.
> 
> Rather than banning tabs, another option would to be convert them (of course, 
> the question is then whether a tab is 2, 4, or 8 spaces ...), although 
> assuming 4 spaces seems reasonable, and could be controlled via an input 
> parameter.

This does seem like the sort of classical place to have argument about the size 
of a tab. To me the 7991 position is compelling. The onus is the formatter to 
use an element which is not ambiguous.

It’s not really anyones business that I have

set tabstop=2 shiftwidth=2 expandtab
In my vimrc nor should it be.

> Thanks,
> Rob
> 
> 
> On 08/09/2018 13:39, Adrian Farrel wrote:
>> Speaking as a co-author, I agree with Kent that this version is ready for 
>> the WG
>> to pick up.
>> 
>> I think that discussions at f2f meetings indicated that there was interest in
>> the WG in addressing this issue, and after much back and forth, the authors 
>> have
>> come together with an approach that they agree on and it incorporates some
>> suggestions made in Montreal.
>> 
>> Thanks,
>> Adrian
>> 
>>> -Original Message-
>>> From: netmod [mailto:netmod-boun...@ietf.org] On Behalf Of Kent Watsen
>>> Sent: 07 September 2018 22:59
>>> To: netmod@ietf.org
>>> Subject: [netmod] FW: New Version Notification for draft-kwatsen-netmod-
>>> artwork-folding-07.txt
>>> 
>>> 
>>> An update to the "artwork-folding" draft has been posted.
>>>   - the solution is now using the "/.../" format.
>>>   - the included script has been updated as well.
>>> 
>>> We believe that this draft is ready for an adoption poll.
>>> 
>>> Kent (and Adrian and Qin)  // authors
>>> 
>>> 
>>> -Original 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 and
>> RFCs
>>> Document date:  2018-09-05
>>> Group:  Individual Submission
>>> Pages:  16
>>> URL:
>>> https://www.ietf.org/id/draft-kwatsen-netmod-artwork-folding-
>>> 07.txt
>>> Status: 
>>> https://datatracker.ietf.org/doc/draft-kwatsen-netmod-artwork-
>>> folding/
>>> Htmlized:
>> https://tools.ietf.org/html/draft-kwatsen-netmod-artwork-folding-
>>> 07
>>> Htmlized:   https://datatracker.ietf.org/doc/html/draft-kwatsen-netmod-
>>> artwork-folding
>>> Diff:
>> https://www.ietf.org/rfcdiff?url2=draft-kwatsen-netmod-artwork-
>>> folding-07
>>> 
>>> Abstract:
>>>This document introduces a simple and yet time-proven strategy for
>>>handling long lines in artwork in drafts using a backslash ('\')
>>>character where line-folding has occurred.  The strategy works on any
>>>text based artwork, but is primarily intended for sample text and
>>>formatted examples and code, rather than for graphical artwork.  The
>>>approach produces consistent results regardless of the content and
>>>uses a per-artwork header.  The strategy is both self-documenting and
>>>enables automated reconstitution of the original artwork.
>>> 
>>> 
>>> 
>>> 
>>> Please note that it may take a couple of minutes from the time of submission
>>> until the htmlized version and diff are available at tools.ietf.org.
>>> 
>>> The IETF Secretariat
>>> 
>>> 
>>> 
>>> ___
>>> netmod mailing list
>>> netmod@ietf.org
>>> https://www.ietf.org/mailman/listinfo/netmod
>> ___
>> netmod mailing list
>> netmod@ietf.org
>> https://www.ietf.org/mailman/listinfo/netmod
>> .
>> 
> 
> ___
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
> 



signature.asc
Description: Message signed with OpenPGP
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

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

[joel jaeggli]

I support this.

thanks

joel


On 6/22/18 6:37 PM, Qin Wu wrote:
> Dear WG,
>
> As you may recall I presented yang-xml-doc-conventions in London.  There was 
> strong support for trying to solve the problem and mixed views on the 
> solution, other than that we should do it fast.  In the meanwhile, Kent 
> submitted artwork-folding as an alternative solution.
>
> The authors of the two drafts decided to combine efforts.  After several 
> internal iterations on both drafts, the drafts were becoming more alike than 
> different(both support auto wrapping or auto folding).  The artwork-folding 
> draft was selected as a preferred offering basis (i.e., 
> draft-kwatsen-netmod-artwork-folding-04) to the working group to consider for 
> adoption.
>
> The primary feature differences remained are:
>   - all folded lines continue of column 0 without two character indentation, 
> i.e., whether auto indentation should be supported.
>   - handle two special case on backslash and space at the end of broken line 
> in yang-xml-doc-conventions.
>   - propose to use  to extract artwork 
> from I-Ds.
>
> Thanks,
> Qin, Kent, Benoit and Adrian
> -邮件原件-
> 发件人: internet-dra...@ietf.org [mailto:internet-dra...@ietf.org] 
> 发送时间: 2018年6月23日 9:33
> 收件人: Benoit Claise; Qin Wu; Kent Watsen; Adrian Farrel; Benoît Claise
> 主题: New Version Notification for draft-kwatsen-netmod-artwork-folding-04.txt
>
>
> A new version of I-D, draft-kwatsen-netmod-artwork-folding-04.txt
> has been successfully submitted by Qin Wu and posted to the IETF repository.
>
> Name: draft-kwatsen-netmod-artwork-folding
> Revision: 04
> Title:Handling Long Lines in Artwork in Drafts
> Document date:2018-06-22
> Group:Individual Submission
> Pages:9
> URL:
> https://www.ietf.org/internet-drafts/draft-kwatsen-netmod-artwork-folding-04.txt
> Status: 
> https://datatracker.ietf.org/doc/draft-kwatsen-netmod-artwork-folding/
> Htmlized:   
> https://tools.ietf.org/html/draft-kwatsen-netmod-artwork-folding-04
> Htmlized:   
> https://datatracker.ietf.org/doc/html/draft-kwatsen-netmod-artwork-folding
> Diff:   
> https://www.ietf.org/rfcdiff?url2=draft-kwatsen-netmod-artwork-folding-04
>
> Abstract:
>This document introduces a simple and yet time-proven strategy for
>handling long lines in artwork in drafts using a backslash ('\')
>character where line-folding has occurred.  The strategy works on any
>text based artwork, producing consistent results regardless the
>artwork content.  Using a per-artwork header, the strategy is both
>self-documenting and enables automated reconstitution of the original
>artwork.
>
>   
> 
>
>
> Please note that it may take a couple of minutes from the time of submission 
> until the htmlized version and diff are available at tools.ietf.org.
>
> The IETF Secretariat
>
> ___
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
>

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

[netmod] Publication has been requested for draft-ietf-netmod-schema-mount-10

[Joel Jaeggli]

Joel Jaeggli has requested publication of draft-ietf-netmod-schema-mount-10 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-schema-mount/

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

[netmod] Completion: WGLC - draft-ietf-netmod-schema-mount (version 09)

[joel jaeggli]

This working group last call completed Wednesday April 4th.

It looks like there are no outstanding discussion threads going on now,
and the recent discussion has mostly been clarificatory.

Editorial changes proposed as a result of WGLC review look largely
superficial to schema mount itself.

https://github.com/netmod-wg/schema-mount/commit/8ba2b284ec861c9ca65e6f7ee65edba3ab071c36

As this is the second WGLC and is was immediately proceeded by a meeting
to discuss the adjustment of the document between draft 08 (1ST WGLC)
and draft 09 (2nd WGLC). I think we can conclude that there is consensus
to proceed IESG processing and IETF last call.

Thanks to everyone who contributed to this significant effort.

NETMOD WG Chairs


On 3/28/18 7:01 PM, joel jaeggli wrote:
> Greetings,
>
> I hope that we are all recovered from the IETF meeting (or in my case an
> impromptu ski holiday).
>
> Today we entered the second week on the last call for
>
> draft-ietf-netmod-schema-mount
>
> While I don't expect a lot of commentary given that we devoted an entire
> meeting slot to it, currently we have a fresh reading of it from Ariel.
>
> https://www.ietf.org/mail-archive/web/netmod/current/msg20741.html
>
> and some subsequent commentary
>
> This WGLC will conclude Wednesday April 4th.
>
> Thanks
>
> joel
>
>
> On 3/21/18 7:04 AM, joel jaeggli wrote:
>> Greetings,
>>
>> We are running a 2 week WGLC again on draft-ietf-netmod-schema-mount in
>> order to review the proposed changes in draft 09.
>>
>> https://datatracker.ietf.org/doc/draft-ietf-netmod-schema-mount/
>>
>> the 08 - 09 diff is available here:
>>
>> https://www.ietf.org/rfcdiff?url1=draft-ietf-netmod-schema-mount-08=draft-ietf-netmod-schema-mount-09
>>
>> Please send email to the list indicating your support or concerns.
>>
>> We are particularly interested in statements of the form:
>>
>>   * I have reviewed this draft and I prefer it to draft-08
>>   * I have reviewed this draft and found no issues.
>>   * I have reviewed this draft and found the following issues: ...
>>
>> This WGLC will conclude Wednesday April 4th.
>>
>> Statements indicating there is no known IPR have already been made
>> during the previous WGLC. If anyone is aware of new information
>> regarding IPR they should make us aware of that as soon as feasible.
>>
>> Thank you,
>> NETMOD WG Chairs
>>
>>
>>
>>
>>
>>
>
>
>
> ___
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod



signature.asc
Description: OpenPGP digital signature
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

[netmod] Reminder: WGLC - draft-ietf-netmod-schema-mount (version 09)

[joel jaeggli]

Greetings,

I hope that we are all recovered from the IETF meeting (or in my case an
impromptu ski holiday).

Today we entered the second week on the last call for

draft-ietf-netmod-schema-mount

While I don't expect a lot of commentary given that we devoted an entire
meeting slot to it, currently we have a fresh reading of it from Ariel.

https://www.ietf.org/mail-archive/web/netmod/current/msg20741.html

and some subsequent commentary

This WGLC will conclude Wednesday April 4th.

Thanks

joel


On 3/21/18 7:04 AM, joel jaeggli wrote:
> Greetings,
>
> We are running a 2 week WGLC again on draft-ietf-netmod-schema-mount in
> order to review the proposed changes in draft 09.
>
> https://datatracker.ietf.org/doc/draft-ietf-netmod-schema-mount/
>
> the 08 - 09 diff is available here:
>
> https://www.ietf.org/rfcdiff?url1=draft-ietf-netmod-schema-mount-08=draft-ietf-netmod-schema-mount-09
>
> Please send email to the list indicating your support or concerns.
>
> We are particularly interested in statements of the form:
>
>   * I have reviewed this draft and I prefer it to draft-08
>   * I have reviewed this draft and found no issues.
>   * I have reviewed this draft and found the following issues: ...
>
> This WGLC will conclude Wednesday April 4th.
>
> Statements indicating there is no known IPR have already been made
> during the previous WGLC. If anyone is aware of new information
> regarding IPR they should make us aware of that as soon as feasible.
>
> Thank you,
> NETMOD WG Chairs
>
>
>
>
>
>




signature.asc
Description: OpenPGP digital signature
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

[netmod] WGLC - draft-ietf-netmod-schema-mount (version 09)

[joel jaeggli]

Greetings,

We are running a 2 week WGLC again on draft-ietf-netmod-schema-mount in
order to review the proposed changes in draft 09.

https://datatracker.ietf.org/doc/draft-ietf-netmod-schema-mount/

the 08 - 09 diff is available here:

https://www.ietf.org/rfcdiff?url1=draft-ietf-netmod-schema-mount-08=draft-ietf-netmod-schema-mount-09

Please send email to the list indicating your support or concerns.

We are particularly interested in statements of the form:

  * I have reviewed this draft and I prefer it to draft-08
  * I have reviewed this draft and found no issues.
  * I have reviewed this draft and found the following issues: ...

This WGLC will conclude Wednesday April 4th.

Statements indicating there is no known IPR have already been made
during the previous WGLC. If anyone is aware of new information
regarding IPR they should make us aware of that as soon as feasible.

Thank you,
NETMOD WG Chairs








signature.asc
Description: OpenPGP digital signature
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] choice/case in tree diagrams

[joel jaeggli]

On 3/6/18 3:29 AM, Lou Berger wrote:
> Martin,
>
>
> On March 6, 2018 4:44:47 AM Martin Bjorklund  wrote:
>
>> Hi,
>>
>> After thinking some more about this, realizing that this document is
>> in AUTH48, and looking at the first sentence in the Abstract:
>>
>>    This document captures the current syntax used in YANG module tree
>>    diagrams.
>>
>> I have reached the conclusion that we probably shouldn't make any
>> drastic changes.
>>
>
> I agree.
I would tend to err on that side  as well it's a little late for that.
>> The current syntax, with flags for choice but not for case, may look a
>> bit odd, but it does follow RFC 7950 where a choice node can have a
>> config property, but case cannot.  Also, this syntax has now been used
>> for several years w/o causing much confusion.
>>
>> I suggest the following changes to this document:
>>
>> OLD:
>>
>>     is one of:
>>  rw  for configuration data
>>  ro  for non-configuration data, output parameters to rpcs
>>  and actions, and notification parameters
>>  -w  for input parameters to rpcs and actions
>>  -u  for uses of a grouping
>>  -x  for rpcs and actions
>>  -n  for notifications
>>  mp  for nodes containing a "mount-point" extension statement
>>
>> NEW:
>>
>>     is one of:
>>  rw  for configuration data
>>  ro  for non-configuration data, output parameters to rpcs
>>  and actions, and notification parameters
>>  -w  for input parameters to rpcs and actions
>>  -u  for uses of a grouping
>>  -x  for rpcs and actions
>>  -n  for notifications
>>  mp  for nodes containing a "mount-point" extension statement
>>
>>  case nodes do not have any .
>>
>
>
>> Then, since the syntax requires whitespace before :
>>
> I think we should match current tooling/practice here as well. Can you
> confirm how pyang works today?
>
> My memory is no such space is added.  If my memory is correct, my
> preference is to change the text rather then the tooling.
>
> Lou
> (As contributor)
>
>>  --   
>>
>> we need to fix the examples:
>>
>> OLD:
>>
>>  +--rw (root-type)
>>     +--:(vrf-root)
>>
>> NEW:
>>
>>  +--rw (root-type)
>>     +-- :(vrf-root)
>>
>> (two occurances)
>>
>>
>>
>> /martin
>>
>>
>>
>> Vladimir Vassilev  wrote:
>>>
>>>
>>> On 03/05/2018 06:40 PM, Per Hedeland wrote:
>>> > On 2018-03-05 16:06, Ladislav Lhotka wrote:
>>> >> On Mon, 2018-03-05 at 15:49 +0100, Per Hedeland wrote:
>>> >>> On 2018-03-05 15:41, Ladislav Lhotka wrote:
>>>  On Mon, 2018-03-05 at 15:26 +0100, Martin Bjorklund wrote:
>>> > Juergen Schoenwaelder 
>>> wrote:
>>> >> On Mon, Mar 05, 2018 at 02:54:18PM +0100, Martin Bjorklund
>>> wrote:
>>>  So it seems the running code got it right. ;-)
>>> >>> As the author of that code, I think that was purely by
>>> accident...
>>> >>>
>>> >>> But I'm not convinced it is the correct solution.  We have
>>> one example
>>> >>> in the other thread where someone was confused by the "rw"
>>> flag and
>>> >>> thought that it implied that the node would be present in
>>> the data
>>> >>> tree.
>>> >>>
>>> >> So what does rw mean?
>>> >>
>>> >> (i)  The schema node has a rw property.
>>> >> (ii) The schema node can be instantiated and the instantiated
>>> data
>>> >> node
>>> >>   has a rw property.
>>> >>
>>> >> I think it is difficult to have both at the same time. If the
>>> tree is
>>> >> a representation of schema nodes, then (i) seems to make more
>>> >> sense. That said, the explanation in 2.6 is somewhat vague
>>> since it
>>> >> says 'data' and not 'nodes' (like everywhere else):
>>> >>
>>> >> OLD:
>>> >>
>>> >>  is one of:
>>> >>   rw  for configuration data
>>> >>   ro  for non-configuration data, output parameters
>>> to rpcs
>>> >>   and actions, and notification parameters
>>> >>
>>> >> NEW:
>>> >>
>>> >>  is one of:
>>> >>   rw  for configuration data nodes
>>> >>   ro for non-configuration data nodes, output
>>> parameters to
>>> >>   rpcs
>>> >>   and actions, and notification parameters
>>> > I think this is ok.  But that means that we also have to add:
>>> >
>>> > --  for a choice or case node
>>> >
>>> > But in order to be consistent, we should probably have:
>>> >
>>> > --  for a choice, case, input or output node
>>>  But unlike the three other statements, "choice" can have the
>>> config
>>>  substatement, so "rw/ro" makes sense there.
>>> >>> I don't think so - that config statement does not a define a
>>> property
>>> >>> of
>>> >>> the choice node (it can 

[netmod] feedback draft-rtgyangdt-netmod-module-tags -> draft-ietf-netmod-module-tags

[joel jaeggli]

introduction / abstract should capture the problem module tags are
attempting to solve succinctly

Robert Wilton's criticism of the approach is well taken; the use of tags
as regular configuration (his approach) vs the treatment of tags as
exceptions (how we understand them as proposed). and seems like a ket
architectural consideration in advancing this draft.

joel



signature.asc
Description: OpenPGP digital signature
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

[netmod] Adoption Poll Completed: draft-rtgyangdt-netmod-module-tags-02

[joel jaeggli]

This completes the 2 week poll on making
draft-rtgyangdt-netmod-module-tags-02 a working group document.

https://tools.ietf.org/html/draft-rtgyangdt-netmod-module-tags-02

This document was most recently discussed at IETF 100.

Response has been generally favorable and enthusiasic with some interest
in signficant changes. We are adopting the document as a working group item.

The authors should submit an updated draft probably with the title
draft-ietf-netmod-module-tags-02.

thanks
joel




signature.asc
Description: OpenPGP digital signature
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] Correction, date It ends Feb 20th Re: Adoption Poll: draft-rtgyangdt-netmod-module-tags-02

[joel jaeggli]

Note that this poll ends in a couple days.

thanks
joel

On 2/6/18 15:57, joel jaeggli wrote:
> Sorry, Feb 20th is the end date for the adoption call.
> 
> regards
> 
> joel
> 
> 
> On 2/6/18 3:47 PM, joel jaeggli wrote:
>>
>> Hi,
>>
>> This is the start of a *two* week poll on making
>> draft-rtgyangdt-netmod-module-tags-02 a working group document.  
>>
>> https://tools.ietf.org/html/draft-rtgyangdt-netmod-module-tags-02
>>
>> This document was most recently discussed at IETF 100.
>>
>> Please send email to the list indicating "yes/support" or "no/do not
>> support".  If indicating no, please state your reservations with the
>> document.  If yes, please also feel free to provide comments you'd
>> like to see addressed once the document is a WG document.
>>
>> This poll ends on February 8.
>>
>> Thank you!
>>
>> Joel Jaeggli and IETF NETMOD Co-Chairs
>>
>>
>>
>> ___
>> netmod mailing list
>> netmod@ietf.org
>> https://www.ietf.org/mailman/listinfo/netmod
> 




signature.asc
Description: OpenPGP digital signature
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

[netmod] IPR call draft-rtgyangdt-netmod-module-tags-02

[joel jaeggli]

If any authors or participants are aware of IPR covering the proposed
working-group item:

draft-rtgyangdt-netmod-module-tags-02

https://tools.ietf.org/html/draft-rtgyangdt-netmod-module-tags-02

Now would be a good time to declare it.

Thanks

joel


___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

[netmod] Correction, date It ends Feb 20th Re: Adoption Poll: draft-rtgyangdt-netmod-module-tags-02

[joel jaeggli]

Sorry, Feb 20th is the end date for the adoption call.

regards

joel


On 2/6/18 3:47 PM, joel jaeggli wrote:
>
> Hi,
>
> This is the start of a *two* week poll on making
> draft-rtgyangdt-netmod-module-tags-02 a working group document.  
>
> https://tools.ietf.org/html/draft-rtgyangdt-netmod-module-tags-02
>
> This document was most recently discussed at IETF 100.
>
> Please send email to the list indicating "yes/support" or "no/do not
> support".  If indicating no, please state your reservations with the
> document.  If yes, please also feel free to provide comments you'd
> like to see addressed once the document is a WG document.
>
> This poll ends on February 8.
>
> Thank you!
>
> Joel Jaeggli and IETF NETMOD Co-Chairs
>
>
>
> ___
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

[netmod] Adoption Poll: draft-rtgyangdt-netmod-module-tags-02

[joel jaeggli]

Hi,

This is the start of a *two* week poll on making
draft-rtgyangdt-netmod-module-tags-02 a working group document.  

https://tools.ietf.org/html/draft-rtgyangdt-netmod-module-tags-02

This document was most recently discussed at IETF 100.

Please send email to the list indicating "yes/support" or "no/do not
support".  If indicating no, please state your reservations with the
document.  If yes, please also feel free to provide comments you'd like
to see addressed once the document is a WG document.

This poll ends on February 8.

Thank you!

Joel Jaeggli and IETF NETMOD Co-Chairs

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] moving forward with schema mount

[joel jaeggli]

On 1/24/18 8:07 AM, Ladislav Lhotka wrote:
> Hi,
>
> Kent Watsen  writes:
>
>> 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 and rfc7895bis and an alternate representation of inline schema.
>> These have been considered respecting their impact on the last call
>> consensus and it is the position of the chairs that it is best to
>> advance the existing schema-mount document at this time.
> I guess I have no chance but strongly object to this. Is it normal to
> proceed this way without reaching WG consensus and against the will of
> *both* document authors?
Once the document is adopted by the working group it's the working
group's document.

The consensus call was made back here:

https://www.ietf.org/mail-archive/web/netmod/current/msg19433.html

To my mind the discussion that we picked up in the new year highlights
the limitations of the existing draft without it being fatally flawed.
To wit (and this is my opinion), this one is stable and should proceed,
clearing the path for drafts with normative dependencies; we should
proceed with an update in a timely fashion.

IETF Last call serves a useful function in that is exposes the problem
discussed here beyond the working group, particularly to those who
depend on schema mount today. I think we understand in making this
judgement call where the working group participants stand today.

>> Given that there are significant concerns for how the solution
>> proposed in this draft operates with NMDA, we do think it reasonable
>> to add an applicability statement to the draft that covers its
>> operation in NMDA implementations. We do not believe that such a
>> statement substantively alters the draft nor would it impact drafts
>> that normatively reference the current draft.
>>
>> In addition to resolving the remaining open thread [1],
> Hmm, who resolved this thread? Lou proposed some text and nobody
> expressed any agreement with it. In fact, I believe it is nothing more
> than hand-waving.
>
> I must say that the work on this draft was very frustrating for me. Even
> more than on RFC 8022, and this tells you something.
>
> Lada
>
>> we also agree
>> with the recently made comment that the schema mount draft should
>> allow the use of rfc7895bis (i.e., not reference /modules-state),
>> thereby enabling the draft's use (though not ideal) on servers
>> supporting rfc7895bis.
>>
>> The chairs will propose specific text for the updates mentioned in this 
>> message to be reviewed by the WG for correctness before final submission and 
>> advancement. 
>>
>> [1] https://www.ietf.org/mail-archive/web/netmod/current/msg20049.html
>>
>> Thanks,
>> Kent, Lou, and Joel
>>
>>
>>
>> ___
>> netmod mailing list
>> netmod@ietf.org
>> https://www.ietf.org/mailman/listinfo/netmod


___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

[netmod] Publication has been requested for draft-ietf-netmod-yang-tree-diagrams-05

[Joel Jaeggli]

Joel Jaeggli has requested publication of 
draft-ietf-netmod-yang-tree-diagrams-05 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-yang-tree-diagrams/

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] moving forward with schema mount

[joel jaeggli]

On 1/23/18 3:24 AM, Martin Bjorklund wrote:
> Hi,
>
> So do you believe that this decision reflects rough consensus in the
> WG?
>
> I hope that the document writeup will show that the WG is divided on
> this issue.
>
> For the record, if this means that using Schema Mount *with* NMDA gets
> delayed, I strongly object to this decision.
I don't think it does. assuming we had a draft that addresses that
problem. we could poll for working group adoption now.  and proceed with
that one accordingly. what happens there is orthogonal to sending this
one on it's way.
> Assuming this document now moves forward as-is, can we assume that we
> can start to work on the bis document immediately?  What is needed?
>
>   1.  a new individual draft
>   2.  some time until this becomes WG draft
call for adoption can occur once we have a draft.
>   3.  some time before WGLC
>
> Do we have to go through all these steps?
there's roughly three weeks of more or less required process time 
between submission to a working group and the close of WGLC, everything
else is compressible to various degrees if we can satisfy our standards
for consensus, and we don't spend to much time orbiting the same point.
> This new draft would immediately obsolete the current SM document,
> right?  And it would mark the current SM YANG nodes as deprecated.
>
> Maybe we can send both the original document and the bis document to
> the IESG at the same time ;-)
If you hurry. the first one has taken a bit over 2 years to this point,
I certainly think we can reel that in.
>
> /martin
>
>
> Kent Watsen  wrote:
>> 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 and rfc7895bis and 
>> an alternate representation of inline schema.  These have been considered 
>> respecting their impact on the last call consensus and it is the position of 
>> the chairs that it is best to advance the existing schema-mount document at 
>> this time.
>>
>> Given that there are significant concerns for how the solution proposed in 
>> this draft operates with NMDA, we do think it reasonable to add an 
>> applicability statement to the draft that covers its operation in NMDA 
>> implementations. We do not believe that such a statement substantively 
>> alters the draft nor would it impact drafts that normatively reference the 
>> current draft.
>>
>> In addition to resolving the remaining open thread [1], we also agree with 
>> the recently made comment that the schema mount draft should allow the use 
>> of rfc7895bis (i.e., not reference /modules-state), thereby enabling the 
>> draft's use (though not ideal) on servers supporting rfc7895bis.
>>
>> The chairs will propose specific text for the updates mentioned in this 
>> message to be reviewed by the WG for correctness before final submission and 
>> advancement. 
>>
>> [1] https://www.ietf.org/mail-archive/web/netmod/current/msg20049.html
>>
>> Thanks,
>> Kent, Lou, and Joel
>>
>>
>>
>> ___
>> netmod mailing list
>> netmod@ietf.org
>> https://www.ietf.org/mailman/listinfo/netmod
>>
> ___
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
>


___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

[netmod] Closure - : WGLC - draft-ietf-netmod-yang-tree-diagrams

[joel jaeggli]

Greetings,

This WGLC is concluded.

We have consensus to advance the document.

The authors should submit an update reflecting the result of the
dicussion on the text representation of tree diagrams not being usable
by machine parsers.

The exchange between Robert Wilton and Martin Bjorkland I think sums
this up succinctly.

(Robert)

OK, so the "Providing some guidance for how to represent the tree is
good" is along the lines of what I was thinking for the "algorithm"
would be for 2.

E.g. something along the lines of:
"Arbitrary whitespace is allowed between any of the whitespace
separated fields (e.g.  and ).  Additional whitespace may
be used to column align fields (e.g. within a list or container) to
improve readability".

(Martin)
This is fine with me.  It is something in between (1) and (2) which
people preferred.  I will add this text.

Thanks all, looking forward to IETF last call.

joel
 


On 1/16/18 9:24 AM, joel jaeggli wrote:
> The current dicussion on the draft is not yet concluded. The WGLC will
> conclude when discussion of the editorial changes is complete.
>
> Thanks
> joel
>
> On 1/10/18 8:16 AM, joel jaeggli wrote:
>> Just a reminder given the date that this was posted. This last call is
>> expected to complete Monday 1/15/18.
>>
>> Thanks
>>
>> joel
>>
>>
>> On 1/1/18 2:01 PM, joel jaeggli wrote:
>>> Greetings,
>>>
>>> We hope  the new year is a time to make great progess on outstanding
>>> documents before preparation for the  London IETF begins in earnest.
>>>
>>> This starts a two-week working group last call on:
>>>
>>>  YANG Tree Diagrams
>>> draft-ietf-netmod-yang-tree-diagrams
>>>
>>> https://datatracker.ietf.org/doc/draft-ietf-netmod-yang-tree-diagrams/
>>>
>>> Please send email to the list indicating your support or concerns.
>>>
>>> We are particularly interested in statements of the form:
>>>
>>>   * I have reviewed this draft and found no issues.
>>>   * I have reviewed this draft and found the following issues: ...
>>>
>>>
>>> Thank you,
>>> NETMOD WG Chairs
>>>
>>>
>>>
>>>
>> ___
>> netmod mailing list
>> netmod@ietf.org
>> https://www.ietf.org/mailman/listinfo/netmod
>>
> ___
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
>


___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] schema mount and YANG library

[joel jaeggli]

On 1/18/18 11:15 AM, Martin Bjorklund wrote:
> Ladislav Lhotka  wrote:
>> On Thu, 2018-01-18 at 14:39 +0100, Juergen Schoenwaelder wrote:
>>> Ignoring process issues (not sure there are any), does it make sense
>>> to publish a YANG module on the standards-track that is replaced by
>>> something different 3-6 months later?
>> IMO such a document churn would be a serious mistake. In the documents that 
>> are
>> currently on the table (at least NMDA, YLbis, SM) we are dealing with quite a
>> few tricky and interrelated things, so it's important to come up with a 
>> coherent
>> view into which all the components nicely fit. And I believe we are now quite
>> close.
>>
>> Publishing an interim solution that is a priori known to be technically 
>> inferior
>> would just confuse people. The fact that it can be hacked to support two or
>> three particular data models (albeit important) doesn't warrant to do so.
> I strongly agree with this!
Do we believe that documents using normative referencing to this draft
e.g. in routing would require changes in order to accommodate an updated
draft?

If yes then we're doing ourselves a clear dis-service by essentially
clearing the boards of the existing draft.  If that is the case we
should consider publishing this one possibly with an appropriate
applicability statement; the work on the new one can proceed so that at
least they have a stable reference. This assumes not fundamental flaws
that make the current one unusable.


> /martin
>
>>> Note that the NMDA contributors, after getting the overall design
>>> done, move sequentially through the details of the documents; we first
>>> focused on the NMDA document, which is in the RFC editor queue now. We
>>> then focussed on the protocol extensions, which are now in WG last
>>> call. Currently we are focusing on getting the new yang library
>>> finalized. If no major isses pop up, the NMDA work may be complete by
>>> the London IETF. Hence the 3 months lower bound mentioned above.
>> I agree, and will try to help.
>>
>> Thanks, Lada
>>
>>> /js
>>>
>>> On Thu, Jan 18, 2018 at 07:58:07AM -0500, Lou Berger wrote:
 Martin,

 I do agree with that at some point we will need to revisit scheme mount in
 the context of YL-bis, as there are different possible solutions for
 handling different datastores mounting  different schema. I think Rob laid
 out the options pretty well here, ie doing it now or publishing as is and
 immediately working on the document that covers both.

 As I mentioned before I think this is as much a process issue as anything
 else - and have a planned call to discuss possible directions with chairs. 
 I
 hope we can have some propose next steps on this to the working group in
 short order.

 Lou


 On January 18, 2018 2:57:23 AM Martin Bjorklund  wrote:

> Lou Berger  wrote:
>>
>> On 1/17/2018 11:18 AM, Martin Bjorklund wrote:
>> ...
> My main concern is actually the YL version.  I strongly think SM
> need
> to use YL-bis rather that the old YL, so that it can support NMDA.
>
 Right now to SM is independent of Yang Library version and can run
 with either.
>>> No this is not correct.  SM uses a grouping from the old YANG
>>> library (for the "use-schema" case),
>> I thought YLbis was an updat e to UL (i.e., no name change) as such SM
>> can include either.
> The old "modules-state" structure is deprecated, and a new structure
> that allows multiple datastores is defined.  Note that YLbis can be
> used by both NMDA-capabale and non-NMDA-capabale servers.
>
>>>   and talks about mounting
>>> "modules-state" ("inline" case).
>> In informative descriptions only.  Certainly these can be changed to
>> allow for YL-bis if need be.
>>
 I certainly would expect use of Yang Library bis and nmda
 to have advantages.

> The implementation effort for supporting the new YL in clients and
> servers is minimal, esp. when compared to the efforts involved in
> supporting SM.
>
> Adding an indirection is (for me) less important, but it has the
> benefit of solving the two issues (a) and (b) above, and I haven't
> seen any technical problem with it.
>
 (A) has implementation implications and those participating in the
 discussion at the time expressed as not being worth the cost.
 I don't believe b was seen as a significant issue either.

> Do you have any technical concerns with using an annotation as an
> indirection?
>
 The technicsl issue I have with the approaches the same one that was
 raised when debated previously, ie the implementation overhead of
 requiring inline schemas to be available at the top level.
>>> 

Re: [netmod] schema mount and YANG library

[joel jaeggli]

On 1/18/18 05:39, Juergen Schoenwaelder wrote:
> Ignoring process issues (not sure there are any), does it make sense
> to publish a YANG module on the standards-track that is replaced by
> something different 3-6 months later?

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 think it's more a question of can we live with publishing the module
now as is? Or can  we not live with publishing it now?

> Note that the NMDA contributors, after getting the overall design
> done, move sequentially through the details of the documents; we first
> focused on the NMDA document, which is in the RFC editor queue now. We
> then focussed on the protocol extensions, which are now in WG last
> call. Currently we are focusing on getting the new yang library
> finalized. If no major isses pop up, the NMDA work may be complete by
> the London IETF. Hence the 3 months lower bound mentioned above.
> 
> /js
> 
> On Thu, Jan 18, 2018 at 07:58:07AM -0500, Lou Berger wrote:
>> Martin,
>>
>> I do agree with that at some point we will need to revisit scheme mount in
>> the context of YL-bis, as there are different possible solutions for
>> handling different datastores mounting  different schema. I think Rob laid
>> out the options pretty well here, ie doing it now or publishing as is and
>> immediately working on the document that covers both.
>>
>> As I mentioned before I think this is as much a process issue as anything
>> else - and have a planned call to discuss possible directions with chairs. I
>> hope we can have some propose next steps on this to the working group in
>> short order.
>>
>> Lou
>>
>>
>> On January 18, 2018 2:57:23 AM Martin Bjorklund  wrote:
>>
>>> Lou Berger  wrote:


 On 1/17/2018 11:18 AM, Martin Bjorklund wrote:
 ...
>>> My main concern is actually the YL version.  I strongly think SM need
>>> to use YL-bis rather that the old YL, so that it can support NMDA.
>>>
>> Right now to SM is independent of Yang Library version and can run
>> with either.
> No this is not correct.  SM uses a grouping from the old YANG
> library (for the "use-schema" case),
 I thought YLbis was an updat e to UL (i.e., no name change) as such SM
 can include either.
>>>
>>> The old "modules-state" structure is deprecated, and a new structure
>>> that allows multiple datastores is defined.  Note that YLbis can be
>>> used by both NMDA-capabale and non-NMDA-capabale servers.
>>>
>   and talks about mounting
> "modules-state" ("inline" case).
 In informative descriptions only.  Certainly these can be changed to
 allow for YL-bis if need be.

>> I certainly would expect use of Yang Library bis and nmda
>> to have advantages.
>>
>>> The implementation effort for supporting the new YL in clients and
>>> servers is minimal, esp. when compared to the efforts involved in
>>> supporting SM.
>>>
>>> Adding an indirection is (for me) less important, but it has the
>>> benefit of solving the two issues (a) and (b) above, and I haven't
>>> seen any technical problem with it.
>>>
>> (A) has implementation implications and those participating in the
>> discussion at the time expressed as not being worth the cost.
>> I don't believe b was seen as a significant issue either.
>>
>>> Do you have any technical concerns with using an annotation as an
>>> indirection?
>>>
>> The technicsl issue I have with the approaches the same one that was
>> raised when debated previously, ie the implementation overhead of
>> requiring inline schemas to be available at the top level.
> Ok.  I'm ok with keeping the inline case as it is.  However, I think
> we need to use the new YL-bis, so that we can support the NMDA.
 Given that NMDA support is not yet fully defined, we're still in the
 transition period where support for both NMDA and non-NMDA
 implementations need to be considered.  Rob presented some options
 earlier in the thread that I think captures this.
>>>
>>> Again, note that YLbis supports both NMDA and non-NMDA servers.
>>>
>>> Also note that YLbis is just a different read-only monitoring
>>> structure.  Given an implementation that supports the old YL, it is
>>> trivial to add support for YLbis (especially compared to the more than
>>> non-trivial amount of work required to support schema mount...).
>>>
>>>
>>> /martin
>>>
>>
>>
>> ___
>> netmod mailing list
>> netmod@ietf.org
>> https://www.ietf.org/mailman/listinfo/netmod
> 




signature.asc
Description: OpenPGP digital signature
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] WGLC - draft-ietf-netmod-yang-tree-diagrams

[joel jaeggli]

On 1/16/18 8:01 AM, Robert Wilton wrote:
>
>
> On 16/01/2018 15:40, Martin Bjorklund wrote:
>> Vladimir Vassilev  wrote:

>> Does anyone else have an opinion on this?  I can see three
>> alternatives:
>>
>>    1) allow any number of addtional spaces
>>    2) allow any number of addtional spaces + define a suggested
>>   alignment algorithm
>>    3) mandate the alignment algorithm
>
> Definition of symbols should be precise/consistent, so that readers
> can consistently interpret tree diagrams.
>
> I think that flexibility in layout should be OK, but the draft should
> provide guideline to ensure the output is readable, and likely to be
> broadly consistent (since consistency aids readability).
>
> If the IETF data modeling group is trying to specify text output
> precisely enough that it can be screen scraped then we may want to
> consider whether we are focusing on the right solution ;-)
I would hope that we are not, as the diagrams are programmatically 
generated if you wanted to for example validate them one should do that
from the sources. 

Approaches that result in the most easily human readable, followed by
consistency between tools is probably better for that. That said this is
almost the indentation wars so the proscriptive it gets the more dissent
you can probably find (e.g. 3).

> In summary, (2) is my preference, followed by (1), followed by (3).
>
> Thanks,
> Rob
>
>>
>>
>> /martin
>>
>> ___
>> netmod mailing list
>> netmod@ietf.org
>> https://www.ietf.org/mailman/listinfo/netmod
>> .
>>
>
> ___
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
>


___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] Reminder: WGLC - draft-ietf-netmod-yang-tree-diagrams

[joel jaeggli]

The current dicussion on the draft is not yet concluded. The WGLC will
conclude when discussion of the editorial changes is complete.

Thanks
joel

On 1/10/18 8:16 AM, joel jaeggli wrote:
> Just a reminder given the date that this was posted. This last call is
> expected to complete Monday 1/15/18.
>
> Thanks
>
> joel
>
>
> On 1/1/18 2:01 PM, joel jaeggli wrote:
>> Greetings,
>>
>> We hope  the new year is a time to make great progess on outstanding
>> documents before preparation for the  London IETF begins in earnest.
>>
>> This starts a two-week working group last call on:
>>
>>  YANG Tree Diagrams
>> draft-ietf-netmod-yang-tree-diagrams
>>
>> https://datatracker.ietf.org/doc/draft-ietf-netmod-yang-tree-diagrams/
>>
>> Please send email to the list indicating your support or concerns.
>>
>> We are particularly interested in statements of the form:
>>
>>   * I have reviewed this draft and found no issues.
>>   * I have reviewed this draft and found the following issues: ...
>>
>>
>> Thank you,
>> NETMOD WG Chairs
>>
>>
>>
>>
>
> ___
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
>

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

[netmod] Reminder: WGLC - draft-ietf-netmod-yang-tree-diagrams

[joel jaeggli]

Just a reminder given the date that this was posted. This last call is
expected to complete Monday 1/15/18.

Thanks

joel


On 1/1/18 2:01 PM, joel jaeggli wrote:
> Greetings,
>
> We hope  the new year is a time to make great progess on outstanding
> documents before preparation for the  London IETF begins in earnest.
>
> This starts a two-week working group last call on:
>
>  YANG Tree Diagrams
> draft-ietf-netmod-yang-tree-diagrams
>
> https://datatracker.ietf.org/doc/draft-ietf-netmod-yang-tree-diagrams/
>
> Please send email to the list indicating your support or concerns.
>
> We are particularly interested in statements of the form:
>
>   * I have reviewed this draft and found no issues.
>   * I have reviewed this draft and found the following issues: ...
>
>
> Thank you,
> NETMOD WG Chairs
>
>
>
>


___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] Kathleen Moriarty's Discuss on draft-ietf-netmod-rfc7277bis-01: (with DISCUSS)

[joel jaeggli]

On 1/8/18 1:53 PM, Kathleen Moriarty wrote:
> Kathleen Moriarty has entered the following ballot position for
> draft-ietf-netmod-rfc7277bis-01: Discuss
>
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
>
>
> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
>
>
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-netmod-rfc7277bis/
>
>
>
> --
> DISCUSS:
> --
>
> Hello,
>
> I'm a little confused on the Security Consideration section as it doesn't use
> the latest template, but does specify SSH for NETCONF, so I'm good with that
> part.  Will RESTCONF also be used as a transport or is there some reason it
> won't be used for this YANG module?
>
> Here's what I think is the latest template and please let me know if sections
> of it do not apply to this draft and I'll drop the discuss for correcting the
> security considerations section.

the security consideration section of 7277bis is the same as for rfc 7277

the ssh recommendation came from you at the time.


  *Comment* (2014-03-21 for -13)

Add a RECOMMEND use of SSH in addition to the MTI to prevent MITM or monitoring 
attacks (pervasive or otherwise).

> https://tools.ietf.org/html/draft-ietf-netmod-rfc6087bis-10#page-52
>
> Thanks in advance!
>
>
>
>

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

[netmod] WGLC - draft-ietf-netmod-yang-tree-diagrams

[joel jaeggli]

Greetings,

We hope  the new year is a time to make great progess on outstanding
documents before preparation for the  London IETF begins in earnest.

This starts a two-week working group last call on:

 YANG Tree Diagrams
draft-ietf-netmod-yang-tree-diagrams

https://datatracker.ietf.org/doc/draft-ietf-netmod-yang-tree-diagrams/

Please send email to the list indicating your support or concerns.

We are particularly interested in statements of the form:

  * I have reviewed this draft and found no issues.
  * I have reviewed this draft and found the following issues: ...


Thank you,
NETMOD WG Chairs






signature.asc
Description: OpenPGP digital signature
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

[netmod] Publication has been requested for draft-ietf-netmod-rfc8022bis-06

[Joel Jaeggli]

Joel Jaeggli has requested publication of draft-ietf-netmod-rfc8022bis-06 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-rfc8022bis/

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

[netmod] Publication has been requested for draft-ietf-netmod-rfc7277bis-01

[Joel Jaeggli]

Joel Jaeggli has requested publication of draft-ietf-netmod-rfc7277bis-01 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-rfc7277bis/

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

[netmod] draft-ietf-netmod-yang-tree-diagrams - IPR verfication request

[joel jaeggli]

Authors, Contributors, WG,

As part of the preparation for WG Last Call:

Are you aware of any IPR that applies to drafts identified above?

Please state either:

"No, I'm not aware of any IPR that applies to this draft"
or
"Yes, I'm aware of IPR that applies to this draft"

If so, has this IPR been disclosed in compliance with IETF IPR rules
(see RFCs 3669, 5378 and 8179 for more details)?

If yes to the above, please state either:

"Yes, the IPR has been disclosed in compliance with IETF IPR rules"
or
"No, the IPR has not been disclosed"

If you answer no, please provide any additional details you think
appropriate.

If you are listed as a document author or contributor please answer the
above by responding to this email regardless of whether or not you are
aware of any relevant IPR. This document will not advance to the next
stage until a response has been received from each author and listed
contributor. NOTE: THIS APPLIES TO ALL OF YOU LISTED IN THIS MESSAGE'S
TO LINES.

If you are on the WG email list or attend WG meetings but are not listed
as an author or contributor, we remind you of your obligations under
the IETF IPR rules which encourages you to notify the IETF if you are
aware of IPR of others on an IETF contribution, or to refrain from
participating in any contribution or discussion related to your
undisclosed IPR. For more information, please see the RFCs listed above
and
http://trac.tools.ietf.org/group/iesg/trac/wiki/IntellectualProperty.

Thank you,
NetMod WG Chairs

PS Please include all listed in the headers of this message in your
response.




signature.asc
Description: OpenPGP digital signature
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

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

[joel jaeggli]

Thanks,

sounds like we have a lot of docs to look after.

looking forward to helping out.

joel

On 12/15/17 13:03, Kent Watsen wrote:
> 
> Indeed, congrats!
> 
> K.
> 
> Sent from my iPhone
> 
> On Dec 15, 2017, at 12:19 PM, Lou Berger 
> <lber...@labn.net<mailto:lber...@labn.net>> 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
> management at the IETF:
> NMDA architecture, NETCONF, RESTCONF
> NMDA-compliant YANG modules: some RFC bis modules but also new ones
> Guidelines: RFC6087bis and the tree diagram
> The interaction with NETCONF: The schema mount, IETF-YANG-LIBRARY,
> telemetry
> The interaction with routing, where many YANG modules come from.
> etc.
> There are a lot of dependencies between all these tasks, which must take
> place in parallel, and, obviously, be completed ASAP.
> 
> Kent and Lou have a lot on their shoulders these days.
> To help with the situation and proactively progress documents, I'm happy
> to announce that Joel Jaeggli accepted to serve as a third NETMOD
> co-chair. Thank you Joel.
> 
> Please welcome Joel.
> 
> Regards, Benoit
> 
> ___
> netmod mailing list
> netmod@ietf.org<mailto:netmod@ietf.org>
> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_netmod=DwIGaQ=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo=aQtrcY_GHgRkFfWKs98sSl_yYy7MAromRtRm63miwFQ=mxu0y9ch7J7FeNSpDgZkgFaNo_22Ucov9NXusI356DE=
> 
> ___
> netmod mailing list
> netmod@ietf.org<mailto:netmod@ietf.org>
> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_netmod=DwIGaQ=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo=aQtrcY_GHgRkFfWKs98sSl_yYy7MAromRtRm63miwFQ=mxu0y9ch7J7FeNSpDgZkgFaNo_22Ucov9NXusI356DE=
> 

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod