Re: Issue 14.1: Retrieval Subset specification proposal

[Wes Hardaker <wjhns1@hardakers.net>]

>>>>> On Tue, 16 Mar 2004 17:16:18 -0800, Andy Bierman <abierman@cisco.com> said:

Andy> I'm leaning towards rejecting this #xpath proposal and any
Andy> other proposal to put in place-holders for these loosely
Andy> defined features.

That's the problem.  They're more than place-holders, and less than
full features which you means you've locked in part of a solution with
none of the full-thought process.

Why wouldn't this feature be specified in a future document instead,
which seems to more architecturally sound.  You could always add an
appendix saying "Future directions the data model work is expected to
tackle" just so people who go looking for stuff that isn't there can
find something.

Now, having said that, I do have to say that Randy's points made me
ponder a bit longer (as they often do) on whether I should type up
this response as they left me more on the fence.  But I still think
documenting features that aren't fully described is pretty odd.  If it
was an enum problem, I could understand it.  But netconf is flexible
enough that I don't see the point of inserting something now that
could be added later.

(Though from a security protocol, one of the biggest problems about
dynamic protocols is that future modifications can greatly impact the
security of a protocol in ways that are hard to wrap your head around.
Most typically this results in access control mis-use problems, but
since you don't do that yet...)


-- 
"In the bathtub of history the truth is harder to hold than the soap,
 and much more difficult to find."  -- Terry Pratchett

--
to unsubscribe send a message to netconf-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/netconf/>