Minutes of the NETCONF WG session, 26 July 2010
===============================================

Minutes taken by Lada Lhotka and Juergen Schoenwaelder (Many thanks)

The session started at 13:03, blue sheets were circulated.

Note Well, need to accept rules etc IP issues, patent or related issues, should disclose anything pertinent

* Name abbreviations

AB - Andy Bierman
BC - Bob Cole
BW - Bert Wijnen
DH - Dave Harrington
DR - Dan Romascanu
LL - Lada Lhotka
MB - Martin Bjoerklund
ME - Mehmet Ersue
MW - Margaret Wasserman
JS - Juergen Schoenwaelder
PS - Phil Shafer
WH - Wes Hardaker


* Agenda (ME)

no changes

* WG Status (ME)

AB: Network wide configuration Bar BoF at 17:40-19:40 NH Maastricht bar
JS: What's the conclusion WRT moving a part of with-defaults to 4741bis?
BW: The opinions were split about 50:50, and it would require to change the charter, so the chairs decided not to do it.
JS: This was only about a part of the W-D draft, so the charter is not an issue.

* 4742bis (MW)

JS: On the username issue, there is a difference between 'what' and 'how' - do we allow SSH servers to rewrite the authenticated username to foo/bar for the SSH username bar?
WH: As an author of RFC 5592 - we found no other solution. A mechanism for mapping the obtained username to the name that is really used by NETCONF may be needed. The best thing you can do is to say that it is implementation dependent.
MW: I agree with you. We can give feedback to SSH folks that we need something better than this.
AB: There is no way to get the name from OpenSSH 
MW: Identities represented as usernames mean different thing in different OSes - Unix uses (uid,gid), Windows domainname/username.
AB: It's similar in Apache - you get different access depending on where you come from.
MW: We have to figure out what to do. We don't want to grep packets, that would be a violation of protocol layering.
PS: With RADIUS it's even more complicated as the server doesn't see the credentials.
MW: Yes, we probably can't do any better than stating that the username and how it is obtained is implementation dependent.
WH: SSH was selected because operators understand it and already have authentication data.
BW: So does the proposed text address Jürgens comments?
AB: In the NACM draft we have some text about the variable "user".
BW: Hum: WG consensus is to use the proposed text. MW will post an updated ID where the derivation of the username from SSH is implementation-dependant.

* 4741bis (MB)

slide 2:
PS: Namespace wildcarding can lead to unexpected results. Did you change operations in a non-backwards compatible way?
MB: Yes, client should normally use filters with appropriate namespaces. The wilcarding is a flexible mechanism but you have to know what you are doing. Even with 4741, clients must be prepared to deal with multiple namespaces in responses 
PS: This makes applications fragile, e.g. when the data model is extended and the filter returns unexpected data.
MB: Clients have to be prepared to handle unknown data anyway.

slide 3:
PS: The change to copy-config is not backwards compatible.
MB: Correct, it's one of base-1.1 changes.

slide 5:
WH: We require a reliable transport. The draft has to say what happens in case of a parsing error. E.g. say that you skip to the next message (does not always work) or preferred to state that the connection is closed. The session probably shouldn't continue because we don't know the state the config data is in.
AB: In my implementation the XML parser never sees any EOM markers and a parsing error generates an RPC error and the session continues. If we move to dropping the session, we have to specify conditions under which the session is to be dropped. So for me, I do generally not care to drop a session.
WH: I agree, generic operation errors are not supposed to be handled in this way. One option is if the XML is not well-formed, close the connection.
Hum: WG consensus was on dropping the session. 
Hum: Room in favour of doing a WG last call on the next revision.
BW: We need one more revision specifying when the session will be dropped.

* Access Control (AB)

slide 6:
LL: What is actually the exact scope for module rules? Do they apply to nodes that augment the module tree from outside?
AB: No, it doesn't apply to them, they have a different namespace.
BW: People had time to send in requirements and/or propose alternative solutions. Nothing appeared.
JS: I am surprised that the document talks about authentication. This should be handled separately. It even specifies orders how a user is authenticated but we just agreed that 4742bis does whatever the system does.
WH: The proposed charter update only addresses requirements. Is this just a requirements document?
AB: No, work on a solution is also being proposed.
BW: We don't want to get bogged down on requirements as it happened in the past. It is a document listing requirements and the solution.
WH: A phased approach may not work too well with access control (you can't leave out something essential). With any AC model, you cannot add or throw out things randomly. It is not acceptable to say that we first make it a little secure and more secure later.
BW (asking Dan Romascanu about his opinion on the proposed charter text).
DR: Charter text is good enough for charter inclusion from the AD point of view.
BW: Hum: WG consensus supports the new charter text.
BW: Hum: WG consensus to take -02 revision as the starting point.
DH: Does the "preconfigured subset" mentioned in the charter text mean this subset is preconfigured by an operator?
AB: Yes.
DH: This should be mentioned in the text.

* System Monitoring (AB)

slide 3:
WH: What does "system" mean? Is it the SNMP system name or NETCONF server id?
AB: This is always difficult to determine.
Peter Lothberg: What is "system current time"? Whose data and time is this?
AB: It's the server notion of local time. The server's known data and time.

slide 4:
MB: We need the "system" module.

slide 6:
AB: Discussion how to deal with errors in startup configs
PS: You are mixing three things. [LL: I didn't get what the things were].
WH: I think it's a good starting point. Just be consistent in using either system reboot time or SNMP restart time.
DR: I agree with Wes. SNMP information is not the same as NETCONF information.
PS: It is an implementation choice whether a box boots up with an erroneous startup configuration or not.
DR: Do you want to define notifications in the same document?
AB: Probably yes, the notifications really apply to the netconf server and the distinction between system and server needs to be more clear.
BW: Call for consensus on doing this work in the NETCONF WG
JS: Where should this work be done, how does it relate to NETMOD rechartering? I object, it is strange to do data modeling in this WG. Is there any strategy in this respect?
DR: No, there is no particular strategy. I think most of modeling should be done in other WGs, but this specific module is appropriate to be developed in the NETCONF WG.
JS: For example the "uname" stuff is not NETCONF specific.
DR: The other option is to charter a new WG. This will take longer.
BW: If our very first module is a mix of NETCONF and other info, it's not the best start.
BW: Hum: WG consensus is to do it here.
BW: Hum: WG consensus is to start with the -00 revision.

* Verify and Transaction Test (BC)

AB: Two comments:
1. We should be able to have some standard verification tests.
2. Expansion of the transaction module requires a WG on its own.
The connectivity tests may require a complete WG to work out. Doubts that this working group has the resources to work out all the connectivity tests.
PS: The management system has a more global view and can decided which tests to run. Decoupling of the two topics from the previous draft does not make the whole system simpler.
BC: It would be a lot easier if the tests are preloaded and the pre-configuration of the devices would be simpler / more common..
PS: Criteria for test success or failure depends on operators network and operational requirements and not on the device.
BC: Yes, and we provide a common interface for specifying these criteria and to configure the tests.
PS: I see more value in having the underlying tests available instead of a high-level common interface.
AB: This might be a slippery slope bringing us to service level agreements; I am interested in pushing more high-level configuration to the box. Being able to tell the box "Make sure you are always reachable." is useful. So there is some value in the standard interface.
BW: As this is not a chartered item please submit early before deadline and initiate discussion on the maillist.

* Open Mike

Nobody wants to sing a song, even Bert ;)