Minutes of the NETCONF WG session, November 9, 2009 =================================================== Co-Chairs: Bert Wijnen, Mehmet Ersue AD: Dan Romascanu Minute takers: Lada Lhotka, Wes Hardaker Jabber scribe: Dan Romascanu The session started at 15:25, blue sheets were circulated. Agenda bashing - no objections/additions. * WG Status (Mehmet Ersue) - partial lock draft now in RFC editor queue - monitoring draft: WGLC ended on 2 November - RFC 4741bis still under intensive discussion, issues recorded in the tracker are being resolved - with-defauts: may be ready for AD review * WG status on not-yet-chartered (Mehmet): - RFC 4742bis: some errata have been collected, editors solicited - Robust config management: the draft hasn't been updated - Dan Romascanu: There was some discussion about the draft with input from Martin and Phil, prototyping work has started; the authors will continue and prepare new version for consideration. * Monitoring Scheme (Balazs presenting for Mark Scott) - Revision -10 planned for end November - Mehmet: One of the issues is: Should the YANG module be as complete as possible? - Balazs: Martin is on Jabber, we should ask him - Martin (on Jabber): Yes, we should move the text to the YANG module. - Mehmet: There were also some comments from Phil that haven't been addressed. - Dan channeling Martin: yes we should move the text into Yang * RFC4741bis status (Andy): - 007 return from xpath filter - There is no text that says the nodes are returned; no ordering required - Balazs: I think the issue is whether the keys should be returned or not - Andy: Ok, I think that should be the case otherwise there is no way to tell them apart. - Bert: you (Andy) and Martin should should propose text and send to mailing list for consensus check - Martin via jabber: yes I believe the keys should be included. Note it's also different from subtree filtering. - Martin: different than how subtree filtering works - hum taken and general favor to include keys when returned - Andy: I implement subtrees the same way. It returns keys when keys are missing and it knows it's a list - Martin: We should clarify subtree filtering to allow extra nodes to be included. - Bert: proposals for complete text needed; please sent to the list. - 011: duplicate edit-config modifications - Andy: the issue is should this be an error or? How does the server deal with the same object appearing more than once - Martin proposes result is implementation specific - Lada: Shouldn't be implementation specific but rather an error raised by the schema validation subsystem. - Wes This is a conflict between NETCONF and NETMOD. From NETMOD POV this is an error, for NETCONF it's OK. - Balazs: there are other protocols that allow this - Andy: but the example is a leaf - Martin: I object to detecting an error. - Ladislav: should be the schema that validates it - Bert: schema = data model or protocol? - Ladislav: data model - Bert: Wes, this matches with what you said? - Wes: yes, I think we are all in agreement - NETMOD should detect an error. - Andy: Server may create two leafs in candidate and not detect it until commit. Should the server detect this as an error? - Wes: it's still a netmod problem. 4741 should already have the text - Martin: This shouldn't be allowed. - Bert: so we should double check that the generic "operations can return an error" and ensure it's there. Specific checks for errors like this is a data model specific problem to detect and figure out the exact error that should be returned. - Hum taken: many for this, no against - Bert: can we get Andy/Martin to say they agree - Andy: we should take the discussion to netmod. I'm not sure the error is there in netmod either. - Bert: from the protocol point of view, this isn't a protocol problem and that's the consensus we're trying to check. - 017: new reference figure - Andy: slide just suggests new diagram - Wes: Should it be just "Transport" and not "Secure Transport" since why limit yourself architecturally? But in the end I don't care enough in total - Bert: If the enivronment is secure, then the transport is secure. - Ladislav: I sort of agree with Wes. Security is relative, ranging from no to absolute security and the example protocols differ in the security level they provide. - Martin: the bigger change is rpc -> messages - Agreement that it is the bigger change, but no-one has a problem with it. Rough humming consensus on going for "Secure Transport". - Jurgen: having a secure transport will matter when we get to access control. - Bert: personally I like the secure transport things - 4741 text says "using a secure connection oriented session" - hum taken; maybe slightly leaning toward changing - Mehmet: we may need to change the text if we *don't* change - Balazs: there is a bunch of text in 4741 that isn't in official MUST/SHOULD/MAY text and those should be cleaned up. - 018: Lock and Commit - Andy: this was discussed on the mailing list; some implementations did have a lock prevent a commit and others did not. I myself don't know which is better. Issue is which blocks a commit operation? - Bert: It sounds like we need a clarification but what should it be? - Balazs: The global lock already has two side effects this will add another so I object to it. - Wes: Does this mean that if user A holds the lock on candidate, user B is not allowed to commit? - Andy: That's another issue. - Martin: Yes, user A keeps lock, user B cannot commit. But I am not sure I like it. Phil does. - Bert: no consensus at the moment; someone should write it up on the mailing list - 004: error-severity - Bert: Who wants to remove warnings? We need a proposal. - Andy: warnings aren't used anywhere, so how can you ever return one? We don't have anything that should return it. A warning can not be returned with because of the way the XSD is written. Ending a warning will actually confuse an application. - Wes: it'd be useful for netmod more likely. NETMOD could make a good use of warning, e.g. in the case of duplicate leafs. - Ladislav: would it be ok to fix the XSD and just allow it but not do anything else? Would it be an option to pack a warning together with ? - Andy: I'd rather leave it the way it works now. I don't see the benefit to having an application have to search through the ok tag for rpc-error fields. - Andy: This would break clients. Supporters should suggest something. Wes could propose a change - Wes: not gonna do it - David P: Maybe we should wait for a real case before fixing it. - 014: - Andy: [note taker couldn't hear Andy] - Martin: error-app-tag could be used for capability-changed, but it was supposed to be reserved for applications. Maybe I and Andy can send a proposal. - Bert: No consensus; proposals needed to mailing list. - 013: confirmed commit - Andy is not in favor - First issue: do we agree about the problem. The session must stay up. - Balazs: we have more than one problem. If the session is dropped for whatever reason, someone still may want to commit later. I like the proposal but we should use user ID rather than session ID for identifying the commiter. - Martin: current implementations behave differently - Bert: then the implementations must differ if Martin and Andy disagree. - Martin: there is no user id - Balazs: But the assumption is that all sessions SHOULD be authenticated, so user identity should be known. - Martin: It can also be accomplished through client certificates. - Bert: hums indicate general agreement to allow other sessions to explicitly to confirm - Andy: not in favor of changing to session to user based locks. - Bert; bring proposal to list; Martin is in favor so he should write the proposal. - slide 10: Other issues? - Bert: Lack of time, other issues should be discussed in ML. * "with-defaults" capabilities in NETCONF - Martin: The capability should not be mandatory. - Balazs: thought it was simple but there has been a lot of discussion. - most devices will be adapted devices, not from scratch - Balazs talks to slides - Bert: I think we posted to the mailing list that we should gather together people from netconf/netmod to solve the problem. This working group would need to define if the capability should be a SHOULD or a MUST. - Bert: does the room think that with-defaults should be a mandatory capability? Rough humming consensus on saying that servers SHOULD implement the capability. - Hum: split for MUST? - Martin: not sure what SHOULD would mean? - Bert: it means if you don't implement it you have to justify why you're not implementing it. - Bert: would anyone object to a SHOULD? (none) - Ok, Bert: Proposal that with-defaults capability SHOULD be implemented will go to the ML. Should it then go to 4741bis? - Bert: Next question: - if with-defaults is supported, is report-all mandatory? - No objections - Bert: no one is speaking, so I read consensus that we want to make report-all be a MUST implement (to be verified in ML). - should basic mode be configurable? - Bert: no discussion; make complete proposal to list - Shall we make explicit mandatory? - Balazs: no (loudly) - Martin: don't make it mandatory - Should we make 3 features/capabilities instead of one? - Balazs: no, it's simple. - no comments; nothing will happen - Balazs: I prefer one capability. - Martin: I agree with Balazs. - Andy: One capability, not three. - Bert: consensus: we want what's in the document right now. Double check consensus on list. - It would be more correct to speak of operations instead of rpcs - Balazs; I see that, but other documents are written the other ways. - Bert: if we do it then we should do it in 4741bis too - Bert: personal opinion is to leave as is - Hum: leave as is (none opposed), RPCs are used in other documents. - Should we wait for YANG and 4741bis to make YANG mandatory? - Balazs: it would be nice, but it might take a long time - Mehmet: We had inconsistencies in monitoring draft. If we don't have similar issues here as a contributor I am in favor of pushing the draft as it is. - Balazs: no - Balazs: my other problem is that if we want to make a formal description then we have to wait for both 4741bis and yang and 4741bis may take a long time - Andy: I do not object to publishing asap with xsd and not yang * 4742bis (Bert): - issues: - errata via RFC editor approved now - xml start directive with ssh - SSH-transport for notifications? - Bert: Are there any other issues? - Balazs: There is also the problem of terminating sequence "]]>]]>". - Lada: It was acknowledged as a problem but the consensus was to leave it as it is because any change would break clients and the potential risk is not that high. - Bert: So it's not an open issue anymore. - Bert: - We need editors. Margaret Wasserman would be willing - Andy: RFC 4742 should be updated if the authors are willing to do it. - hum: should we try to get it out at the same time? - "shy hum"