[Last-Call] Re: [netconf] Opsdir last call review of draft-ietf-netconf-transaction-id-07

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Dear Bing,

Thank you for helping me perfect this document, and your patience taking the open points all the way. There was only one unresolved comment left, I believe. It was about the set of Versioned Nodes in the schema tree.

It took me a while, but I think I might have figured how you interpreted the text in your last comment now.

> > > I. Clarification issues
> > > 
> > > #1 Section 3.2
> > > “Regardless of whether a server declares the Versioned Nodes or not,
> > > the set of Versioned Nodes in the server's YANG tree MUST remain
> > > constant, except at system redefining events, such as software upgrades or
> > > entitlement (a.k.a.
> > > "license") installations or removals.“
> > > 
> > > It means that the txid does not support a normal node transitioning to
> > > a Versioned Node, or verse visa dynamically. It might be good to add a
> > > couple of sentences to explain why it has such limitation, e.g., maybe
> > > there is no requirement in practice, or there might be potential
> > > requirement but such capability requires more sophisticated design
> > > that would need another work to address it.
> > 
> > [JANL] Thank you. I propose adding the following to the section 3.2 paragraph
> > quoted above. Do you think that would clarify the situation?
> > 
> > """
> > If the set
> > of Versioned Nodes was allowed to change while a client was connected, the
> > client would no longer be able to reason about the change, since the effective
> > txid of some nodes would sometimes change even when no configuration
> > change has taken place.
> > """
> 
> 
> [Bing] Sorry that I'm still a bit confused. I can understand that the Versioned Nodes should not change while a client was connected. But the quoted text above indicates that unless the system redefined, the VN should not be changed. So my last comment above was actually thinking about the situation that when no clients connected and yet no system redefining happens, is it possible to update the VN through configuration?
> 
> It is totally ok for me that this document limits the VN update only to system redefinition, just want to understand the thinking behind it.
> (Btw, please pardon me for getting to the bottom of this niche.)

I value you taking the time to pull this all the way. The way I understand your comment now is that you were under the impression that when the draft talks about the set of Versioned Nodes should not change, you take that to mean that their *configuration* values should not change. That is not at all what I'm trying to convey. I'm trying to say that a Versioned Node must not change into a non-Versioned Node in the schema tree (except at SW upgrade, etc), nor the other way around, a non-Versioned Node to become a Versioned Node.

The configuration values of all configuration nodes in the configuration tree will of course change as clients make changes (and the txid values updated accordingly).

I have tried to clarify this in the following paragraph under 3.2:


Regardless of whether a server declares the Versioned Nodes or not,
the set of Versioned Nodes in the server's YANG tree MUST remain
constant, except at system redefining events, such as software upgrades
or entitlement (a.k.a. "license") installations or removals. If a
Versioned Node was allowed to change status to a non-Versioned Node
(or vice versa), the client would no longer be able to reason about
the change. The effective txid of some nodes would sometimes seem to
change even when no configuration change had taken place.


Did I interpret your comment correctly and if so, does the above clarify matters?

Best Regards,
/Jan

-- 
last-call mailing list -- last-call@xxxxxxxx
To unsubscribe send an email to last-call-leave@xxxxxxxx




[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Mhonarc]     [Fedora Users]

  Powered by Linux