Minutes for NETMOD at interim-2014-netmod-15
minutes-interim-2014-netmod-15-1

=============================================================
NETCONF Data Modeling Language WG (netmod)
6th YANG 1.1 Virtual Interim
Wednesday, October 15, 2014, 16:00-18:00 CEST
Minutes Juergen Schoenwaelder
=============================================================

* Participants

  - JS = Juergen Schoenwaelder
  - BL = Balazs Lengyel
  - MB = Martin Bjorklund
  - LL = Lada Lothka
  - EV = Eric Voit
  - AB = Andy Biermann
  - V? = Vladimir
  - DR = David Reid
  - JT = JF Tremblay
  - KW = Kent Watsen
  - TN = Tom Nadeau

* Organizational

  - This is the last virtual interim allocated to YANG 1.1. How do we
    continue?
	
  - Allocate slots to continue right after the IETF week, keeping the
    Wednesday slots.
	
  - Can we use the 29th of October? The IETF meeting is November 9-14
    and the next possible slot after October 29th would be November 19.

  - During the next meeting, we will try to tackle the conformance
    related issues again.
	
* Y58 associate an actions with a data node

  JS: Is Balazs proposal complete? Do we need to formally define an
      RPC?
  MB: Yes, there should be an RPC for it.
  BL: I agree with an RPC definition.
  LL: What about the approach of sending an instance identifier?
  BL: Is this Q2?
  BL: Having the action element inside of the nested tree avoids
      issues with name clashes. This also maps more natural to the CLI.
  AB: The signature of a reset action may differ significantly
      depending on where it appears.
  AB: I do not really like this much but this is all implementation
      detail.
  MB: Does the DSDL not work with the example we have here?
  MB: I see why using instance identifiers may be problematic, I do
      not see why the nested encoding would be problematic since you
      have all the context.
  LL: How does this work with access control?
  AB: I believe NACM would need to be modified to check parameters
      that identify where an action belongs. It is easier for the
      nested solution.
  JS: Does this require changes to NACM?
  MB: The data model allows to set this, but the text in the
      procedures needs an update.
  MB: Action to look into the details of the NACM update.
  JS: What about notifications associated to data nodes?
  BL: No indication that somebody seriously wants this.
  AB: From a YANG point of view, it seems strange to do this for
      actions but not for notifications.
  MB: I agree with AB.
  LL: Are the access control arguments valid for notifications as
      well?
  KW: How is the list instance identified?
  MB: This is in the example, see the name leaf of the server element.

  Proposal: Use the nested encoding but remove the data wrapper. Open
  Y36 again and ask for proposals how to encode notifications
  associated with data nodes.

* Y57 unique leaf-list

  LL: If we have such a leaf-list and it is ordered by system, it
      seems impossible to insert after a certain position.
  BL: Yes.
  AB: An insert after is always an error on a system ordered list.
  LL: Seems to be OK. I support this change.
  BL: Q1 - go with A1a?
  AB: A single leaf-list value is often not interesting, usually it is
      the whole list.
  KW: Do we need to solve this at all? Where does this pop up?
  LL: An example is an AS path where AS numbers can repeat.
  BL: We have a number of examples in proprietary data models.
  BL: Q2 - go with A2a?
  BL: Q3 - go with A3a?
  MB: What do you mean with addressing?
  MB: Can you also delete by position? Would that not be a solution?
  BL: Prefer to delete just one.
  MB: I agree with Andy. The way we handle leaf-list today makes this
      somewhat awkward.
  MB: If we add this, then the way we do thinks today becomes more a pain.
  AB: The way NC works today is that only one instance is deleted at time.
  MB: So this means A3a.
  AB: Yes.
  BL: Q4 - go with A4b?
  AB: Do we need a YANG substatement to say whether a leaf-list allows
      duplicates?
  BL: Yes.
  MB: How would you move say the second a somewhere else?
  BL: With position, you can remove the second a.
  MB: For moving, you have to specify two positions (current, new).
  BL: A move operation is currently not part of the proposal.
  BL: Do we need a move operation?
  JS: Does all of this only apply to ordered by user lists?
  BL: Some operations may require position and thus ordered by user
      lists, but others don't.
  LL: Can we simplify this? Does it make sense to edit system ordered
      lists?
  AB: I think it makes sense to restrict this to user ordered lists.
  MB: Why would we make it illegal to have duplicates in system
      ordered leaf-lists?
  LL: We are talking about different collections, lists and sets.
  LL: Perhaps we can even make this leaf-list and leaf-set.
  MB: Would the set have an order?
  BL: We have use cases for unique ordered lists.
  LL: You can use a must statement to make the list elements unique if
      need be.
  MB: We need to be compatible with YANG 1.0.
  MB: If an ordered-by user leaf list is moved to 1.1, then it means
      something else?
  AB: I do not want to introduce any changes unless absolutely
      necessary. We should not change silently how a leaf-list works.
  MB: Having the same YANG statement mean different things in two
      versions of YANG is to be avoided.
  BL: Unless you use the new keyword, everything works as it was
      before.
  MB: I rather add a new substatement than changing the semantics of
      existing statements.
  BL: A5
  MB: Yes.
  KW: Some system ordered lists tend to be stable.
  MB: We need to be careful what happens with position if access
      control is applied.
  BL: I believe it is the same as why insert is not allowed on system
      ordered since there is no guarantee that the order is stable.
  KW: If I do a get-config followed by an edit-config on a single
      session, is the order not predictable?
  AB: The RFC is pretty clear that there is no guarantee that the
      order is stable.
  AB: An example is a balanced tree where a change of the tree can
      change the walk order significantly.
  KW: If the order could be assumed to be stable, position would work
      for at least a single session.
  MB: I am not sure why would use that. You can delete by value.
  BL: But for system ordered, you can have multiple values as well.
  LL: Leaf-lists in operational state will be system ordered and I can
      see that there might be non-unique values.
  BL: A6
  BL: A7
  AB: Does in this case position say find the second leaf-list element
      with the given value?
  BL: I have not thought about this in this way.
  MB: I think it should be the absolute position.
  AB: If you provide a value, you want the second of those with the
      same value.
  MB: If the leaf-list is a string and you allow an empty string, you
      can't distinguish the two cases.
  AB: This is a good point. But I do not like the server ignoring a
      value if it is presented. I think this should actually be an
      error if the value is not at the position.
  MB: I agree.
  KW: Yes.
  BL: A9
  AB: Agree.
  BL: A8
  AB: This should be an error. This is an edit-config that is not a delete.
  MB: What about replace?
  BL: Move is difficult since it requires two positions.
  BL: We skip A8 because I do not understand it right now.
  BL: Do we need a move operation?
  BL: If nobody speaks up, we will not do a move operation.
  
  BL: I will take an action item to write a proposal and a summary of
      the changes that are needed.
  
* Y56 UTF8 non-characters

  LL: Is this to be done at the protocol level or the YANG level?
  JS: I think we should say what is allowed in YANG
  MB: This is about the character set, not about the encoding (UTF8 or
      UTF16, which is a protocol issue).
  MB: I agree that we should define in this in YANG.

  Proposal: Adopt Y56-01. MB will work the concrete text with the help
  of LL.
	
* Y42 a better model for configuration versus state data is needed

  JS: We may want to move this to closed since there is nothing to do
  until I2RS has decided what they need. Once this happens, we can
  reopen this issue or add more concrete issues (which may be a better
  choice).

  Proposal: Move Y42 to DEAD.
	
* Y28 support default values in leaf-lists

  LL: What about additive defaults?
  BL: Do you have examples where this is useful instead of overriding?
  LL: I can create an example, but perhaps additive defaults get complicated.
  BL: My feeling is that Andy's always replace behavior is simple to
      understand.
  JS: Adopt Y28-02?
  MB: Yes
  AB: Yes
  LL: OK

  Proposal: Adopt Y28-02.
	
* Y13 allow multiple inheritance for identities

  AB: Is this an OR or an AND if I have multiple bases?
  MB: Y13-01 says AND.
  AB: If in the example the base would be non-commercial, only
      CC-BY-NC-SA would be valid.
  MB: We probably want multiple bases in identityrefs. But then why
      would it be AND and not OR?
  AB: I am not sure how this impacts my implementation yet.
  MB: You can get an OR by using a union type of multiple identityrefs.
  JS: Seems we go with Y13-01.

  Proposal: Adopt Y13-01.