Subject: Notification Issue List -- DRAFT

From: Andy Bierman <[email-masked]>
Date: Sun, 11 Mar 2007 12:08:29 -0700

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

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

---

From: Martin Bjorklund <[email-masked]>
Date: Mon, 12 Mar 2007 12:52:13 +0100 (CET)

>   --> Agree; this is part of the content layer (as determined at

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.]

>     The schema should define a targetNamespace.

This one is fixed in 06.  See I37 though.

>         <netconf:filter type="subtree">

Still open in 06, but see I42 for other errors.

>     If "neb:" is removed from the xpath expressions, it will be ok.

Fixed in 06.

> (data model) exists for manipulating these Named Profiles.

Fixed in 06, section 3.3

> 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.

>   - What if the timezone is given and it is not the same as the agent's

The agent has to convert a time with timezone into whatever it's
internal notion of time is.

>   - 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.

>     to the agent to accept a <close-session> from the session getting

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.

>  Mentions the "NETCONF" notification event stream but this is not

I thought it is defined in 3.2.3.

>     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.

>     the capability to determine whether to use it (like all other NC

But that means that rfc4741 has to be updated, right?  IMO it's
cleaner with separate namespace.

/martin

--
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: Mon, 12 Mar 2007 07:39:53 -0700

Martin Bjorklund wrote:
>...

<xsd-rant>
For some definition of the word 'cleaner'.

I know from the protocol draft experience that we must modify our XML
to meet the capabilities of XSD, if ever the 2 are in conflict.
Unfortunately, XSD isn't very good at all at some things
that SNMP/SMI got right, like DM lifecycle, extensions, conformance...

What makes it worse is that there is no DM discovery mechanism
(like SNMP getnext), except for a <get> or <get-config> of the entire tree.
If the filter (subtree or Xpath) has any nodes at all in it,
then they must be in a particular namespace.  Therefore, all other
namespaces (mixed in the child nodes) will be skipped by the filter
because they don't match the namespace ID test.

At least in SMI, if you add an AUGMENTS or new table (in a new module)
later on, an NMS can find it with a getnext starting somewhere 'close by'
in the OID tree, (if the MIB is properly designed) like the module root.
NETCONF has a capabilities exchange, but these are technically just
capability URIs (like registration OIDs) and not namespace URIs.

So every time we change or add a new bit of data to NETCONF,
it will have to be in a new XSD <schema> and with a new targetNamespace?
So by the time we have one tenth as many 'MIB objects' as SNMP,
we will have about 5000 different namespace URIs to deal with?

Eventually, vendors will add their own hacks to undo the uselessness
of various XSD CLRs, like saving configs without defaults or ignoring
namespace processing rules.  What a mess...
</xsd-rant>

Andy

---

From: Martin Bjorklund <[email-masked]>
Date: Mon, 12 Mar 2007 16:17:32 +0100 (CET)

> that SNMP/SMI got right, like DM lifecycle, extensions, conformance...

I agree.  Don't use XSD for data modelling ;)

> capability URIs (like registration OIDs) and not namespace URIs.

These could be the same.  In fact, that's what we do all the time -
each loaded datamodel namespace URI is by default sent by the agent as
a capability.  So this is DM discovery.  This has nothing to do with
XSD though.

Also, we're currently experimenting with something similar to
AUGMENTS, but in the XML you get back you will see the augmented data
where the base data is defined.  A small example:  DS0 augments the
ifEntry:

    <ifEntry>
      <ifIndex>1</ifIndex>
      ...
      <ifAlias>ds0 if</ifAlias>
      <ds0:ds0ChannelNumber>1</ds0:ds0ChannelNumber>

> we will have about 5000 different namespace URIs to deal with?

This problem isn't unique for NETCONF, and I think it has been solved
(it must be) for XSD in general.  A DM effort for NETCONF has to
consider this problem of course.

/martin

---

From: Andy Bierman <[email-masked]>
Date: Mon, 12 Mar 2007 09:26:08 -0700

> I agree.  Don't use XSD for data modelling ;)

Yeah right. Tell the IESG that ;-)

> a capability.  So this is DM discovery.  This has nothing to do with

I am using the unofficial 'module URI'

  urn:ietf:params:netconf:capability:module:<owner-name>:<mod-name>:<mod-version>

  The namespace URI is auto-generated with the (owner, application, [version]) tuple,
  module.  A module is just a container of definitions.  It does not directly
  impact the data organization structure.  (Gee, another thing SMI got right.;-)

  What about adding 'module', 'namespace', and 'version' attributes to
  the <capability> element, to keep with the "do not parse URIs" CLR?

  What about a <get-version> operation to help figure out up-rev and down-rev
  incompatibilities at runtime?

> consider this problem of course.

I don't think it has been solved in XSD.
(Anyone know, then send a pointer!).

I know people are working on alternatives to XSD ;-)
We would only have one programming language if every software project
had the same problem to solve.

If I was trying to solve an XML document editing problem,
I would use WEBDAV.  If I was trying to provide the most
comprehensive language to model XML instance documents,
I would use XSD.  But I'm working on a network management problem,
not an XML document problem.

Andy

---

From: Martin Bjorklund <[email-masked]>
Date: Mon, 12 Mar 2007 19:44:49 +0100 (CET)

> (Anyone know, then send a pointer!).

http://www.xfront.com/SchemaVersioning.html
http://www.xfront.com/Versioning.pdf

> not an XML document problem.

I completely agree.

/martin

---

From: Andy Bierman <[email-masked]>
Date: Mon, 12 Mar 2007 13:24:47 -0700

> http://www.xfront.com/Versioning.pdf

good -- this is what I was doing: keeping targetNamespace the same
but changing schemaLocation for each version

Andy

---

From: "tom.petch" <[email-masked]>
Date: Fri, 16 Mar 2007 12:12:40 +0100

I raised I23 against -05 which was not fixed so I raised I36 against -06 - still
open

I raised I24 against -05 and this is fixed in -06

I raised I25 against -05 and this is fixed in -06

Tom Petch

----- Original Message -----
From: "Andy Bierman" <[email-masked]>
To: "Netconf (E-mail)" <[email-masked]>
Sent: Sunday, March 11, 2007 8:08 PM
Subject: Notification Issue List -- DRAFT

> The comments are 'Numbered Inputs', from I1 to I105.

<snip>

---

From: Balazs Lengyel <[email-masked]>
Date: Mon, 19 Mar 2007 12:11:33 +0100

Hello,
About my comments:
I16) too many namespaces: open
I17) closed
I18) closed?
I19) closed
I20) closed
I21) closed
I22) closed
I26) open, not so important
I27)  Open not so important
I28) open
I29) open
I30) Open
I31) Open, for me this is important
I32) open
I33) open
I34) open
I35) open

other comments:
- if starttime is in future, it should have no effect, same as if it would be missing

- all times should be converted to UTC for internal use, that solves time-zone and time leap 
problems

- I like the warning for the case when we asked for a too early start-time. Page 27 sec 6.1 para 3

- I prefer to keep named profiles, but can live without them.

- Timestamps SHOULD be generation time. The term SHOULD allows
the implementations to deviate from this, but states our wish.

- it should be allowed to add new error codes.
I think having more specific error codes is a very much needed and good idea.
One of our difficulties with SNMP was just this, that
the error codes provided by SNMP was limited.
I understand that this is problematic with the XML
  so the error codes shall go into some place like the error-app-tag.

Balazs
PS: Sorry and  I hope it is not to late, but at the moment I am occupied with  my new baby.