Subject: Re: [Netconf] Alexey Melnikov's Yes on draft-ietf-netconf-4741bis-10: (with COMMENT)

From: "Bert (IETF) Wijnen" <[email-masked]>
Date: Tue, 15 Mar 2011 11:23:12 +0100

Inline

On 3/15/11 10:42 AM, Alexey Melnikov wrote:
> Alexey Melnikov has entered the following ballot position for
> draft-ietf-netconf-4741bis-10: Yes
>
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
>
> Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
>
>
>
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
> I am balloting Yes, but please check a couple of remaining comments.
>
Thank you.

> 4.3.<rpc-error>  Element
>
>     error-tag:  Contains a string identifying the error condition.  See
>        Appendix A for allowed values.
>
> Is the list of error conditions extensible? If yes, where can they be found? If not, it would be better to be explicit about this, in particular the document should mention that addition of a new error tag value would require capability version increment.
>
Mmm... My understanding was that this was addressed.
See email between you and Martin:

    4.3.<rpc-error>  Element
    >  >>
    >  >>     error-tag:  Contains a string identifying the error condition.  See
    >  >>        Appendix A for allowed values.
    >  >>
    >  >>Is the list of error conditions extensible? If yes, where can they be found?
    >  >>  

    >  >
    >  >No.  These are fixed in the Appendex, and in the XSD.
    >  >

So is that still not good enough?

    >  I think an explicit statement that any changes to the list need a new
    >  capability name (version) would be good.
    >  
    >  
    >  Additionally, can you please check if any issues from
    >  <http://www.ietf.org/mail-archive/web/apps-discuss/current/msg02268.html>  need
    >  to be addressed?

    Yes, most of these issues are already address in -09.

    /martin

> 7.8.<close-session>
>
>     Negative Response:
>
>        An<rpc-error>  element is included in the<rpc-reply>  if the
>        request cannot be completed for any reason.
>
> How is this possible? What can the client do next if the operation fails?
>
The discussion between you and MArtin:

    7.8.<close-session>
    >  
    >      Negative Response:
    >  
    >         An<rpc-error>  element is included in the<rpc-reply>  if the
    >         request cannot be completed for any reason.
    >  
    >  How is this possible? What can the client do next if the operation fails?

    Good catch. The only reason would be if the request is mal-formed,
    e.g. contains a unexpected parameter:

    <close-session>
    <session-id>42</session-id>
    </close-session>

so i guess that is the explanation.
Was that not sufficient?

Martin, did we add some other text that would make this clear?

> [I haven't checked if the following were addressed:]
> I am also agreeing with David's DISCUSS points # 1 and # 2, and I also think that Peter's Comment point # 1 is worth being DISCUSS level.
>
>

We have also responded to David's DISCUSS< see my posting (with copy to IESG list) this morning.
We hope he will clear his DISCUSS too.

I also believe we have addressed Peter's 1st comment, see changes to section 3.

Bert Wijnen
document shepherd

---

From: Alexey Melnikov <[email-masked]>
Date: Thu, 24 Mar 2011 15:40:06 +0100

Bert (IETF) Wijnen wrote:

>> Is the list of error conditions extensible? If yes, where can they be 
>> found? If not, it would be better to be explicit about this, in 
>> particular the document should mention that addition of a new error 
>> tag value would require capability version increment.
>>

I would like to see a sentence on this in Section 4.3.

> Martin, did we add some other text that would make this clear?

I haven't seen any change in the document.

>> I am also agreeing with David's DISCUSS points # 1 and # 2, and I 
>> also think that Peter's Comment point # 1 is worth being DISCUSS level.
>
>

Ok, great.

---

From: "Bert (IETF) Wijnen" <[email-masked]>
Date: Fri, 25 Mar 2011 10:03:09 +0100

Inline,

On 3/24/11 3:40 PM, Alexey Melnikov wrote:
>>> Is the list of error conditions extensible? If yes, where can they be found? If not, it would be better to be explicit about 
>>> this, in particular the document should mention that addition of a new error tag value would require capability version increment.
>>>

Mmmm with all due respect, I do not really see why that is needed.
We have it in the specific definition  in Appendix A, and I think that
"See Appendix A for allowed values" is a pretty definite statement,
is it not. Why add more text aka "extensions are not possible"?
We could also add "and there it never rains in California"... sorry,
couldn't resist.

> I haven't seen any change in the document.

I reread this thread and the section 7.8 and discussed it with Martin,

The close session allows a client to nicely close a session after which it can terminate
the session/connection. We actually expect that many clients may not even check
if there is an error (or any) return message.  The client decides it is done (for
whatever reason), then informs the server that it is going to close the session,
so the server can (if possible) cleanup and that is it. In any event, I bet that
the client then terminates the session/connection.

It seems so logical to me that I do not really see we need to add any text here.

Bert
document shepherd.