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: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] 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 [EMAIL PROTECTED] with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/netconf/> _______________________________________________ Gen-art mailing list [email protected] http://www.ietf.org/mailman/listinfo/gen-art
