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.