[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Notification Issue List -- DRAFT
Andy Bierman <ietf@andybierman.com> wrote:
> 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.)
>
>
>
> Martin Bjorklund: 12/28/06, comments on -05, checked against -06:
> 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
I think the text is consistent with what was said at the interim. My
point is that I think it will be difficult to conform to this. I
suspect an agent implementation will actually use the "time it was
logged", since this time is the only one available to the agent.
(Unless it knows where to find the generation time in all
notifications it might relay). [IMO it would have been better with
the generation time in the "header". I know it was rejected at the
interim though.]
> I7a) targetNamespace assignment -- open
>
> o 3.2.5.2 (now 3.3)
>
> The schema should define a targetNamespace.
This one is fixed in 06. See I37 though.
> I8)
>
> o 5.1 & 5.2
>
> The prefix 'netconf' is undeclared in all examples.
>
> <netconf:filter type="subtree">
> ^^^^^^^
Still open in 06, but see I42 for other errors.
> 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.
Fixed in 06.
> 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.
Fixed in 06, section 3.3
> 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.
Same as I10, fixed in 06, section 3.3
From I26 and onwards, the comments are on 06, so I guess they are all
open in some sense.
> 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...
> I74)
>
> - What if the timezone is given and it is not the same as the agent's
> timezone?
The agent has to convert a time with timezone into whatever it's
internal notion of time is.
> I77)
>
> - Does the <kill-session> have to come from another session? (I think so)
Yes, that's how kill-session works. You can't kill yourself. From
rfc4741, on session-id:
Session identifier of the NETCONF session to be terminated. If
this value is equal to the current session ID, an
'invalid-value' error is returned.
> 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
Just accept <close-session>? And why not <kill-session>, it's small and
simple. And <lock> ... I think it's more clean to accept
all-or-nothing.
> I84)
>
> - pg 11, sec 3.2.3, Default Event Stream
> Mentions the "NETCONF" notification event stream but this is not
> defined anywhere.
I thought it is defined in 3.2.3.
> I87)
>
> - Can we use just one namespace for all NETCONF data model objects,
> put the definition in IANA, and use it for notification data?
And update it with a new URI when a new capability is defined? I
think it's better to use separate namespaces for base and
notifications.
> 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)
But that means that rfc4741 has to be updated, right? IMO it's
cleaner with separate namespace.
/martin
--
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/>