Sharon's Notes from Netconf IETF 59

["Sharon Chisholm" <schishol@nortelnetworks.com>]

[Note these are not the meeting minutes. These need to be combined with
Chris Elliot's notes and sanitized by the working group chair]

IETF 59 Netconf (Wednesday)
----------------------------

Agenda
  - status reports on netconf related activities
  - document updates
  - resolution of hottest issues
  - conformance issues

----
Status Report on Netconf Related Activities
----

Simon's meeting at RIPE (http://www.ripe.net)

 - Simon presented information about the Netconf effort at the January RIPE
meeting. RIPE is an operator meeting and this presentation was an attempt to
ensure the operators were involved in the development of Netconf.

  - Simon's presentation was reasonably well attended with feedback coming
more from a couple of people rather than the audience as a whole. He
surveyed the room at found it was only ISPs - there was no representation
from Enterprise.

- In discussions about operational practices in this venue, Simon didn't
find anyone who was using elaborate tools for provisioning or configuration.
Almost everyone used scripts and used Perl. There were some concerns raised
that Netconf needs hooks into scripting languages such as Perl. Other
concerns raised include the ability to deal with huge configurations and
large access lists. There were also concerns about locking and overlapping
operations. One specific feedback was present issue of multiple transports
and the fact that we have not yet done mandatory selection. After meeting
someone came up to Simon and said SSH is the no brainier. Operators prefer
this.

Eliot's Presentation at NANOG (http://www.nanog.org)

- While Eliot is not currently going through slides, he will send the slides
he presented at NANOG to Andy for inclusion in the minutes.

- Eliot gave a brief presentation with a primary message being that Netconf
has been cut down to focus on the basic features that need to be delivered. 

- Eliot posed two questions to the operations: The first question was do you
have interest in managing services and devices that are behind NATS or
firewalls and do you therefore care are about the direction you connection
from. To his surprise, operators were not particularly in these issues. The
second question was the issue of which port to use for SSH - port 22 versus
another port. Consensus among the operators was that we should use another
port other than 22. They didn't care about access list issues, but rather
just wanted another port. 

There was discussion within the room that indicated that that trying to
manage through a firewall was an issue that does come up in the field, as
shows up as calls to Technical support. It was also noted that not running
SSH on port 22 may cause problems in getting through NATs and Firewalls.


Sharon's Summary of Netconf Data Models Discussions
(http://standards.nortelnetworks.com/netconf)

[Editor's note: As the presenter, my duty as minute taker was neglected]

It was noted that the Data Modeling discussion is not just about the data
models, but also includes other issues such as conformance to standards.

------
Document Updates
------

Rob Enns presented the changes in the latest version of the Netconf protocol
draft

Q - Why do we want to remove the notifications from the protocol, since
there is interest in this ability
A - Given the focus of Netconf on configuration and the fact that most of
operators we spoke to currently are using SNMP or syslog to get their
configuration related notifications and that many of the proposed sub-stream
solutions for Netconf can't easily support Notifications, this feature did
not meet a cost/benefit evaluation for inclusion in the initial version of
the Netconf protocol. The one potential differentiator would be
notifications that were specific to a particular Netconf session, as appose
to the device in general. It can always be added at a later date. 
 
Chris Lonvick - We will be doing work in the Syslog WG related to this area,
so if the Netconf working group doesn't want to take this on, we could
potentially do it in syslog.
 
Randy Presuhn - Both the previous speakers have raised the issue of the data
model behind the notifications regardless of whether reliable syslog is
bundled with netconf or a standalone netconf. It would be good if concerns
along those lines was brought to the data model mailing list that Sharon
mentioned.

Andy - Good point. The data model work can certainly look at Notifications

--
Netconf over SOAP Document

The editors of the Netconf over SOAP Document were not present in the
meeting.

Andy - We must understand what attribute can't be ignored. That is the only
one that we would require for compliance. This raises some issues related to
using http as a sub stream.

--
Netconf over BEEP Document

Eliot - The beep draft needs to be updated based on Rob's updates to the
protocol specification. I didn't get a chance to do that before the IETF,
but I'll do it with the next 2-4 weeks. I would be nice to receive comments
on the beep draft between now and then. 

--
Netconf over SSH Document

There was discussion about the SSH draft and the fact that it now need to
remove the Notifications.

-----
Resolution of Hottest Issues
-----

The issues list is available on a web page
(http://www.nextbeacon.com/netconf/).

1.4) Dual role implementations 

A single host capable of being both a manager and an agent, but over a
single connection you can only be one.

1.5) Validation conformance

It needs to be clarified that the syntax check is the minimum. Future work
on the data model will handle requirements for referential integrity, both
within an object and across objects.

Randy - I have a comment on second sub bullet. I would request hat the
editors be careful with the wording as what Andy verbally communicated is
now what is written in the slides. 

Andy - I just meant a syntax check. We should just take out the second
bullet

Randy - Just make sure the language in the RFC does not prevent people from
doing a serious implementation

Andy - To me a syntax check means the same as XSD validation. I may not want
to make it that strong of a requirement. The new revision is that "at
maximum" be removed ...

<Consensus: no objection to removing the maximum from the notes>

5.1) End of message directive

This is for SSH mapping only. There has been lots of discussion on the list
lately. The concern is there should be a netconf specific framework for SSH,
but it can't be CDATA since there are security issues. Not sure if <?eom?>
was the final answer. It was suggested as being a string.

Rob - I believe the design team agreed that this would be what was used ...

<Consensus: no objections to proposed change >

5.2) SSH port assignment

Proposed consensus matches what Eliot said - we want to get new port
assignment. We will tell vendors that it SHOULD be configurable, We are not
going to do any work on how to configure this.

7.1) Need to compile a list of criteria

We originally said we would wait for experience before selecting a mandatory
transport, but operators are saying using SSH. We proposed consensus is SSH.
Note that it didn't appear there were large implementation differences
between the options.

Margaret - If the operators prefer SSH and we make it mandatory they will
get it. If the vendors prefer something else they can also do that as well.

<Consensus: no objection>

7.1a) Mandatory-to-implement choice

The initial proposal is:
  mandatory SSH
  should beep
  may support soap
 
Eliot - With respect to 'should support beep', I think the agent should
support beep, but I'm not sure if the manager should. This is too much to
ask for simple, specific task tools.  

Sharon - So you have two ends of a pipe and only one end speaks Beep?

Margaret - I agree with the agent should be may. If I write a real manager
application .. it is going to have know the specific machines, so I will
know if it supports BEEP.

Bert - First it should be agent implementation MUST implement. If not
enabled by the deployment, it is still there. I think mandatory SSH is there
it needs to be on both sides. Get every manager to talk to every agent ..

Andy - Manger and agent MUST do SSH. Agent should do beep? 

Randy- Look at RFC2119 and the appropriate use of MUST. If you didn't do it
this way there would be no interoperability then it is a MUST.  The should
is suppose to be used if you don't support it, something may not go well.
One need a really good reason for not doing it. I don't think we have
fulfilled this for BEEP. I therefore argue it should be a MAY.

Andy - Note that we had discussed initiating the session from the device.

Randy- That requirement seems to be fading.

Randy - Manger and agents MAY implement BEEP or SOAP

Dave - I agree with what Randy said 

Eliot - Even though I went to NANOG and reported back what I said, yeah the
MUST can be SSH, but I think the firewall issue is going to come back to
bite us. We will need the implementation of BEEP in the agent to get around
this

Andy - Really much more about a large number of small device than the other
way around

Bert - When I read that the agent 'MAY', it sounds odd. It is usually used
for something that you were not meant to do but you can. 

Andy - So it should say MAY for agent.

Randy - To address the concern about directionality in some environments,
this might be the best way to do it - make it non-normative ...

Sharon - Will this conformance information be in the protocol ID? It seems
we may want to rev it independent of the protocol.

Andy - We could put it in the applicability document.

Andy - Before we leave this issue, is this our consensus?

<Consensus: Yes, SSH MUST; Beep and SOAP MAY>

8.1) <get-all> (Operation set)

The proposal is to leave protocol set as is. We don't redo in more object
oriented way.

Ted Stoddard - I spoke up on the issue. get-all was a dump and there no
filtering capabilities. At least get-state provides a filter. get-all could
be a huge amount of data .

Andy - You can specify a start point in your data model. There is a scoping
mechanism for picking a subtree in the containment model. You are right
there isn't a filter for just getting state. operators want to be able to
just get configuration, though.

Ted - The history of this was get-state. Ff this is get-state I have no
issue. If it is get-all I have issue. get-state was better

Andy - There were issues with get-state since it required the implementation
to pull out state information. I don't want to make two separate requests to
get operator and admin status. The clincher for this decision was that the
operator requirement was not to have a special command to get state, but
rather to get configuration. I understand your concern that we don't have a
command with filtering, but we are leaving that for future work. I don't
think meta data belongs here. 

Ted - But it will be a large volumes of information

Andy - This is all about filtering which is very data model specific. We
could just learn instances for example.

Ted - The fact that those things are not on the table, that means that this
is broken.

Andy - Broken is too strong. If large box with lots of interfaces, it should
be able to stream it. This is an outlier case. Most of the times the box's
resources match the sort of retrieval it is being asked to do.

Ted - Instances by name ... limits on the size of the return. We need to
make this more controllable. This stuff should be discussed on the list.

Andy - Sense of the room?

<consensus that something should be done here .. look into it further>

Andy - Two really related proposals: specifying the number of nest levels
deep or just returning the instances. The latter is probably cleaner as the
level filtering might not always help.

Randy - The other point is that the kind of data models that vendors will
develop will be influenced by the type of protocol we come up with. For
example, logging related to resources ... if you don't have control over
what instances are returned you would want to ensure the logs are elsewhere
so you don't bump into them.

Andy - We shall take it to the list. I know the Cisco developers did the
work with just being able to return the instances.  We will capture that.

<retrieve instances is the preferred choices?>

Andy - The full blown solution that was dropped would be to use XPATH. We
still may end up going there. It would be for future work ...

8.1a) <edit-state>

RPC wrapper ... Rob took out the text about exec commands, but he intended
to expand that section but saying something about 'netconf can support exec
commands, but we are not putting them in at the moment' didn't seem quite
right.

Andy - Proposal is to defer this for future work ... any comments?

<Consensus: no objections>

10.3.2) Confirmed commit

The proposal is to remove confirmed commit feature.

q - If we are removing this at this time, is it planned to pick this up and
to finish rollback so that it can be completed. Can we poll operators to
find out? What is the effort to put it back? If we ask operators, we may
find out this is important.

Andy - This is easier on a application development, this kind of feature -
I want this blob of configuration to either all take or non of it to take.
If it is a list of 10 commands and only 7 worked, not 10 from what I've
heard from customers that this is not what they want.

q - What is the impact of not completing rollback now?

Andy - We've heard that if people don't use locking I can hose things. They
can commit someone else's changes if they rolled back. They don't want to
roll back all changes. My answer is that what is locking is for. I had
originally said there would be specific constraints on rollback. Rob do you
have ay comments?

q - I think this is an important feature and want it.

Rob - I don't have any objection. We were concerned as to what rollback
meant when you had a candidate configuration and when you didn't. Rather
than dig it up, Phil suggested getting rid of it. If we think we can get it
to work then we should take it to the mailing list.

Andy - Originally we were thinking of a full blown rollback, which was  seen
as too complicated. I think the concern is that there is a slight mismatch
between the candidate and running.

Rob - I agree that operators like this a lot and it would be a good selling
point for netconf 1.0

Andy - Ok. We might have been too zealous when removing things.

<Consensus: take back to list and see if we can come up with something
reasonable>

11.1.2) URI versus URN

No one had read RFC3553

Andy - Anyone have comments? Familiar with RFC3553

Andy - In a tool like XML spy it will try to retrieve the schema like it is
a URL (from a URI). This is convenient.

Rob - Juergen says we should just use URNs.

Scott Hollenbeck - RFC3688 describes  registering XML parameters

Eliot - I don't see any problems with this. There are issue with URNs - will
the name survive forever? So longs as they do I'm comfortable with this.

11.2.3) Rollback

already covered 

12.6) <rpc-error>

This is the biggest part of the document that is still TBD 

Andy - I had sent out an email that indicated that I would like a small set
of constrain things as appose to something open ended. We can't check what a
string is without standard semantics. We can't have any automated response
to error codes that way and that is the end goal.

Andy - We need layered layers: protocol and application or data model
specific error. We should have support for that. We also need to be able to
include multiple in one reply if more than one error. How do I associate
this chunk of configuration error with this particular rpc error is another
issue. The document suggests using edit-path. I don't think there is an
example. It needs to provides a hint or you could just reproduce the
containment hierarchy and stuff the error in where it goes.

Proposed consensus is to clarify document on the error codes

<Consensus: no objection>

Proposed consensus is to add hook for data model errors. Any element outside
the netconf namespace can go there. 

Andy - This also solves problem of being able to return the lock of a failed
session. We could add additional elements in this container - set of
protocol errors and container mechanism for additional errors.

Andy - Comment on proposal?

<no comments ... need text>

12.6.1) Error codes

Andy has been looking at Alarm MIB for IANAItuProbableCause and wonders why
we would want to reinvent every error code that could happen when we could
just leverage this?

Andy - I had previously told the design team to come up with a proposal

Gregory Lev. - There was some work done in the op sec group on standardizing
logging of security. Based on that experience, if you try to do it in this
document you will drown. There is too much to do.

Andy - No ... this is just the error code and they are just for that
request.

Randy - Following up on that, I think there are three kinds of error codes.
The first level is at the level of the RPC error itself - netconf protocol
level that will be a very small set of errors. The second level will be an
elaboration that is specific to the data model which will be specified as
part of the data model. The value of this is out of scope of the protocol
work. The third level is an implementation specific problem that has been
noted - during validation an referential constraint was violated - this
would be valuable to communicate to the operator.

Andy - That is what I was proposing - in the protocol putting in the
container. I am  then just throwing out the idea that this IANA probable
cause worth putting out there. I agree it could balloon

Randy - In my view, the IANA probable cause might be useful for data model
or application level. We don't need to nail them down in this working group.
We nail down the RPC level and probable cause may not be the best choice for
those.

Andy - Hearing a consensus that we should stick to defining our stuff with a
place holder for the rest

<Consensus: agreed>

13.3) <edit-configuration>

<no objection to operation set>

Andy - The text that says you can't mix different values in an operations
request sounds like a new CLR (A rule that either adds no value or gets in
the way, but that we are stuck with for historical reasons). I think we will
probable regret that later.

Sharon - We should then either remove it or make the restriction
discoverable view a #capability

Andy - I don't want another capability

Rob - If we do take this up then we need to look at all the evil things that
people can do if they mix things up and come up with CLR to handle those.
Someone is going to write a conformance tool for example.
 
Rob - Probably going to be more restrictive ...agree with you.

Andy - If taking it out means the agent MUST support arbitrary combinations
then I don't want it. We need to word smith something

Randy- We need to consider management applications. Due to complexity
limitations, without any capability and therefore the ability to know in
advance, then the prudent management application is not going to take
advantage of this feature.

Andy - The use case that I came up with for this is that I want to replace
this blob, but there is another blob that I want to delete and these are
against different instances.

Randy - Permitting the agent to beg off on these things due to complexity
isn't good. The prudent application will break things down into the specific
requests since that will always work.

Andy - We need to try to come up with some better text and propose it on the
mailing list. Perhaps for the same instance information it must be the same
operation.

Eliot - We need more text on the mailing list on this. I'm not sure I fully
grasp the issue.

Andy - Yes, it becomes important with respect to rollback.

13.12.3) Error handling for <lock>

<no comments>

---- end of slides----

Any other issues?

Eliot - One comment: I still owe Rob some text on locking. Plus people with
less privileges with respect to locking. This all goes into the security
considerations section.

----
Next step
----

It was agreed that the working group did not need to meet on Thursday.
finish up documents my next I

It was suggested that we want to wrap things up and go to last call around
the time of the next meeting.

Andy would like to see implementations get started and to plan for a netconf
bakeoff event - hopefully in 3-6 months for the fundamental features.

Sharon Chisholm
Portfolio Integration
Nortel Networks
Ottawa, Canada

--
to unsubscribe send a message to netconf-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/netconf/>