[netmod] draft item 104 meeting 1/2 minutes

Joel Jaeggli <joelja@bogus.com> Sat, 13 April 2019 22:36 UTC

Return-Path: <joelja@bogus.com>
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id B91761200CE; Sat, 13 Apr 2019 15:36:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.9
X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id n50rqvwASJjZ; Sat, 13 Apr 2019 15:35:58 -0700 (PDT)
Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 64A2B1200B3; Sat, 13 Apr 2019 15:35:58 -0700 (PDT)
Received: from [IPv6:2601:647:4201:4561:c105:62f6:c24a:844a] ([IPv6:2601:647:4201:4561:c105:62f6:c24a:844a]) (authenticated bits=0) by nagasaki.bogus.com (8.15.2/8.15.2) with ESMTPSA id x3DMZuc5032528; Sat, 13 Apr 2019 22:35:57 GMT (envelope-from joelja@bogus.com)
From: Joel Jaeggli <joelja@bogus.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.8\))
Message-Id: <5E420615-0D27-4FB3-9AB7-D005EFB9F484@bogus.com>
Date: Sat, 13 Apr 2019 15:35:56 -0700
To: NETMOD Working Group <netmod@ietf.org>, NetMod WG Chairs <netmod-chairs@ietf.org>
X-Mailer: Apple Mail (2.3445.104.8)
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/I2_rWCNjPDfUYzowE5KV85jMbp8>
Subject: [netmod] draft item 104 meeting 1/2 minutes
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list <netmod.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/netmod/>
List-Post: <mailto:netmod@ietf.org>
List-Help: <mailto:netmod-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 13 Apr 2019 22:36:02 -0000

IETF 104 netmod meeting minutes

Monday Session 1 - Second half of netconf slot, 2019/03/25 1000

Monday Session 2 - 2019/03/25 1350

* Monday Session 1 *

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

Requirements Draft update – Joe Clarke (5 mins)
• Design Team update & Solution overview – Rob Wilton (10 mins)
• Semantic versioning for modules – Balazs Lengyel (20 mins)
• Semantic versioning for YANG schema – Rob Wilton (10 mins)
• Schema version selection – Reshad Rahman (10 mins)

Joe presenting on requirements - 

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 *


     Chairs (10 minutes)
     Session Intro & WG Status

Chairs: the following will be LCed after the meeting 

Robert Sparks: IETF is managing YANG Catalog 

   WG documents items:

     Balazs Lengyel (10 min)
     YANG Instance Data File Format

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

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)

	other approach is to just use an annotation.

joe: this extension allows lists to not need a key element

lou: please add to you list how this impacts tree diagrams?

lou: how many have read this version ( a few)
	how many have read any version? (one more)
	for both documents we'll have to talk among chair about last call before montreal, may use a as forcing function for review.

     Kent Watsen (10 min)
     Handling Long Lines in Inclusions in Internet-Drafts and RFCs

christian - is the martins suggestion work for all cases?

kent - seems like it has a dangerous chance of collision.

martin: cases where the pretty thing doesn't work

kent: for automated folding you would need a smart folder

martin prefers one

christian: should have one way even if it's a little bit harder

rob: don't think a single backslash can cover all cases.

kent:  poll on approaches - double backslash only  (no suppport)
	both methods (some support)
	only single (also some support)

kent question footer
	a (leave draft as is)
	b add a footer 

lou: clear majority for a over b

   Non-Chartered items:

     Kent Watsen (15 min)
     YANG Next Analysis
     <no associated draft>

kent: 70 issues over 3 years created in yang next issue tracker.

Kent: Where should we focus

juergen: two other dimensions, do we know how to solve? do we have consensus?
     Qin Wu (10 min)
     Factory default Setting

Kent (polling)
- How many have read draft: a reasonable number
- How many interested in problem addressed in draft: a reasonable number
- Now many think we should not work on this topic: none
- How many think draft should be adopted as starting point: a reasonable number
- How many think it should not be adopted: none

Adoption poll will be taken to the list

     Qin Wu (10 min)
     NMDA Base Notification for Applied Intended Configuration

Kent (polling):
    -  How many have read draft: very few
     - how man think intersting:  also few
lou: how many people think this is an area we should be spending time on? (a little more)

Lou: Need more feedback from group, please send a summary to the list of objectives  to list to try to generate interest

     Christian Hopps (10 min)
     YANG Geographic Location

Kent (polling)
    - How many have read draft: a few
    - how man think intersting:  more
    - how many would like to see document used as basis: a good number
    - How many think it should not be adopted: none

Adoption poll will be taken to the list

     Juergen Schoenwaelder (15 min)
     Update of Common YANG Data Types (RFC 6991)

Kent (polling)
- How many have read draft: a reasonable number
- How many interested in problem addressed in draft: a reasonable number
- Now many think we should not work on this topic: none
- How many think draft should be adopted as starting point: a reasonable number
- How many think it should not be adopted: none

Adoption poll will be taken to the list

Update of Common YANG Data Types
Jürgen Schönwälder

rob: type defs are cheap so define both nanoseconds and minutes (time resolution)

lada: host type should be restricted narrowly

chris: does the canonical format go down to seconds?

kent: hundreths of seconds

	possibly more types (days weeks hours months)

Lou (polling)
- How many have read draft: a reasonable number
- How many interested in problem addressed in draft: a reasonable number
- Now many think we should not work on this topic: none

chris: we're adding more common types

lou:  does it make sense to rev this as a bis. lets use the model of keep reving this

rob: if we delay by and extra year we'll have more to add.

lou: lets see how fast we can do it.

     Michale Wang / Chongfeng Xie (10 min)
     A YANG Data model for Policy based Event Management

lou: how many have read this (a few)
	maybe it's early but how many this is a starting point (some)
	adopting now (less)
	wait a bit (few)

	this is coming out of yang push dt in netconf

meeting concludes