[netmod] Preliminary Meeting Minutes from Interim Meeting 9/10/2015

[Nadeau Thomas <[e-mail]>]

	These are the preliminary/draft meeting minutes from today’s meeting. 
They will be neatened up once we are sure what they contain is accurate. Please 
comment ASAP if you feel there are any inaccuracies contained therein.

	Thanks to Mahesh Jethanandani ([e-mail]) for taking notes!

	If you were in attendance, and are not listed in the screen capture from WebEx
below, please contact me privately so I make sure you are added. There were others that
came/went that did not make it on my initial screen capture nor were listed on the etherpad.

	—Tom


>> Requirements Discussion have been captured in the e-mail send to the mailing list.
>> Tom: Question - do you agree/disagree with requirements posted on list
>> 
>> Discussing the following requirements: 
>> 	•     
>> 	• 1. Ability to interact with both intended and applied configuration
>> 
>> 	•    a. The ability to ask the operational components of a system
>> 	•        (e.g., line cards) for the configuration that they are currently
>> 	•        using. This is the "applied configuration".
>> 
>> 	•    b. applied configuration is read-only
>> 
>> 	•    c. The data model for the applied configuration is the same as
>> 	•        the data model for the intended configuration (same leaves)
>> 
>> 	•    d. For asynchronous systems, when fully synchronized, the data
>> 	•        in the applied configuration is the same as the data for the
>> 	•        intended configuration.
>> 
>> Tom: who disagrees with #1
>> Lada: Who is requirement 1.b. for. NETCONF client ? The example of being able to change the /proc entry in the Linux kernel.
>> Rob: That is not a good example. Take the example of a flash light. Asking to turn on the light through some other means is not changing applied configuration.
>> 
>>     
>>     
>> Carl: we need a concrete example
>> Lou: applied config = show on the CLI
>> Carl: Lou's example is not the correct interpretation of applied configuration.
>> Carl: A concrete example would help here.
>> Kent: 1.d Is the applied configuraiton = intended configuration. On a sysnchronous system, if during transiition from applied to intended, the system simplified the configuration, would that be acceptable, or does it have to be a carbon copy? Rob confirms - yes.
>> Martin: In the draft, for 1.d, the applied configuration may not be the same as intended configuration. 
>> Rob: For hardware that is synchronized. If the hardware is not present then it is not synchronous.
>> Martin: Will interfaces show up in applied configuration that have not been intended?
>> Call-in User 13: It will show up in applied configuration. Not everything that is applied is intended.
>> Martin: Maybe it is the schema that is the same between intended and applied configuration.
>> Rob: We are at the same point we were in June. 
>> Tom: Do we agree with the requirements or are they minor edits?
>> Lada: The requirements are related to definitions. If the definitions are not clear, the requirements are not clear.
>> Tom: What have we been doing for the last three months? Can we move forward on agreeing on the requirements.
>> Kent: We have consensus on 1 a, b, and c. But not on d.
>> Rob: How can we say we do not have agreement on d.
>> Tom: Is the general sense that d is a requirement is clear. Are the requirements 1 a, b, c, d clear. No negative responses. No disagreement on the requirements.
>> 
>> Tom: Moving to 2. Does anyone disagree with the requirement? 
>> Alex: Will the applied data indistinguishable from dervied state?
>> Rob: In the draft we say that applied data would be retrieved from derived state.
>> Lada: IP address on a interface can be both applied or dervied state. 
>> Rob: The BGP example of hold time has both intended and applied configuration.
>> Christian: The draft says that we can get both in a single operation. 
>> ??: Need more examples for each of the requirements.
>> Tom: No objections. But do need examples.
>> 
>> Tom: Moving to 3. No objections
>> Tom: 3a no objections
>> Tom: 3b no objections
>> 
>> Tom: Moving to 4. No objections to 4, 4a and 4b.
>> Kent: Will add the word state to derived.
>> 
>> Tom: Does anyone disagree that 5 is a duplicate of 3a. No objections.
>> 
>> Tom: Disagree on 6a, b or c. No objections
>> 
>> Tom: Disagree on 7 a, b, c. No objections
>> 
>> Tom: Will be taken to the list where comments will be welcomed within 48 hours.
>> Christian: Can we make a call.
>> Tom: Not here. On the mailing list.
>> 
>> Tom: Moving to solution discussion.
>> Lou: Can the chairs share the slides they have prepared.
>> Kent: Is that there are no questions?
>> Tom: No. It would help to see the comparisons.
>> Kent: Sharing slides.
>> 
>> [Kent to paste his comparison e-mail here]
>> 
>> Christian: Are both the kwatsen and wilton implemented using RPC.
>> Kent: Yes.
>> Christian: Would like to hear from OpenConfig folks on the two suggested solutions.
>> Rob: Would be interested in implementations that do not support a particular datastore 
>> Andy: Instead of changing the schema, add attributes. Client asks for particular attributes. Would be happy with tha solution.
>> Aneesh: In the extreme case, the reply could carry all the extra attributes?
>> Andy: But the schema would have to maintain the extra leaves.
>> Aneesh: Do not want to debate the solution.
>> Andy: Most platforms do not need this. So keeing it as attributes makes it part of the protocol instead of the schema.
>> Aneesh: So is the solution is for the server returning attributes?
>> Aneesh: Like the idea.
>> Benoit: The two suggested solutions. They are based on NETCONF/RESTCONF. Are they using it for other protocols?
>> Aneesh: We are using other protocols. Will share primitives.
>> Benoit: If the solution is for NETCONF/RESTCONF, will it work for other protocols.
>> Rob: If the solution is mappable for NETCONF/RESTCONF, would it be mappable for another protocol.
>> Benoit: YANG is currently not protocol agnostic. Currently, it is tied to NETCONF/RESTCONF.
>> Benoit: If the solution is for NETCONF/RESTCONF, is that acceptable?
>> Rob: No. The solution has to be more general.
>> Christian: Is the intersection of NETCONF/RESTCONF good enough for the other protocols.
>> Andy: YANG cannot be decoupled from NETCONF/RESTCONF without making it Information Modelling Language.
>> 
>> Tom: Need another meeting. Call for consensus on the mailing list.