Subject: review of draft-ietf-netconf-notification-07.txt

From: "David B Harrington" <[email-masked]>
Date: Mon, 4 Jun 2007 11:30:12 -0400

Hi,

I haven't had a chance to complete my review of this revision; I'll
try to review the remaining pages soon. In the meantime, I'll provide
input on pages 1-21.

section 1.1  
"Subscription" does not define what a subscription is.
"Operation" is self-referential, which is a bad thing for definition. 
	("an operation refers to an operation." Not very helpful.
"Named Profile" is included, but not "Filter". Section 2.1.1 defines
both.
What is a "Network Element"? This is used in a definition but is nto
defined itself.

section 1.2
"this work is to enable ... sending ... messages ... consistent with
the data model ... and security model ..." I am not sure what data
model and security model refers to; I'm not sure they are defined
anywhere yet. I don't know how this document will make things
consistent with them. Would it be more accurate to change "consistent
with" to "independent of"? or independent of specific data models and
specific security models? 

What is a security model in netconf terms? It is not defined here or
in RFC4741.

section 1.3
"A capability may be advertised to announce that a server is able to
process RPCs while a notification stream is active on a session.  The
behaviour of such a capability is outside the scope of this document."

As I read this, I thought "if it is outside the scope of this
document, then why mention it here?". But if oyu remove this text,
then you miss an important decision made by this WG about the netconf
notifications protocol, which seems to argue that it is in scope for
this document. Shouldn't it be discussed here to ensure
interoperability of this feature of the notification protocol? We
certainly spent a lot of time debating it in the Montreal interim
meeting, because it was important to understand the implications of
this feature, and I don't see much of that debate captured here.

Section 1.4
consistent capitalization of the bullets, please.

"(syslog and SNMP are rather constrained in terms of message sizes)"
is not actually true any longer. draft-ietf-syslog-protocol-20 defines
no upper limit to message size.  and "When an SNMP entity uses the
snmpSSHDomain transport model, it must be capable of accepting
messages up to and including 8192 octets in size.  Implementation of
larger values is encouraged whenever possible."

"Data content must not preclude the use of the same data model as
      used in configuration"
I'm not quite sure what this means, since this document does not
define data content, does it? 
If you keep the sentence, I think it should read "same data model for
notifications as is used in configuration."

" o  solution should send sufficient information in a notification so
      that it can be analyzed independent of the transport mechanism
      (data content fully describes a notification; protocol
information
      is not needed to understand a notification)"
Isn't thsi about data modeling, not the protocol?

section 2.1 
capitalization in the section title:
s/Subscribing to receive Event Notifications/Subscribing to Receive
Event Notifications/

s/When the event notification subscription is created, the events of
interest are specified./The events of interest MUST be specified when
the event notification subscription is created./

section 2.1.1
Filter:
s/This is mutually exclusive/The filter parameter is mutually
exclusive/ ("this" could refer to the behavior described in the
previous sentence.)

Named profile:
Is the sentence needed that says "If not present, no additional
filtering will be applied."?

s/Note that changes/Changes/
s/This/The Named Profile parameter/

Start Time
s/indicates/indicate/

Stop Time:
Can stop time precede start time? Hasn't this been asked before? I
don't see it mentioned here.

section 2.2.1
s/event of interest (i.e., ...) to them/event of interest to them
(i.e., ...)/

section 2.3
Are there any security considerations for this still being an active
session after terminating? 

section 3.2
Figure 4 does not show where access control is applied, but section
3.2.5.1 mentions that a session must have sufficient privilege. I
assume the "privilege" check is perfomed after the stream is formed,
and probably before the Filter is applied. Or is "privilege"
determined by the netconf server, after filtering? Should the concept
of "privilege" or "access control" be included in this diagram
someplace, so operators and implementers can tell where the access
control occurs in the flow? Should it be mentioned explciitly?

section 3.2.2 
Is "contents" or "content" approrpiate here?
Must the XML be well-formed? Must it be valid?

3.2.3
s/NETCONF XML event notifications/NETCONF event notifications/

3.2.5.1
s/where <name> element is/where the <name> element is/
"value is unique" - within what scope?

s/snmp/SNMP/g

section 3.2.5.2
s/available event streams to/event streams available to/

section 3.3.1
Is "recently" accurate? who defines what recent means?
Would "previously" be accurate?

Is "resend" accurate? what if the event were logged and never sent
(due to loss of connectivity, for example)? Don't those also get
"replayed"?

section 3.3.2
Is the "replay complete" notification of section 3.3.2 the same as the
replayComplete notification of section 3.3.3? There are a number of
these that should be made consistent. I personally found the
replayComplete easier to recognize as a specific notiication than the
"replay complete notification" which has to be parsed (just slightly)
to make sure "replay" or "complete" were not being used as verbs in
the sentence. If you keep replay complete, then please quote it.

section 3.3.2 and 3.3.3 have text about when the replay complete
notification is sent. section 3.3.2 says it is sent to indicate that
all of the replay notications have been sent, but 3.3.3 says it will
only be sent if a stopTime was specified. So, I assume this menas only
the replay notificiaitons with a time less than or equal to stopTime
are sent, not "all of the replay notificiaitons".

If I understand correctly, if I am replaying notifications, and I set
the stopTime to be the time of my request, the channel may not be
available for new notifications while I am replaying, so they get
logged into the stream. They do not get "replayed" if I set a stopTime
when I make the request for replay, since they are later than that
stopTime. If I don't set a stopTime, the new logged notifications are
also replayed, and new (non-replay) notifications will be sent as they
arise naturally (per 3.3.2). Will netconf let me know when everything
logged has been replayed (so I can tell that subsequent notifications
in the stream will be real-time)? I think I'd like to know that.  

What is a "normal" NETCONF session? Is there a difference between a
subscription with no stopTime that sends notificiaitons as they arise
naturally, and a subscription with a stopTime that becomes a "normal"
netconf session?

section 3.4
s/and the query/and to query/

The XSD:
"Named Profile" discusses the fact that it can be created, read,
deleted, and modified. Should this documentation also include mention
of the fact that once applied to a subscription, that instance cannot
be modified, i.e., modifications will not impact the already-created
subscription?

"lastModified" says "Therefore, this time should be compared with the
last modified time asscoiated with the subscription. If ..." 
I recommend s/subscription. If/subscription; if/

s/Note that//g - Please get rid of (at least) some of these
unnecessary "Note that" phrases; everything in the spec is important,
but that doesn't mean every sentence should start with "Note that".
They are just not needed.

"notethere is no guarantee that the profile named in the subscription
will be found at all." - So what happens when that occurs? Should
nothing be sent? should everything be sent? shoul dit generate an
error because obviously there is a mismatch of expectations?

section 3.6
"it will be filtered out" - what is filtered out? the data? the
notification?

Note that "Note that ... Note that ... Note that ... Note that"  is
irritating!

Did we ever resolve the lowerCamel vs C-style naming? I see
"named-profile" and stopTime. Can we be consistent?

Note that ... I will send more later if I have time. ;-)

[a quick glance at security considerations - I recommend this section
include a discussion of the threats specific to notifications, and
specifically how to mitigate those threats (e.g., use the SSH
transport defined in RFCxxxx). I think this whole section will need
work to pass security review. I'll try to make some recommendations
later.]

David Harrington
[email-masked] 
[email-masked]
[email-masked]

--
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: Thu, 14 Jun 2007 10:52:16 -0700

> try to review the remaining pages soon. In the meantime, I'll provide

thanks for this review.
I think the clarifications you suggest are good.

The issues you raised will require some edits.
The named profiles and notification replay features
(bells & whistles to some degree) are not as precise
and clear to implementers as we require for standards-track RFCs.

I thought the sec. 1.3 capability about RPC processing
was already removed.  It was supposed to be removed.

Andy

---

From: Andy Bierman <[email-masked]>
Date: Sun, 24 Jun 2007 09:48:03 -0700

David B Harrington wrote:
>....

yes -- this is my fault -- I will stop doing it, and this redundant
text should be removed from this draft is well.

> "named-profile" and stopTime. Can we be consistent?

yes -- at the Prague meeting, and I think documented in the minutes.

Since we started using c-style-naming for our RPC method names
and their parameters, we decided to keep doing that.

To be more consistent with MIB object naming, the data model objects
are named with the lowerCamelNaming.

(It was a compromise to make both camps happy ;-)

IMO, it doesn't matter that much.  An implementation should
be able to handle any valid XML 'Name', and ignore these NETCONF
distinctions.

> work to pass security review. I'll try to make some recommendations

Please do.  The sooner the better (i.e., better we do it now
then wait for the DISCUSS from Sam ;-)

Andy