[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: comments on notification-07 draft



 Comments inline

-----Original Message-----
From: owner-netconf@ops.ietf.org [mailto:owner-netconf@ops.ietf.org] On
Behalf Of Martin Bjorklund
Sent: Wednesday, May 16, 2007 5:28 AM
To: netconf@ops.ietf.org
Subject: comments on notification-07 draft

Hi,

Here are some comments on the latest draft.  Some comments are the same
as before
(http://ops.ietf.org/lists/netconf/netconf.2007/msg00035.html).


  o  2.1.1 

     The missing-element's error-info is broken:

         Error-info: <startTime Description: An expected element is
         missing.

     I think that you should define an error-app-tag for the second
     error, i.e. replay asked for when it's not available.  
<sharon>

I believe there were previously comments to not have special error
messages. This was discussed in Prague too. It involves reving the base
protocol I think.
</sharon>

<clip>


   o  3.2.5.1

     In the rpc-reply example, none of the streams returned have the
     element 'replayLogStartTime', which according to the schema must
     be there.  Personally, I'd rather see the schema modified so that
     replayLogStartTime has minOccurs="0", and the description
     changed to:

         The start time of the log used to support the replay
         function. If replay is not supported, this element is not
         present.

<sharon>
I can go either way on this. As it is, the text is conditional (if
replay is supported ...), but it might be cleaner to set minOccurs=0
</sharon>

   o  3.4

     I've pointed out before that the 'stream' element makes no sense
     within a named profile.  If you think it does, the text for
     create-subscription must be modified to allow for this case.
<sharon>
I guess the problem is that stream has a minOccurs > 0 in the
subscription. I think it does make sense to be able to save this in the
named profile since it filters content.
</sharon>

   o  3.6
  
     Why does this section talk about "multiple filters"?  In the
     schema for 'create-subscription', the description for the
     'filter' parameter says: 

         This is mutually exclusive with the named profile parameter.

     So when/how can multiple filters be specified?
<sharon>
It doesn't. It talks about multiple filter elements. This is the term
used in the base protocol document. If it talks about multiple filters
anywhere this is residue, but I believe this has been corrected
everywhere now.
</sharon>

   o  5.1

     I've also said before that this example doesn't make much sense.
     It also contains some XML errors.

     
<sharon>
I thought you and Hector had worked on the updated examples and agreed
to the text offline? I guess Hector can comment on your proposed changes
and you can reach agreement here on the list.
</sharon>

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