Re: Netconf Notifications WC LC: Issues & Proposed Resolutions - Part 1

[Andy Bierman <ietf@andybierman.com>]

Sharon Chisholm wrote:
> Hi
>
> I have a different proposed resolution to issue 17, which I think people
> will prefer. The requirement for a warn-and-continue construct goes away
> with the addition of the replayLogStartTime introduced in the resolution
> of issue 44. This provides an alternative way to tell the difference
> between no notifications within a timeframe and no notifications in the
> log for a timeframe.
>
> Updated Proposed Resolution for 17: I think we briefly discussed this in
> Prague, but I don't remember the consensus, if any. An edit is
> definitely required to make these consistent with each other.
> Conditional on the inclusion of replayLogStartTime discussed in issue
> 44, delete any reference to warn-and-continue like constructs from
> current section 6 before merging it into section 2.2.1 and section 3.


I'm having a hard time following all the details in these long emails.
I don't recall what Issue 17 by number.

I've decided it would be easier (for me anyway) to just read the new draft
when it comes out, rather than discussing the issue list.

We are getting to the point when we start asking for strong objections
to text, rather than just comments, especially issues which have
been closed for some time.

I have no strong objections to anything in the draft, so I'm not
going to comment further on the remaining details.

> Sharon

Andy

> -----Original Message-----
> From: owner-netconf@ops.ietf.org [mailto:owner-netconf@ops.ietf.org] On
> Behalf Of Chisholm, Sharon (CAR:ZZ00)
> Sent: Wednesday, April 11, 2007 3:46 PM
> To: Netconf (E-mail)
> Subject: Netconf Notifications WC LC: Issues & Proposed Resolutions -
> Part 1
>
> <clip>
>
> 17. pg 8, sec 2.1.1, Negative Response (Source Andy) 
>
> a.	This section is correct, but inconsistent with the text in sec.
> 6.1, para 3.
> b.	There is no mention of a 'warning-and-continue' mode of
> operation here. (More reason why sec 6. create-sub. details needs to be
> integrated into this section.)
>
> Proposed Resolution: I think we briefly discussed this in Prague, but I
> don't remember the consensus, if any. An edit is definitely required to
> make these consistent with each other. The reasons why warn and continue
> is required it to allow the client to create a replay request without
> actually needing to know the exact time of the earliest available log.
> Propose adding text to section 2.1.1 to reflect the warn and continue
> method discussed in section 6.  Create a new section between "Positive
> Response" and "Negative Response" called "Warn and Continue" with the
> following text "If the NETCONF server can satisfy the request, but the
> start time specified is too early then the <rpc-error> element will be
> included a warning message, but the client can expect <notifications> to
> be along the Netconf session. "
>
> <clip>
>
> --
> 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/>