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

["Sharon Chisholm" <schishol@nortel.com>]

Hi

Actually, we already do have an error message for that:

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.

Sharon 

-----Original Message-----
From: Chisholm, Sharon (CAR:ZZ00) 
Sent: Sunday, February 24, 2008 5:23 PM
To: 'Suresh Krishnan'
Cc: Bert Wijnen; General Area Review Team; Hector Trevino; Romascanu,
Dan (Dan); Netconf
Subject: RE: Gen-ART review of draft-ietf-netconf-notification-11.txt

Hi

Ah. That makes more sense. I think that same error can be used in both
cases and I will clarify the text of the message to indicate that it
gets sent in both cases.

Thanks,

Sharon

-----Original Message-----
From: owner-netconf@ops.ietf.org [mailto:owner-netconf@ops.ietf.org] On
Behalf Of Suresh Krishnan
Sent: Sunday, February 17, 2008 11:57 PM
To: Chisholm, Sharon (CAR:ZZ00)
Cc: Bert Wijnen; General Area Review Team; Hector Trevino; 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/>

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