[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Netconf Notifications WG LC: Issues & Proposed Resolutions - Part 2
Hi
Here is the rest of the working group last call comments. I will also be
posting resolution to the Phil's slightly late comments. Coming soon.
26. pg 13, sec 3.2.5.2, redundant section (Source Andy)
This section is confusing to read, and does not really add any value,
since the previous section just defined event subscription.
Proposed Resolution: It provides information about querying the
subscription. Proposed no change.
27. pg 14-15, XSD comments (Source Andy)
a. should define the new verbs to be in the NETCONF base namespace
and use the capability to determine whether to use it (like all other No
operations)
b. do not need to import these 3 namespaces
c. should define 1 namespace for data models related to the NETCONF
protocol, not a separate namespace for every bit of monitoring data.
d. do not need 'stream' parameter; it is already in the
<create-subscription> RPC
e. do not need the <lastModified> read-only timestamp. This is just
general metadata associated with the configuration database. We should
have a general <config-changed> notification if this is so important.
IMO, it is not important, and also a bad idea to copy this aspect of MIB
design.
f. can we use short prefixes, like 'nc' instead of 'netconf'?
Proposed Resolution: One namespace for content and one for protocol
operations.
In section 3.3, delete "<xs:import
namespace="urn:ietf:params:xml:ns:netconf:notification:1.0"
schemaLocation=
"urn:ietf:params:xml:ns:netconf:notification:1.0"/>" since it is
not being used.
This stream here is not redundant with the one in the protocol. It is
the list of streams available. It is the step before the
create-subscription command. Propose no change.
The lastModidifed field is useful and necessary to tell if there is a
mismatch between the content of the named profile and what the
subscription is using. Propose no change.
Replacing the netconf prefix with nc would make things less readable
with very little or no benefit. Propose no change.
28. pg 16, sec 3.4 (Source Andy)
a. Not clear why this section is here. It is actually incorrect.
b. If a proprietary configuration data model (or future standard)
exists, then this section is wrong.
Proposed Resolution: We agreed before the information is not persistent
across reboot. So, this is correct, according to what the working group
agreed to. Proposed no change (except for the section title change
discussed in another issue).
29. pg 17, sec 3.5 (Source Andy)
First sentence is wrong; multiple filters cannot be combined.
Proposed resolution: In section 3.5, first paragraph replace "Note that
when multiple filters are specified" with 'Note that when multiple
filter elements are specified". Replace "If a filter is Specified" with
"If a filter element is specified". In the second paragraph replace
"Note that the order that filters are applied" with "Note that the order
that filter elements are applied".
30. pg 17, 3.5.2 (Source Andy)
Term 'just-in-time filtering' is used here without any explanation what
it is, or why it matters in this document.
Proposed resolution: In section 3.5.2, replace "just-in-time" with
"inline".
31. pg 18, message flow diagram (Source Andy)
Should mention (and show) that many rpc/rpc-reply sequences could occur
before the create-subscription. In fact, text suggests use of
get(event-streams) first.
Proposed Resolution: add text in section 3.6 in the first paragraph
before the picture: "It is possible that many rpc/rpc-reply sequences
occur before the subscription is created or after a stopTime in a replay
subscription, but this is not depicted in the figure."
32. pg 19, XSD comments (Source Andy)
Apply same changes wrt/ namespaces, imports, and prefixes.
Proposed Resolution: If we agreed there were no changes above, then
there are not changes here.
33. pg 20, XSD typo (Source Andy)
Indentation of <xs:choice> is wrong
Proposed Resolution: In section 4, indent the filter element in the
choice tag to fix the indenting.
34. pg 22-26, sec. 6 (Source Andy)
Move entire section to a non-normative appendix and state clearly that
the data models shown are examples, not standards(bugs found by others
in examples not confirmed)
Proposed resolution: It is all clearly labeled as examples. Other RFCs
have examples in the main body of the document. Don't see any reason to
move it to an appendix. Propose no change.
The following changes need to be made to fix the bugs:
In section 5.1, on page 24 replace
" <rpc message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:notification:1.0">
<create-subscription
xmlns="urn:ietf:params:xml:ns:netconf:notification:1.0">
<netconf:filter type="subtree">
<event xmlns="http://example.com/event/1.0";>
<severity>critical</severity>
</event>
<event xmlns="http://example.com/event/1.0";>
<severity>major</severity>
</event>
<event xmlns="http://example.com/event/1.0";>
<severity>minor</severity>
</event>
</netconf:filter>
</create-subscription>
</rpc>
"
With
" <rpc message-id="101"
xmlns:netconf="urn:ietf:params:xml:ns:netconf:base:1.0">
<create-subscription
xmlns="urn:ietf:params:xml:ns:netconf:notification:1.0">
<netconf:filter type="subtree">
<event xmlns="http://example.com/event/1.0";>
<events>
<eventEntry>
<eventClass>fault</eventClass>
<severity>critical</severity>
</eventEntry>
<eventEntry>
<eventClass>fault</eventClass>
<severity>major</severity>
<eventEntry>
<eventEntry>
<eventClass>fault</eventClass>
<severity>minor</severity>
<eventEntry>
</events>
</event>
</netconf:filter>
</create-subscription>
</rpc>"
In section 5.2, replace
" <rpc message-id="101"
xmlns:netconf="urn:ietf:params:xml:ns:netconf:base:1.0">
<create-subscription>
<netconf:filter type="xpath"
select="event/eventClasses/fault' and
(event[severity='critical'] or
event[severity='major'] or
event[severity='minor')))"/>
</create-subscription>
</rpc>"
With
" <rpc message-id="101"
xmlns:netconf="urn:ietf:params:xml:ns:netconf:base:1.0">
<create-subscription>
<netconf:filter type="xpath"
select="//eventEntry[(eventClass='fault' and
(severity='minor' or severity='major'
or severity='critical'))]"/>
</create-subscription>
</rpc>"
Also in section 5.2, replace
"<rpc message-id="101"
xmlns:netconf="urn:ietf:params:xml:ns:netconf:base:1.0">
<create-subscription>
<netconf:filter type="xpath"
select="((event[eventClasses/fault] or
event[eventClasses/state] or
event[eventClasses/config]) and
((event[eventClasses/fault] and
event[severity='critical']) or
(event[eventClasses/fault] and
event[severity='major']) or
(event[eventClasses/fault] and
event[severity='minor']) or
event[eventClasses/fault/reportingElement/card='Ethernet0']))"/>
</create-subscription>
</rpc>"
With
" <rpc message-id="101"
xmlns:netconf="urn:ietf:params:xml:ns:netconf:base:1.0">
<create-subscription>
<netconf:filter type="xpath"
select="//eventEntry[(eventClass='fault' and
severity='minor') or
(eventClass='fault' and severity='major') or
(eventClass='fault' and severity='critical') or
(eventClass='fault' and card='Ethernet0') or
eventClass='state' or eventClass='config']"/>
</create-subscription>
</rpc>"
35. 3pg 27, sec 6 Replay (Source Andy)
Should move all <create-subscription> details to sec 2.1.1
Proposed Resolution: This is a duplicate of issue 15.
37. pg 28, error-tags (Source Andy)
a. We cannot update RFC 4741 to add redundant specialized error
codes.
b. We already have 'invalid-value'. IMO, these should not even be
errors.
c. If the supplied timestamps are well-formed, but produce no
output, then this is an empty data set.
Proposed Resolution: The changes introduced as a result of issue 2
should also cover this issue.
38. pg 28, error handling design (Source Andy)
a. The manager and agent procedures can both be simplified here.
b. If the parameters are well-formed, but produce no matches, then
this is no different than if the filter removed everything and there was
no output. In both cases, just sent the replay-complete notification
right away, instead of any warnings or errors.
c. If a stop-time is specified, then the normal termination
procedure is followed after the replay-complete is sent.
Proposed resolution: Conditional on the introduction of a timestamp on
the stream Schema to indicate earliest logged notification, I think the
warn and continue behaviour can now be removed.
For point c, this is what the draft currently says. Propose no change.
39. pg 29, XSD comments (Source Andy)
a. do not need a special namespace for the replay-complete
notification
b. suggest simple name like 'replay-complete' instead of
'replayCompleteNotification'. This appears in instance documents
c. eventClass element introduces data model details into this
document that the WG has not agreed to
d. eventClass is an empty element with no data type or content.
Doubt that is what is intended.
e. do not need statistics collection and reporting in this
notification
f. do not need a timeGenerated timestamp here. The manager's receive
timestamp is good enough, considering that the content or time of this
notification is irrelevant. The manager just needs a marker to signal
the end of replay. (That was the functional requirement.)
g. agree with Martin that a simple empty notification element
called <replay-complete> is sufficient: even if numberEventsReplayed was
useful, it should be a bounded integer like 'unsignedInt' or
'unsignedLong', not integer. 2^^64 log entries is a large enough amount
to cover most implementations ;-)
Proposed Resolution: The namespace bit is a duplicate of (24).
Generally in the document, rename replayCompleteNotification to
replayComplete.
Working group consensus in Prague was to not have any content. Will
remove content from the replayComplete notification.
40. pg 30, Security Considerations (Source Andy)
a. remove 'use of <kill-session>, only want to document the threats
from this document, not RFC 4741.
b. fully specify the exact security threat, exact parameter names,
use cases, etc.
c. fully specify which data model content is writable and identify
any threats to services due to notification delivery on a NETCONF
session. (Are there any?
d. explain that the notification content is outside the scope of
this document but care must be taken just as with SNMP Notifications
e. explain how notifications are handled by the agent in the
presence of access control.
f. Is the entire notification dropped if only some of the included
data is not allowed, or just the classified data removed from the
notification?
g. capitalize netconf to NETCONF in last sentence
Proposed Resolution: In section 7, remove bullet " o use of
<kill-session>"
Add text to section 7 that says "If a user does not have permission to
view content via other NETCONF operations it does not have permission to
access that content via Notifications. If a user is not permitted to
view one element in the content of the notification, the notification is
not sent to that user.
In section 7, capitalize netconf to NETCONF in last sentence.
Request text from working group to cover other issues.
41. pg 30, missing IANA Considerations section (Source Andy)
need to determine exact IANA requests and add them here
Proposed Resolution: This is a addressed by resolutions to (9) and (22).
42. The example in section 2.1 have some redundant tags, such as
</config>, </data> and </event>. (Source Ma Yuzhi)
Proposed Resolution: There are no examples in section 2.1, but we will
check all examples before submitting.
43. Create more types within protocol XSD (Source Sharon)
Proposed Resolution: In section 4, create types for stream and
named-profile based on current definitions.
44. In 6.2, about the warning message, it says (Source Martin)
Error-info: <log-startime> : Timestamp of earliest event
available for replay
This element (log-starttime) should be defined in the schema. Also, the
short description could be clarified. What exactly does "available for
replay" mean? Does it mean available using the filters and access rules
currently in effect? I assume it does not, since if it did, the warning
would be pretty useless - the same info will be included in the first
event replayed.
Proposed Resolution Add log start time as a field in the stream query
Schema. We can then remove the warning.
In section 3.3, within the definition of stream replace
"<xs:sequence>
<xs:element name="name" type="xs:string"/>
<xs:element name="description" type="xs:string"/>
<xs:element name="replaySupport"
type="xs:boolean"/>
</xs:sequence>"
With
"<xs:sequence>
<xs:element name="name" type="xs:string"/>
<xs:element name="description" type="xs:string"/>
<xs:element name="replaySupport"
type="xs:boolean"/>
<xs:element name="replayLogStartTime
type="xs"dateTime">
<xs:annotation>
<xs:documentation>
The start time of the log used to support
the replay
function. If replay is not supported, this
will return
the current time.
</xs:documentation>
</xs:annotation>
</xs:element>
</xs:sequence>"
Sharon Chisholm
Nortel
Ottawa, Ontario
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/>