Subject: RE: comments on draft-ietf-netconf-notification-01.txt

From: "Sharon Chisholm" <[email-masked]>
Date: Wed, 3 May 2006 08:03:41 -0400

hi

Thanks for the review ....

<Andy>
  - The use of special RPCs, named profiles, and a read-only data model
    goes against the core concept of netconf -- use the standard
operations
    to manipulate standard read-write data models.  The convoluted
manner
    in which a traditional notification generation application would be
    realized would win a Rube Goldberg Machine Contest.
</Andy>

The subscription command is easier then other 'traditional' models for
the person doing the subscribing. We have modified the named profiles to
be a persistent set of information related to subscriptions for those
who are more interested in that approach. I'm hoping by 'traditional
notification generator' that you don't mean you wish to duplicate an
SNMP notification generator in Netconf. That model is one that we should
learn from and move on.

<Andy strongly objecting to multiple subscriptions per session>

It seems more work to me to preclude it then allow it. There are
advantages to being able to organize two different sets of filters into
two different subscriptions. 

<Andy>
  - Event classes

    I strongly object to this document defining the mandatory set of
    event classifications.  This document should simply define a
    field that contains a constrained string, which can be used for
    filtering purposes.  The list still contains enumerations such as
    'metrics' and 'heartbeat' which were supposed to be removed.
    There are under-specified semantics and requirements for many
    of these classifications.

    The actual set of standard events is a modeling problem, and is
    out of scope in this WG.

</Andy>

I strong support the inclusion of event classes in the document. I
thought we had agreed we had consensus that this was useful and should
be included? It lets the consumer of the message know what the content
will be and enables the receiver to route the notification to the
appropriate consumers. It is very useful and comparable in data model
bleed to candidate and running configuration in the base protocol work.

The idea here it to only specify the class and defer the content of the
message to the datamodel. 

We still have the open discussion on what the initial set of values is
and how they will be extended. There was discussion about a more
URI-based extension instead of an enumerated list, but as was discussed,
there are some serious disadvantages to this approach. This is similar
to the enumerated list versus rowPointer debate we always had in SNMP.
One-stop-shopping of enumerated lists provide much more ease of use and
predictability then open-ended where-can-I-find-all-the-values things
like URIs. URIs are good for big things like protocol operations and
Schema namespace, but not for everything. Either way, putting the list
in IANA seems reasonable.
--------------------------------------

<Andy>
page 4:

   "discusses implications for the mapping of application protocols"

Is this document doing to define the normative procedures
for supporting notifications on each transport?  I think
this would be better than generating 4 RFCs instead of 1,
but the WG needs to decide where the normative transport-specific text
will be located.
</Andy>

The text is more there because it needs to be somewhere. I like the idea
of updating the existing three transport documents (once they get
published) then creating separate ones. 

<Andy>
----------------

page 4:

NETCONF[NETCONF] --> NETCONF [NETCONF-PROTO]

---------------

sec. 2:

There are no examples shown for each RPC operation.
There should be examples here instead of spread out
in the end of the document.

----------------

page 6:

<create-subscription>

"This command .."

Wrong terminology.
Use RPC method or operation.

-----------------
</Andy>

ok

<Andy>

page 6:

<named-profile>

This is still an opaque, under-specified proprietary hack. There should
be a read-write standard data model with standard parameters -- and
nothing else.

I strongly object to this parameter.
If vendors want to ignore the standard parameters
and use their own instead, then XML already allows them to
do that -- we should not help them hack around the standard within the
standard itself.

</Andy>

Sorry? In the latest specification, the data model associated with the
named profile is clearly defined. It's even read-write. What exactly is
it you are looking for?

----------------

<Andy>

<notification>

Positive Response: no response, etc.

This only applies to RPCs, so it can be removed here.
</Andy>

I disagree. I think it should be explicitly stated that there is no
response. First of all, because we could have made these acknowledged
events built on RPCs and second of all I still say the average reader
thinks about the Netconf operations rather then the RPC analogy we have
chosen to express them with. 

------------------

<Andy>
notification examples in section 5:

It should be made clear they are only examples
and are not normative.  The examples need to be explained
as well.

These examples are unrealistic.
I don't think it's proper for the agent to return a copy of all the
config that actually changed in a 'config-change' notification. This
could be really verbose, introduce access control problems, and it's not
really needed anyway, if the NMS is designed correctly.
</Andy>

We have added this disclaimer to other examples, but not those in
section 5. We can do that. We have identified two types of configuration
change events. The first provides more of a summary of changes in some
useful format (new interface up or something) and the second would
actually mirror the configuration command sent. The latter is necessary
for security audit logs. 

Notifications always have access control issues. People need to have
permission to see the data that is in the notifications.

------------------

<Andy>
schema comments

- an unspecified access control model is thrown in
   with these 'minAccess' and 'maxAccess' <appinfo> additions.
   There is no agreement in the WG on these XSD extensions,
   or understanding of the functional requirements.

</Andy>

Yeah, that is a bit of a problem. We need this mechanism, but we don't
have a standard one yet. So, we are using the one defined in
http://www.ietf.org/internet-drafts/draft-chisholm-netconf-model-05.txt

-----------------
<Andy>

filter example comments

Sec 6.2 introduces additional 'severity=foo' filtering syntax without
really explaining it.

Not sure what this <neb> element is in the example.

<netconf:filter> is broken XML -- there is no 'netconf' prefix or an
xmlns declared in the example.
</Andy>

Hmmm. Need to look into these. 

------------------

<Andy>
section 7.1.1.1 session lifecycle

The WG did not discuss or approve any such feature.
This watchdog-timer design doesn't work in a mixed-mode
session very well.  The netconf agent never abruptly
terminates a live session.  The lack of architecture discussion in this
document jumps out in this section.  There is no mention of the agent
constantly starting and tearing down sessions anywhere else.

This section needs to be removed.

</Andy>

Just the session lifecycle or the CallHome thing? Our understanding was
that there was consensus to look at how to address the callHome thing
and the session lifecycle is discussion related to that feature. If
there is no consensus for the callHome thing, we can move it back to the
design alternative appendix

--------------------

A.2 Lifecycle

This section is incorrect and needs to be removed.
The NETCONF-PROT document already mandates certain
non-volatile storage requirements.  This section
contradicts that normative text.

</Andy>

We'll have to look into it. I suspect this is a misinterpretation of
what is written rather then this design alternative was proposing
something in violation of what is the in the PROTO draft.

---------------------

<Andy>
Appendix B: Syslog within NETCONF events

events --> notifications

This section does dot clearly define how to encode the
XML PDU.  This should be a normative section (and fully
specified) or removed from the document.

Notification forwarding options needs to be agreed upon
by the WG, and fully explained in a detailed architecture section.

There is no proxy in netconf, and I aim to keep it that way.
</Andy>

We were not sure if there was consensus for this feature to be moved to
the main body of the document. We did add the new event class to support
the tunnelling though.

We don't specify how to encode any of the other event content. I don't
know if we should be doing it for this one case.

---------------------
<Andy>

Appendix C: Example Configuration Notifications

This section needs to be removed.
If the WG can agree of fully-specified standard notifications, then they
will included in normative text.

</Andy>

While we did delete the sections that provided examples for
non-configuration notifications, we were hesitant to delete this section
because we actually referred to it during discussions last month. It
might be useful to keep around for a bit longer.

Sharon

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

---

From: Andy Bierman <[email-masked]>
Date: Wed, 03 May 2006 07:07:47 -0700

> message to the datamodel. 

The WG will need to agree on the list on classes.
Currently there is no agreement.
This could take 3 - 6 extra months to reach
consensus on what the event types are allowed to be,
and the exact requirements and text related to each event type.

Putting some details in a non-normative appendix
instead of normative text is not acceptable.
It doesn't lessen the requirement for WG consensus
just because it's located in an appendix.

> in IANA seems reasonable.

Agreement on all semantics of all event classes is the key issue.
The form of the registry is irrelevant.

I don't -- especially if notifications end up as
an optional capability.

> <Andy>

 From my reading of the text, examples, and XSD, it appears
this is not clearly defined.  Let's see what others think.
It looked to me that it didn't change much, except you added
a sentence that says there is supposed to be a schema that
tells the manager what is in the named profile.

I think we just need a plain data model that contains all of the configurable
parameters.   This data model must be the same for all implementations.
That's because this is supposed to be a standard.

The netconf protocol already has RPCs for manipulating data models,
already deals with all aspects of NV-storage, etc.
We don't need to introduce the concept of named profiles.
It's just more complexity without purpose.

If there was a clearly specified architecture section, it would be
totally obvious how the notification "message flow" differed
from the RPC message flow.

      Positive Response : none

This doesn't really provide enough discussion of the message flow
or architecture.

I don't want to confuse implementors by implying in the
examples that including all the config sections that changed
in a notification is a good idea, or part of the standard.

Real big problem.
Won't get through the WG Chairs or the IESG.
It is not acceptable to block this document for unchartered work.
The min and max access allowed in terms of all netconf operations
will be defined in English text in a normative section.

The addition of <appInfo> elements for this purpose is not required,
not useful to off-the-shelf tools, and therefore not important.
The data models in NETCONF documents can be updated after
this sort of thing is standardized.

The <neb> example is fairly broken.
There is no way to do an OR-expression on 1 field
like the example seems to imply.

I think the entire Callhome section is under-specified and
the whole approach is convoluted.  We already have NV-stored
data models in netconf. We could easily have a traditional
notification architecture without any subscription mechanism,
instead of an agent that connects to a manager and says
"ask me to start sending you notifications".

How does the agent know to ask?
Because it was configured in its NV-storage.
There could just as easily be the entire notification config
as well.

I've never met any operators who would rather miss critical
notifications than "risk" the wasted bandwidth of an agent sending
out critical alarms but nobody is listening.

It seems to me that holding all notifications
until some manager app reconnects after a reboot
and asks for them, amounts to a polling architecture.
It doesn't scale well either.

The WG never even discussed this issue.
There was no discussion of adding new event classes,
only discussion of removing some event classes.

Now that the document is a WG-controlled document,
only changes that the WG agrees on are supposed to
show up in new versions.

Many vendors and operators at the IAB NM Workshop
were very clear in their request -- no proxy in netconf.
It was seen as complexity without purpose.

> know if we should be doing it for this one case.

Andy

---

From: Balazs Lengyel <[email-masked]>
Date: Wed, 03 May 2006 18:51:07 +0200

Sharon, first of all thanks for your efforts with the draft.

General comments:
1) We are not progressing well towards consensus so try to simplify the solution to get 
agreement faster.

2) Terminology: For me a subscription is a set of data that tells the netconf server where 
to send which notifications. This can be configured any way we like/decide. If this is not 
the correct term please propose a better name for it! ( I don't like named profile as it 
sounds too general.)
.
2) Data Model not new operations: I fully agree with Andy that we should use data models 
and the standard operations from netconf-prot and not introduce new operations (without 
very strong arguments, which I don't see here.)

I propose to upgrade the Named profiles into a standard data model for notification 
handling and use edit-config and get-config.
As a first step we need to agree that notifications should be handled with a data model 
and the only new operation needed is the notification itself. After this we can go on 
defining the data model itself. Can we get consensus on this?
!!!!!! THIS IS MY MAIN POINT. PLEASE ANSWER IT !!!!!!

This question is IMHO fully independent of the subscription, call-home, persistent 
profiles question.

3) Using both name profiles and session/subscription based filters is an overkill for me. 
I feel we have 2 separate mechanisms for the same function. I would just keep named 
profiles and drop the other filters in create-subscription, modify-subscription

4) We have the problem of long rpc-replies blocking the return channel for notifications. 
For this reason we discussed having a separate session for notifications. This does not 
appear in the draft. I think it should be there as an option.

5) For subscriptions I would propose to consider some extra data:
- persistent:boolean indicates whether the subscription is persistent or dies with the 
session.
- timeout:dateTime indicates whether this specific subscription should be removed if it is 
not used after a time (days, weeks). (garbage collection Jurgen asked for it, allowed to 
be set to infinity)
- suspended:boolean

6) Access Control: I feel we are not really dealing with access control here but rather 
stating what is meaningful on which bits of data e.g. do not try to write the operational 
state.

7) The draft does not address all requirements on Jurgen's page.

Section 1 somewhere)
Add text about:
- motivations, requirements (see Jurgen's web page)
- architecture of netconf Notifications (focus on notifications not on netconf-proto)
- mixed session, separate session

Section 2.2.1)
Mention that there might be a big chunk of user defined data here.

Section 3.2)
- Wrong name this is not a NetconfStateSchema but a netconfNotificationSchema or something 
  similar
- This data model should be writable as well, see general comment

Section 3.3)
I fully support a notification being a full XML document, but as far as I know with a SAX 
based parser you don't need a complete XML document to be able to process XML. Still life 
should be easier with complete XML documents.

Section 7)
I have a problem with the dormant-active state of the call home subscription. What is the 
real difference between them ?

Section 7.1)
When an event occurs and if we run the mixed-session mode the server should first check 
whether there is an already open connection to the client.

Section 7.1.1.1)
- Ericsson has a need for very long lived call home connections. We would probably put a 
heart-beat on the connection and this way never allow the connection to time-out. But I 
clearly see a need to put this time-out on separate sessions/individually.

Section 7.1.3.1.1)
The element subscriber is not really defined. Attributes like IpAddress, PortNumber etc. 
seem to be missing.

Appendix A)
I like the idea of suspend/resume but this should rather be a bit of data in the data 
model which can be set with edit-config.

Appendix B) Do we have a strong requirement for this ? I propose to remove it (or at least 
to delay ANY discussion of the feature after the time we agreed on basics).

regards Balazs