Hi Sharon, Please find comments inline. Sharon Chisholm wrote:
hi<Suresh>This results in an error. I think this is implicit with the current text in section 2.1.1.Minor ===== * Section 2.1.1What 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."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.1The term "Event Stream Definition" is used in Section 3.2 before it isdefined 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/>