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 > > 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) > > 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 > https://tools.ietf.org/html/draft-ietf-netmod-artwork-folding-01 > > 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 > https://tools.ietf.org/html/draft-wu-netmod-factory-default-02 > > 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 > https://tools.ietf.org/html/draft-wu-netmod-base-notification-nmda-01 > > 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 > https://tools.ietf.org/html/draft-chopps-netmod-geo-location-01 > > 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) > https://tools.ietf.org/html/draft-schoenw-netmod-rfc6991-bis-00 > > 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 > https://tools.ietf.org/html/draft-wwx-netmod-event-yang-01 > > > 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 > > > > _______________________________________________ > netmod mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/netmod >
signature.asc
Description: OpenPGP digital signature
_______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
