[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Notification Issue List -- DRAFT
- To: "Netconf (E-mail)" <netconf@ops.ietf.org>
- Subject: Notification Issue List -- DRAFT
- From: Andy Bierman <ietf@andybierman.com>
- Date: Sun, 11 Mar 2007 12:08:29 -0700
- User-agent: Thunderbird 1.5.0.10 (Windows/20070221)
Hi,
I concatenated and numbered all the mailing list comments
on notification-05 and -06. I will be working during the
week before the meeting to identify all the closed issues.
Hopefully, just a short list of open issues will remain by next week.
(If possible, can the reviewers who made specific comments
help identify status, open vs. closed. vs fix-known, edit-pending, etc.)
The comments are 'Numbered Inputs', from I1 to I105.
Andy
Martin Bjorklund: 12/28/06, comments on -05, checked against -06:
I1) edit - resolved
o 3.2.5.1 (fixed - para removed in -06)
The second paragraph seems to be redundant (same info as in the
first paragraph).
I2) named profiles combined with filter parameter - open
o 3.4 (now 3.5)
The text says:
Note that when multiple filters are specified, they are
applied collectively,
I suspect this text is no longer correct, since named profiles and
filters are mutually exclusive (for some reason).
--> Multiple filters are not supported in the schema
This would be introducing a new type of filtering in the
protocol, which is out of scope. This sentence should be removed
--> Is this multiple instances of 1 param, or combining param
and profile, or both?
I3) replay error codes - open
Need to limit error-tag values to existing values in RFC 4741
o 6.2
It is not obvious if a start-time-too-early error will create the
subscription or not. If create-subscription fails with a
start-time-too-early, it will be very difficult for a manager to
get all logged notifications (and practically impossible to know
when he got them all).
--> text says rpc-error is returned, but it is called a warning.
--> this seems inconsistent with other NETCONF operations which
--> use some sort of filter. They return 'empty data' instead
--> of an error.
If start-time-too-early does not fail the create-subscription
request, how does start-stop-time-mismatch work?
--> Error conditions should be explained in the text section,
--> not just the summary
Also, is start-stop-time-mismatch really needed? Can't we just
re-use 'invalid-value' (or 'bad-element') from rfc4741?
--> Agree!! Do not need new error code points for this, which
--> would require an update to RFC 4741.
I4) replay timestamps -- open
o 6.2
The text says:
Note that while a notification has three potential times
associated it - the time it was generated, the time it was
logged and the time it was sent out by the NETCONF server - the
startTime and stopTime parameters are related to generation
time.
I still think it will be difficult for an implementation to
conform to this -- it means that the logging subsystem must either
be given the generation time along with the notification itself,
or be able to extract the time from the notification content.
This might not always be possible.
--> Agree; this is part of the content layer (as determined at
--> the interim meeting
I5a) replay complete filtered out -- fixed
o 6.3
The text should probably state that the replayCompleteNotification
is not affected by any filters on the subscription.
Are eventClass, timeGenerated and numberEventsReplayed really
needed? Can't we just use:
I5b) exact structure of replayComplete notification -- open
<notification xmlns="urn:ietf:params:xml:ns:netconf:notification:1.0">
<data>
<replayCompleteNotification
xmlns="urn:ietf:params:xml:ns:netconf:replayNotification:1.0"/>
</data>
</notification>
And a few XML errors:
I6) namespace assignments -- open
o 3.2.5.1 (now 3.3)
The namespace of eventStreams is wrong:
<eventStreams xmlns="urn:ietf:params:xml:ns:netmod:base:1.0"/>
^^^^^^^^^^^
both in the request and the reply.
I7a) targetNamespace assignment -- open
o 3.2.5.2 (now 3.3)
The schema should define a targetNamespace.
I7b) bug -- fixed
The prefix 'nm' is not declared. (But maybe the 'nm'-elements
should be removed).
I8)
o 5.1 & 5.2
The prefix 'netconf' is undeclared in all examples.
<netconf:filter type="subtree">
^^^^^^^
I9)
o 5.2
Here's 'neb' again, now transformed into an undeclared prefix!
If "neb:" is removed from the xpath expressions, it will be ok.
I10)
The schema for Named Profiles has been removed. It seems a bit odd
that this mechanism is defined as configuration data, but no schema
(data model) exists for manipulating these Named Profiles.
-----------------------
Andy Bierman - 1/2/07 comment on -05
I11) Keep named profiles? Are they fully defined?
There are essentially 2 solution paths here:
1) remove named profiles completely. The RPC method parameters
are always passed at invocation time, without storing some
of them 'offline' in a named-profile.
2) define a proper standard data-model for the named profile contents,
which is accessible to the standard operations (e.g., edit-config,
get-config), and rooted at a specific point in the
Netconf Standard Data Tree (that doesn't exist yet).
I thought we agreed on (2) awhile ago.
Perhaps this was just over-active cut-and-paste editing.
------------------------
Li Yan 1/5/07 comment on -05
I12)
o 3.2.5.2
<xs:import namespace="urn:ietf:params:xml:ns:netconf:base:1.0"
schemaLocation="./draft-ietf-netconf-prot-12.xsd"/>
I13)
o 4
<xs:import namespace="urn:ietf:params:xml:ns:netconf:base:1.0"
schemaLocation="urn:ietf:params:xml:ns:netconf:base:1.0" />
Should the two schemaLocation be the same?
----------------------------
Andy Bierman 1/5/07 comment on -05
I14)
(1) extra appinfo -- fixed
Sec 3.2.5.2 of notification-05 contains a stream retrieval schema
with an appinfo element that is relying on the non-existent 'netmod template'
standard.
<xs:appinfo>
<nm:identity
xmlns:nm="urn:ietf:params:xml:ns:netmod:base:1.0">
<nm:Name>
NetconfNotificationSchema
</nm:Name>
<nm:LastUpdated>
2006-09-06T09:30:47-05:00
</nm:LastUpdated>
<nm:Organization>IETF
</nm:Organization>
<nm:Description>
A schema that can be used to learn about current
event streams.
</nm:Description>
</nm:identity>
</xs:appinfo>
All of this 'extra' info should be put in a <documentation> element or removed,
like the XSD in section 4.
I15)
(2)
I think the filter examples in sec. 5 need some sort of explanation
of the assumed data model (i.e., the one with 'eventClasses' and 'card'
as top-level siblings).
----------------------------
Balazs Lengyel - 1/9/07 -- comment on -05
I16)
General:
I thought we agreed on having just one schema instead of many small ones,
but if must I can live with this.
I17)
Chapter 1.2)
Please describe that any RPC requests received on a notification session
may be discarded silently, without any response message.
I18)
Chapter 2.3)
Mention termination due to closing the transport session or stop-time.
I19)
Chapter 3.2.5.2 Here in the nm:Name element we have
NetconfNotificationSchema which is not describing the content of
this specific schema.
I20)
Chapter 3.3) "While it is possible ..."
We do not provide a schema to retrieve this information, so I
would formulate this as "While it might be possible ..."
I21)
Chapter 6.2)
Start and stop times should relate to generation time "whenever possible".
Shouldn't we send back in the error info the date/time of the earliest
available notification.
I22)
Chapter 6.3)
Please indicate what happens with the session after the replayComplete
notification is sent. Is it terminated on transport level? Does it become
a normal session? Is it some kind of stale/ useless session? What options
might a device choose? I feel terminate SSH/SOAP/BEEP is the best.
------------------------------------------
Tom Petch 2/15/07 comment on -05
I23)
I see unmatched single quote and right hand bracket in the xpath; I am innocent
in the ways of xpath but imagine that they might not be ok either.
I24)
I see no reference in the text to xpath and no such reference listed in 9.
----------------------------------------------
Sharon Chisholm 2/16/07 proposed edit list
The following is the proposed set of edits to the Notification draft to
resolve comments received. It may not reflect recently received
comments.
1. Put back schema to create and query named profiles, except combine
into single schema with the one for event stream discovery. (Source:
Martin & Andy)
2. In section 1.2, indicate that RPCs requests received on a
notification session may be discarded silently. (Source: Balazs)
3. In section 2.3, indicate that termination may also result from
termination of the underlying transport session or reaching a stop time
on a replay. (Source: Balazs)
4. In section 3.2.5, delete the first sentence of the second paragraph
and merge the second sentence with the first paragraph. (Source: Martin)
5. In section 3.2.5.2, fix namespace. (Source: Martin)
6. In section 3.2.5.2, delete the appInfo reference to netmod tags.
(Source: Andy, others)
7. In section 3.2.5.2, fix the schemaLocation to be the proper urn.
(source Li Yan)
8. In section 3.3.3, replace "While it is possible" with "While it may
be possible". (Source: Balazs)
9. In section 3.4, there is some confusion between individual filter
criteria (severity=major) and the collective set of filters one gets in
a named profile or with in-line filters. In checking with the base
protocol specification, I think the terms should be filter element and
filter respectively. The section (and perhaps other parts of the
document) will be updated to consistently use these terms to clear
things up. (Source: Martin)
10. In section 5, update/add explanation of data model assumptions to
the filter examples (Source: Andy)
11. In section 5.1 and 5.2, fix Schema errors. (Source: Martin)
12. In section 5.2, remove the neb prefix. (Source: Martin)
11. In section 6.2, replace the Error-info for start-time-too-early with
"<log-startime>: Timestamp of earliest event available for replay".
(Source: Balazs; Martin)
12. In section 6.2, add text indicating that in the event of a warning,
the event subscription is still created. (Source Martin). Note I also
propose changing the severity of start-stop-time-mismatch to an error
instead of a warning.
13. In section 6.3, indicate that after the replayComplete notification
is sent, the session then becomes a normal Netconf session. (Source:
Balazs)
14. In section 6.3, indicate that the replayCompleteNotification can not
be filtered out. (Source Martin)
--------------------------------------------
Tom Petch 2/16/07 comment on -05
I25) well-formed XML - closed
MUST the event be properly formed XML? I imagine it must but do not see that
explicitly spelt out in the I-D. Equally, MUST there be a DTD or Schema for an
event?
(Response from Sharon 2/20/07)
It must be well-formed XML. I had been thinking that this was covered,
but since we are not re-using rpc messaging for Notifications anymore, I
guess we need to explicitly state it. I don't think we can make any more
specific claims in this document, but certain can in data model related
ones.
---------------------------------------------
Balazs Lengyel - 2/22/07 -- comment on -06
Generally the document is in good shape, I could except it as is, but
still I have some comments:
I26)
1.) Consider adding: content of notification messages is out of scope.
I27)
1.2 paragraph 2) The sentence starting with "These event notifications..."
might need some rewording.
I28)
2.1.1) An example could be useful.
I29)
2.2.1) An example could be useful.
I30)
3.2.5.1) Change title to Stream Retrieval ...
I31)
3.3) Why do we need more then one namespace? I feel we should put
everything into one.
I32)
3.5) Remove first sentence. There can be only one filter.
I33)
5.1) The sample event list is hard to understand. I would rather like to
know which bit of XML will go into each event. Is it the <eventEntry>
element as a whole or just the contents of <eventEntry> ? The example
on page 24 indicates only the contents, the example on page 25 indicates
the whole <eventEntry>. The two examples contradict each other.
I34)
5.1 page 25) In my understanding the example is faulty. The
last <eventEntry> clause is useless as the first
<eventClass>fault<eventClass> clause will always let through
all "faults". The first clause should be removed.
I35)
6.2) I would mention that in replay sessions events are always
sent in order of their timestamps. Events occurring during a
replay will not be sent immediately, but only after all
previous events are sent.
---------------------------------------------------------
Tom Petch 2/23/07 comment on -06
I36) Xpath bugs -- missed edit -- fix pending
I am looking at section 5.2 and seeing
<netconf:filter type="xpath"
select="event/eventClasses/fault' and
(event[severity='critical'] or
event[severity='major'] or
event[severity='minor')))"/>
which appears to have seven single quotes, one left hand round bracket
and three right hand round brackets, three left hand square brackets
and two right hand square brackets.
Response from Hector Trevino (2/23/07)
Hi, I was looking at your comment and noticed that this section (5.2)
was not get updated properly. We'll update.
------------------------------------------------------
Martin Bjorklund: 2/25/06, comments on -06:
I37)
o 3.2.5.1
Uses the URI "urn:ietf:params:xml:ns:netmod:base:1.0" for event
streams in the example. But the schema in 3.3 uses
"urn:ietf:params:xml:ns:netmod:event:1.0". These should be the
same.
I suggest that this info is put into the
"urn:ietf:params:xml:ns:netconf:notification:1.0" schema.
I38)
o 3.3 /namedProfiles/namedProfile/name
xs:key is not used for namedProfile/name. If it's not unique or a
key, then there can be several namedProfiles with the same name.
I suspect this is not the intention. The text in 3.2.5.1 says
that the value is unique. Maybe that is sufficient.
It also says about 'name' that it is modifiable. How is this
supposed to be done over NETCONF? (how do you modifify the key?
or even worse if it's not a key).
I39)
o 3.3 /namedProfiles/namedProfile/stream
Why is this element included here? A stream is always specified in
the <create-subscription> (or defaults to NETCONF) when a
namedProfile is used. Are these supposed to match??
I40)
o 3.3 /namedProfiles/namedProfile/filter
This element has a minOccurs="0". It means that the element may
or may not be present in an instance document. Why is it used
here?
I41)
o 5.1
The text shows a sample event list which doesn't match the
examples that follows.
I also don't understand the <events> container. I suggest that
the <events> container is removed, and <eventEntry> is changed to
<event> in this list. The second example must also be modified to
match this.
I42)
o 5.1 and 5.2
All four examples use an undeclared prefix "netconf" on the
element 'filter' (it shouldn't be there; 'filter' is defined in
the new namespace), and <create-subscription> lacks a xmlns
attribute.
Both xpath examples use the element name 'eventClasses' but the
text and other examples use 'eventClass'.
I43)
o 6.1
Section 2.1.1 says that an <ok/> element is returned for a
<create-subscription> if the request can be satisfied.
This section (6.1) says
"If a client requests a replay of notifications that predate
the oldest notification available, then the NETCONF server must
return a warning message in the RPC reply and start replaying
the notifications it does have available"
But, according to 4.4 of rfc4741,
"The <ok> element is sent in <rpc-reply> messages if no errors
or warnings occurred during the processing of an <rpc>
request."
This is also consistent with the XML schema in rfc4741.
Thus, it is not possible to return <ok/> and a warning.
I suppose the intention of 6.1 is that a warning only (i.e no
<ok/> element) is returned. The text in 2.1.1 should be updated
to reflect this.
I44)
o 6.2
This section lists additional "Negative Response" to
<create-subscription>. I think these should be moved to 2.1.1,
where <create-subscription> is defined.
Also, two new error-tags are defined. If I understand the schema
in rfc4741 correctly, it is not possible to define new
error-tags. An error-app-tag can be used though.
Also, I don't think start-stop-time-mismatch is needed - the
standard 'invalid-value' can be used.
I45)
o 6.3
I think that the replayCompleteNotifcation should be defined in
the "urn:ietf:params:xml:ns:netconf:notification:1.0" schema.
I.e. use a single schema (instead of three) for everything.
Other Minor issues:
I46)
o 1.2
"A capability may be advertised to announce that a server is
able to process RPCs while a notification stream is active on a
session."
Should this text really be here? There is no such capability
defined.
I47)
o 2.1.1
"until the subscription to terminates."
^^^ ??
I48)
o 3.2.5.2
This section (including 3.2.5.2.1) seems to be redundant.
Compare with 2.1.1.
I49)
o 3.3
The schema uses xs:import to import a namespace which isn't used
(1998/namespace), and two imports with a bad (?) schemaLocation.
The prefix ncEvent is defined but not used.
The documentation for namedProfile:
"A named profile, which is a saved set of parameters
associated that may be associated with zero or more active
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ ??
subscriptions."
I50)
o 3.3
You're using two top-level elements in this schema. This means
that you can't create a single standalone XML instance document
which lists the eventStreams and namedProfiles (since an XML
document must have a single top-level element). This isn't an
error per se, but I thought I should mention it.
I51)
o 3.5
"Note that when multiple filters are specified,"
Multiple filters cannot be defined anymore, right?
I52)
o 4
The xs:import in this schema seems to be copy-and-pasted from
thee netconf schema. It is not needed here.
--------------------------------------------
Martin Bjorklund: 2/26/06, comments on -06:
I53)
In 6.2, about the warning message, it says
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.
------------------------------------------
Li Yan 2/28/07 comment on -06
I54)
o 1.2 paragraph 3, "An NETCONF server" should be "A NETCONF server".
^^
6.1 contains a "An NETCONF server" also.
I55)
o 5.2 The first example:
<netconf:filter type="xpath"
select="event/eventClasses/fault' and
(event[severity='critical'] or
event[severity='major'] or
event[severity='minor')))"/>
^^^
Parentheses don't match.
I56)
o 5.2 The second example is wrong. The given filtering criteria are
not consistent with the xpath filter.
The first xpath clause should be removed.
select="((event[eventClasses/fault] or
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
I57) element naming style -- open
o I suggest that the naming style of elements should be identical.
There are two naming style in the draft. For example, "named-profile"
and "namedProfile". I prefer "xxx-yyy" to "xxxYyy".
--> agree
---------------------------------------------------
Sharon Chisholm 3/2/07 comment on -06
I58)
I noticed when creating the monitoring schema that it is convenient when
the protocol Schema defines things as types rather then elements. It
makes it easier for other schemas to just use the definition -
type="netconf:SessionId", for example. The Schema for the Notification
definition should turn the following into types:
stream
named-profile
-------------------------------------------
Andy Bierman 3/11/07 comment on -06
In general, I think the draft is almost done, and hopefully
we can resolve all the minor open issues soon. There comments are
in page order, and range from typos to design flaws...
I59)
- pg 3, ToC: Suggest title change of sec. 3.4
'Subscriptions not Configuration Data'
I60)
- pg 3, ToC: Sec. 5 title : Capitalize examples
I61)
- pg 3, ToC: No entry for IANA Considerations (no section either)
I62)
- pg 4, middle of page: Move 'Figure 1' above the para, and directly below
the figure
I63)
- p4 4. sec. 1.1 Terms
Managed Object is unclear, not used anywhere, should be removed
I64)
- p5 Terms
Operation: 2nd sentence is not true. Term used as stated only in
sentence 1.
I65)
- p5 sec1.2: Put first para in Terms section as 'Event'
I66)
- pg 7, bottom: missing period after parameter
I67)
- pg 7 - 8: General comments on create-subscription
I68)
- need to specify conceptual data types for all parameters in this
section
I69)
- need to show usage examples in this section
I70)
- need to combine entire section 6 (Replay) into this section since it is
confusing to introduce just the parameters but not the feature.
I71)
- once again, we are creating parameter dependencies that XSD cannot
represent.
(Just as happy to rant against XSD than change things though ;-)
I72)
- pg 8, Start Time and Stop Time comments
I73)
- What if a legal start-time (or start/stop pair) specifies some time in
the future?
I74)
- What if the timezone is given and it is not the same as the agent's
timezone?
I75)
- What if a time change (e.g., daylight savings time) happens?
- Explain how both parameters handle forward and backward boundary
conditions
I76)
- pg 8, sec 2.1.1, Negative Response
This section is correct, but inconsistent with the text in sec. 6.1,
para 3.
There is no mention of a 'warning-and-continue' mode of operation here.
(More reason why sec 6. create-sub. details needs to be integrated
into this section.)
- pg 9, sec 2.3, Terminating the Subscription
I77)
- Does the <kill-session> have to come from another session? (I think so)
I78)
- IMO, since we do not have an endless RPC reply model, it is not a
burden
to the agent to accept a <close-session> from the session getting
notifications
I79)
- Does sentence 2 mean after the last replayed notification that meets
the stop time criteria, the session is terminated?
I80)
- last sentence, capitalize Netconf to NETCONF
I81)
- pg 10, sec 3.1.2, cap. exchange example
IMO, this section should be removed. Sec. 3.1.1 defines the
capability identifier.
Just say that RFC 4741 defines the capability exchange.
I82)
- pg 11, diagram
This is a good diagram but there should be text following it explaining
all the boxes, why they are there, and where in this document the
relevant
definitions can be found
I83)
- pg 11, 3.2.1-2, typos
- s/via NETCONF protocol/via the NETCONF protocol/
- missing period after last sentence
- s/i.e. the notification/i.e., the notification/
I84)
- pg 11, sec 3.2.3, Default Event Stream
Mentions the "NETCONF" notification event stream but this is not
defined anywhere.
Need to put this in the IANA considerations section that will be added.
I85)
- pg 12, typos
- para 1, s/e.g. SNMP, syslog, etc./e.g., SNMP, syslog/
- para 3, missing space after <get> and before operation
- pg 12, Name Retrieval comments
I86)
- Need introduction and formal description of the data model for
retrieving
stream names
I87)
- Can we use just one namespace for all NETCONF data model objects,
put the definition in IANA, and use it for notification data?
I88)
- agree with comment to change <eventStreams> to <event-streams> for
better consistency with rest of this doc, and RFC 4741.
I89)
- pg 13, bad XML style
<description> end tags on new line introduces significant whitespace
into the element content
I90)
- pg 13, sec 3.2.5.2, redundant section
This section is confusing to read, and does not really add any value,
since the previous section just defined event subscription.
I91)
- pg 14-15, XSD comments
- 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 NC
operations)
- do not need to import these 3 namespaces
- should define 1 namespace for data models related to the NETCONF
protocol,
not a separate namespace for every bit of monitoring data.
- do not need 'stream' parameter; it is already in the
<create-subscription> RPC
- 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.
- can we use short prefixes, like 'nc' instead of 'netconf'?
I92)
- pg 16, sec 3.4
Not clear why this section is here. It is actually incorrect.
If a proprietary configuration data model (or future standard) exists,
then this section is wrong.
I93)
- pg 17, sec 3.5
First sentence is wrong; multiple filters cannot be combined.
I94)
- pg 17, 3.5.2
Term 'just-in-time filtering' is used here without any explanation
what it is, or why it matters in this document.
I95)
- pg 18, message flow diagram
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.
I96)
- pg 19, XSD comments
Apply same changes wrt/ namespaces, imports, and prefixes
I97)
- pg 20, XSD typo
Indentation of <xs:choice> is wrong
I98)
- pg 22-26, sec. 6
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)
I99)
- pg 27, sec 6 Replay
Should move all <create-subscription> details to sec 2.1.1
I100)
- pg 27, sec 6.1, para 2
Is this warning-then-continue mode really needed? Why not just send
the replay-complete notification right away, and not special-case any
parameters. Bad filter data is just a no-match, not an error.
I101)
- pg 28, error-tags
We cannot update RFC 4741 to add redundant specialized error codes.
We already have 'invalid-value'. IMO, these should not even be errors.
If the supplied timestamps are well-formed, but produce no output,
then this is an empty data set.
I102)
- pg 28, error handling design
The manager and agent procedures can both be simplified here.
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.
If a stop-time is specified, then the normal termination procedure
is followed after the replay-complete is sent.
I103)
- pg 29, XSD comments
- do not need a special namespace for the replay-complete notification
- suggest simple name like 'replay-complete' instead
of 'replayCompleteNotification'. This appears in instance documents
- eventClass element introduces data model details into this document
that the WG has not agreed to
- eventClass is an empty element with no data type or content. Doubt
that is what is intended.
- do not need statistics collection and reporting in this notification
- 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.)
- agree with Martin that a simple empty notification element called
<replay-complete> is sufficient:
<notification>
<replay-complete/>
</notification>
- 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 ;-)
I104)
- pg 30, Security Considerations
- remove 'use of <kill-session>, only want to document the threats from
this document, not RFC 4741.
- fully specify the exact security threat, exact parameter names, use
cases, etc.
- 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?
- explain that the notification content is outside the scope of this
document
but care must be taken just as with SNMP Notifications
- explain how notifications are handled by the agent in the presence
of access control.
Is the entire notification dropped if only some of the included data
is not allowed,
or just the classified data removed from the notification?
- capitalize netconf to NETCONF in last sentence
I105)
- pg 30, missing IANA Considerations section
- need to determine exact IANA requests and add them here
----------------------------------------------------