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

=============================================================
NETCONF Data Modeling Language WG (netmod)
8th YANG 1.1 Virtual Interim
Wednesday, November 19, 2014, 16:00-18:00 CET
Minutes Juergen Schoenwaelder
=============================================================

* Participants

  - JS = Juergen Schoenwaelder
  - KW = Kent Watsen
  - LL = Lada Lhotka
  - MB = Martin Bjorklund
  - BL = Bing Lu
  - PS = Phil Shafer
  - GZ = Guangying Zheng
  - IB = Ignas Bagdonas
  - YY = Yangyang
    
* 64-bit numbers in xpath expressions

  LL: I think this is a bug-fix issue to track.
  MB: Is this a real problem?

  Action: LL to write-up a new issue and to send it to the mailing
  list.
  
* Y05 unprefixed path in top-level typedef

  MB: I proposed some text to resolve this in Y05-01
  PS: I prefer consistency with groupings.
  LL: I think additional text should be added for derived typedefs.
  LL: Perhaps we need some usage guidelines, e.g. warnings about not
      using namespaces.
  
  Proposal: Adopt Y05-01.
  
* Y09 introduce optional keys

  PS: I pointed out that not() can't be used that easily.
  PS: Many database technologies require keys.
  LL: I believe this is related to non-unique leaf lists (Y57), 
      positional addressing could be used here as well.
  KW: Is the example in Y09-02 incomplete or a default lacking?
  LL: A default is not necessary.
  JS: Does this allow to add an optional leaf?
  JS: I believe we concluded that adding optional leafs can't be supported.
  PS: Adding an optional key breaks the initial contract.
  JS: If we can use optional keys only at initial module design time,
      how useful is this then?
  MB: This might still be useful, for example, if you define a new
      list derived from an old list.
  PS: I prefer to keep things simple.
  MB: Optional keys are valuable in cases such as supporting VRFs.
  KW: Perhaps we should only allow optional keys if there is a default?
  JS: This would be another solution, lets say Y09-03.
  JS: The type of the optional leaf key would have to allow for the
      special value and we would essentially document the usage of the
      special value in a machine readable way.
  PS: I think Y09-03 is a good compromise.
  MB: I prefer Y09-02 without the update for section 10.
  JS: How does this interact with the different default handling
      modes?
  PS: The server still needs to track internally whether a value
      was explicitly assigned or not.
  MB: I prefer Y09-02 since you do not need to invent a special value.
  MB: But Y09-03 is still better than nothing.
  MB: Y09-03 resolves the issue with the not() function since there is
      always a value for each key leaf.
  
  Action: MB to write-up Y09-03 as discussed above.

  Proposal: Adopt Y09-03.
  
* Y16 module advertisement optimization

  MB: This issue has evolved since we have a separate conformance
      document now and the ietf-yang-library model has been proposed
      to be moved from RESTCONF to NETMOD
  PS: What is the reason to factor out conformance into a separate document?
  MB: Primarily document modularity.
  MB: Y54 suggests a complete removal of conformance announcements
      which I do not agree with. We should send a hash of the module
      capabilities so that a cache can quickly be verified.
  PS: Why do we not do the same for protocol capabilities?
  MB: We can only modify things defined in RFC 6020. Protocol capabilities
      are defined in RFC 6241.

  MB: I would like to move the NETCONF specific text into a separate
      document and this document would have to explain how
      advertisement works.
  PS: How do you get rid of the edit-config rules?
  MB: The idea is to move the rules, not to get rid of them.
  PS: What about the examples? Consider insertions into a list.
  LL: I like the proposal to move protocol specific text into a
      separate document
  KW: This is what we already do with RESTCONF.
  PS: YANG is a data modeling for NETCONF and I prefer to have it stay
      this way.
  PS: I do not mind YANG to be reused. I am concerned if NETCONF
      becomes a distant cousin instead the technology it came from.
  LL: But with RESTCONF things are already done differently.
  PS: It would be bad to have data models that are specific for
      NETCONF or RESTCONF
  MB: I agree that should be avoided.
  MB: Document size may be an issue - RFC 6020 is already fairly long.
  LL: People using RESTCONF do not benefit from the NETCONF specific
      content in RFC 6020.
  JS: The devil may be in the details. It may require to try out
      splitting the document in order to find out whether a split is
      workable.
  MB: I am willing to try but not if it is already clear from the
      beginning that this won't be accepted.
  JS: Please bring the discussion of the document structure to the
      mailing list so that people can comment. Based on the feedback,
      people can decide whether they are willing to prototype such a
      document split.
  
  MB: For the hashing, we would have a separate capability.
  
  Action: MB to add a new solution (Y16-03) that is covering the hash
  idea and the usage of ietf-yang-library. 

  Proposal: Declare Y54 DEAD with a pointer that Y54 got subsumed by
  Y16.
  
* Y18 fix "when" expression context problem

  LL: I added an example to Y18-01 and he believes this is problematic.
  MB: The example is just fine since the description does not talk
      about the order in which when expressions are evaluated.
  MB: The only problem are loops.
  LL: The xpath expressions cannot be evaluated in isolation anymore;
      the problem is that we are not evaluating against a fixed
      document but instead against something where nodes are added
      during the evaluation
  PS: So the question is how do you describe the context in which the
      expression for A is evaluated.
  KW: Is the example not missing mandatory true for leaf B?
  PS: No, B is not mandatory - it has a default and a when statement.
  PS: It is easy to say that the context includes objects that have a
      default value. But there is definitely an order going on, how do
      you describe it?
  MB: It is mostly recursive.
  KW: Call it the evaluation order.
  PS: How do we describe this order?
  LL: It is a dependency order of things appearing in when expressions.
  PS: Any nodes appearing in when expressions must be first evaluated
      before the current expression is evaluated.
  PS: For ../B to make sense, you first have create A.
  PS: If we define the context correctly, perhaps even circular issues
      go away.
  KW: A circular reference cannot be used to a fake context node, it
      has to be to a real one.
  MB: Still, is ../* circular or are fake nodes not considered in that
      case?
  MB: It seems we need to define the evaluation order somehow along
      the lines PS suggested.
  MB: We need to explain how the rest of the context is constructed.
  LL: This problem would not exist if when would only be allowed for
      augments.
  MB: The ordering issue would still have to be spelled out but the
      context node issue goes away.
  LL: Change the issue  name by removing 'node'.

  Action: MB to draft some text concerning the order of when
  expression evaluations.