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

[Robert Wilton <[e-mail]>]

Hi Tom,

Do you know when the follow up meeting will be scheduled for please?

Thanks,
Rob


On 10/09/2015 21:57, Nadeau Thomas wrote:
>
> 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] 
> <mailto:[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.
>
>
>
>
>
> _______________________________________________
> netmod mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/netmod