RE: Gen-ART review of draft-ietf-netconf-notification-11.txt

["Hector Trevino (htrevino)" <htrevino@cisco.com>]

Hi Suresh,


Your comment from below:

I enquired what would happen if stopTime would be specified without a
startTime. You mentioned it was implicit in this sentence ""Must be used
with and  be later than <startTime>.". My question is why the other half
of the sentence "later that <startTime>" explicitly handled as an error
case while the "must be used with" not explicitly handled.

Response:

The definitions in the document included below. Start time is a
mandatory parameter for replay. Stop time is an optional parameter for
replay. If Start Time is not present then Stop time should not be
present, if it is, then it is an error. Maybe the Start Time and Stop
Time descriptions do not explicitely state this but I think the Negative
response text does. Does this satisfy you comment?

The Negative Response says:

     If a <stopTime> is specified in a request without having specified
      a <startTime>, the following error is returned:

         Tag: missing-element

         Error-type: protocol

         Severity: error

         Error-info: <bad-element>: startTime

         Description: An expected element is missing.



      Start Time:

         A parameter, <startTime>, used to trigger the replay feature
         and indicate that the replay should start at the time
         specified.  If <startTime> is not present, this is not a replay
         subscription.  It is not valid to specify start times that are
         later than the current time.  If the <startTime> specified is
         earlier than the log can support, the replay will begin with
         the earliest available notification.  This parameter is of type
         dateTime.

      Stop Time:

         An optional parameter, <stopTime>, used with the optional
         replay feature to indicate the newest notifications of
         interest.  If stop time is not present, the notifications will
         continue until the subscription is terminated.  Must be used
         with and be later than <startTime>.  Values of <stopTime> in
         the future are valid.  This parameter is of type dateTime.


 

-----Original Message-----
From: Suresh Krishnan [mailto:suresh.krishnan@ericsson.com] 
Sent: Sunday, February 17, 2008 9:57 PM
To: Sharon Chisholm
Cc: Bert Wijnen; General Area Review Team; Hector Trevino (htrevino);
Romascanu, Dan (Dan); Netconf
Subject: Re: Gen-ART review of draft-ietf-netconf-notification-11.txt

Hi Sharon,
   Please find comments inline.

Sharon Chisholm wrote:
> hi
>  
> <Suresh>
>>> Minor
>>> =====
>>>
>>> * Section 2.1.1
>>>
>>> What happens if a stopTime is specified and a startTime is not? Does

>>> the replay begin starting now or is the request rejected? This needs

>>> to be clarified.
>> This results in an error. I think this is implicit with the current 
>> text in section 2.1.1.
>>
>>  "Must be used with and be later than <startTime>." 
>>
>> I'm not sure further clarification is required.
> 
> Then why do we have the following error case explicitly listed?
> 
> "     If a <stopTime> is requested which is earlier then the specified
>        <startTime>, the following error is returned:
> 
>           Tag: bad-element
> 
>           Error-type: protocol
> 
>           Severity: error
> 
>           Error-info: <bad-element>: stopTime
> 
>           Description: An element value is not correct; e.g., wrong 
> type,
>           out of range, pattern mismatch."
> 
> </Suresh>
> 
> The text in section 2.1.1 says that stopTime must be later then 
> startTime and there is an error message defined later when this isn't 
> the case. I'm not sure what the issue is. Can you clarify?

I enquired what would happen if stopTime would be specified without a
startTime. You mentioned it was implicit in this sentence ""Must be used
with and be later than <startTime>.". My question is why the other half
of the sentence "later that <startTime>" explicitly handled as an error
case while the "must be used with" not explicitly handled.


> 
> <Suresh>
>>> * Section 3.2.1
>>>
>>> The term "Event Stream Definition" is used in Section 3.2 before it 
>>> is defined here. Is it possible to move this somewhere further up.
>> The term 'Stream' is defined in section 1.1 so I think we are OK.
> 
> The following text occurs in Section 3.2
> 
> "The central component inspects each event notification and matches
>   the event notification against the set of stream definitions."
> 
> At this point I was not aware what a "stream definition" meant and 
> how/where it was defined. Personally I would like to push the "Event 
> Stream Definition" or a subset of it to Section 1.1 but I do not have 
> a strong position on this.
> </Suresh>
> 
> My personal view is that since it is defined in the definition section

> I think we are ok.

OK. I am fine with this.

Thanks
Suresh



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