Minutes of the NETCONF WG Session November 15, 2011, 1710-1810
================================================================

Many thanks to the minute taker Lada Lhotka and jabber scribe Russ Mundy.

Discussion of AD review of the ACM draft 

Comments from AD review, Dan's mail from Nov 7
Comment T1:
- Juergen: There is something in the RADIUS definition taht
   gives you groups.
- Dan: Then a reference is needed.
- Martin: We do have a reference to RFC 5607.
- Dan: Juergen referred to specific policy extensions.
- Juergen: I think they are cntained in 5607.

Comment T2:
- Dan: Text has to say that disabling the ACM could be a
   security hole.
- Andy: In order to do that you need to be a superuser. But we
   can make it more clear. 

Comment E2:
- Andy: Yes, the paragraph is out of order, we have to find a
   better place for it.
- Bert: After the last revision, two days will be left for
   last-minute comments.

Discussion of AD review of the system-notifications draft, Dan's mail from Nov 7
Comment T1:
- Andy: A NETCONF session must be able to assign session number
   even to a non-NETCONF session.
- Dan: The text should say that info about non-NC sessions can
   be provided for debugging purposes etc.

NETCONF over TLS, 5539bis  (M. Badra, presented by Juergen)
- Andy: Both sides have to advertise 1.0 or 1.1, that shouldn't be left out.
- Carsten Bormann: I am wondering about deriving user identity
   from TLS. What if a user has multiple keys? The name is just
   the name of the key.
- Juergen: This is something to look at.
- Bert: Carsten, could you send your question to the mailing list?
- Mehmet: There are 5 algorithms for extracting name. Why is it
   necessary to implement all of them?
- Juergen: It is the client that sends the certificate, the
   server must be able to handle any of them, whatever they contain.
- Carsten: Say I preload a new pre-shared key to my machines every
   month. How can I make sure that both keys are valid for some period?
- Mehmet: How normative are the instructions in descriptions?
  They contain MUST, SHOULD etc.
- Juergen: They are normative if used correctly.
- Mehmet (as contributor): I think the draft is needed.
- Andy: This is a little off-topic but isn't it time to get rid
  of the transports that are not used (BEEP)?
- Juergen: Once 1.1 obsoleted 1.0, BEEP & SOAP don't work
   anymore as they don't support user names. So either people
   update them or they cannot be used.
- Bert: If we want to make them historic, we should do it explicitly.
- Dan: From what I understand from Juergen, 1.1 obsoletes the
   old transport, so I consider it a side effect that doesn't
   need rechartering.
- Bert asks for hums. Some support for obsoleting the transport,
   nobody against.
- Mehmet: We have to ask this question on the mailing list.
- Dan: Definitely.
- Andy: BEEP & SOAP say they only work with 1.0, so we needn't
  do anything.
- Bert: The only question is whether we want to explicitly label
   them as obsolete.
- Dan: We should avoid letting people make mistakes.

NETCONF over WebSockets (Tomoyuki Iijima)
- Bert: Does the transport also provide the user name so that we
   can do access control?
- Tomoyuki: I will check.
- Martin: This is more interesting than NETCONF over TLS.
- Dan supports Martin's view.
- Andy: I am not clear about use cases. I implemented something
   similar, it doesn't send NETCONF but objects that the browser
   API expects.
- Peter Lothberg: I want to remove people sitting behind the
   screens and manually configuring boxes. Network elements should
   talk to computers instead of human user. Is this going towards
   this goal or against?
- Martin: There are smaller networks that are operated by humans.
- Stewart Bryant (?): This will allow people to access the technology.
- Juergen: Should we have REST-based interface rather than WebSockets?
- Martin: REST by itself cannot handle notifications.
- Bert: Martin, do you have any implementation of REST so that we
   can compare it to WebSockets?
- Martin: I wrote a document, not implementation, so far I had no
   plans to publish it.

Changes to handling of submodules (Juergen)
- Peter: We need to be sure about which version is used.
- Lada: Submodules are fine for a coordinated group of developers 
  that can make sure that module's revision is increased every
  time any submodule changes. I also don't understand the fear of
  having many namespaces.
- Andy: Submodules don't help at all.
- Juergen: Can you explain?
- Andy: The overall version changes constantly.
- Martin: We should fix it in YANG rather than in NETCONF.
- Bert: How can we fix it in YANG?
- Martin: The text that specifies module-related capabilities is in RFC 6020.
- Juergen: I will take it to the mailing list.