Re: [netmod] Wrapping up system-creatable
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [netmod] Wrapping up system-creatable



Hi David,

if this choice refers to YANG 1.0, my preference is 1 but I am also fine
with 2 - it could be actually helpful if the _issue_ gets formulated
rather than the solution.

Lada

David Partain píše v Út 27. 10. 2009 v 14:56 +0100:
> Hi,
> 
> The various documents have been updated in advance of the upcoming IETF, and, 
> unless I'm mistaken, we seem to have one sticky issue left to clear up, and 
> that is what to do about system-creatable.
> 
> Last week, Martin published a set of possible choices of what we could do.
> 
> It would be helpful if everyone who cares would reply to this message telling 
> me / the group what you think the right answer is.
> 
> The choices are below.  If you think there are other possible choices, please 
> say so.  I've renumbered just to try to make it clearer what you're "voting" 
> for.
> 
> 1. Do nothing in the draft and let implementations and data models figure out
> how/if/when/why the server can modify the configuration data.
> 
> 2. Do nothing but write in the document that we _know_ it's an issue but we're 
> still not doing anything.
> 
> 3. Add text that says that the server MUST NOT modify config data unless 
> dictated by the data model (through description clauses or future 
> extensions).
> 
> 4. Add text that says that the server is free to modify config data in any way 
> it wants, unless constrained by the data model (through description clauses 
> or future extensions).
> 
> 5.  Add formal statements (e.g. the current s-c) to control how the server can 
> modfiy config.
> 
> Please let your voice be heard as soon as possible.  Please try to choose 
> one...
> 
> Thanks.
> 
> David
> _______________________________________________
> netmod mailing list
> netmod at ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
-- 
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C


Note: Messages sent to this list are the opinions of the senders and do not imply endorsement by the IETF.