----- Original Message ----- From: "Jeffrey Haas" <[email protected]> To: "t.petch" <[email protected]> Cc: "Jeffrey Haas" <[email protected]>; <[email protected]> Sent: Tuesday, June 10, 2014 2:41 PM
> Tom, > > Thanks for the comments. > <snip> > > > I do find the I-D quite hard to follow as the terminology seems > > inconsistent - the word 'state' is much used but it is unclear to me if > > the term can be given a single definition in this context; and even if > > it can, the word seems an unfortunate choice since the IETF Ops Area has > > given it a precise definition which is at odds with its use here. > > Are there specific edits you would suggest to clarify the document? I think that the problem is pervasive. 'State' appears everywhere, starting with the Abstract in this I-D, and also on the list, and I really do not know what it means. It gets qualified - protocol state, active state, programmed state, routing-related state, operational state, structured information and state that is frequently not directly configurable, ephemeral state, dynamic system state, static system state etc. - but perhaps the killer phrase comes in 6.2 I2RS State Storage with "These sets of data form the I2RS data store." The model in the Ops Area, which might be familiar to those enthusiastic about YANG and NETCONF, is a split into 'config' and 'state' as in RFC6241, a split that was explicitly requested by Operators (RFC3535) so using the term state in a different sense here I struggle with. At least a definition is needed to contrast it with the Ops Area usage (but I am too unclear to offer such a definition). Tom Petch > -- Jeff _______________________________________________ i2rs mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2rs
