[this one more publicly]
Dan,
Based on the goals you set out below, I would argue that the document is
too long. I would recommend sticking with principles and calling out a
few examples. I think this is done reasonably well in Section 2, and
less so elsewhere. I would also suggest that you scope the document,
because what you write below wasn't clear to me on first read.
Eliot
On 6/4/09 11:16 AM, Romascanu, Dan (Dan) wrote:
Sam,
Thank you for your review and opinions.
I would like to remind you and let many people that are not aware about
the history of the document know one fact that may be important. This
document is an outcome of the discussions hold at the IESG retreat in
May 2006. I was then the 'fresh' AD bringing this issue to the IESG
table, we discussed approaches on dealing with management in the IETF
and the need for a different approach of looking at management than the
'write a MIB' which was the rule in the IETF WGs until then. I took the
action item to 'write a draft' on this issue - which then developped in
this piece of work chartered in the OPSAWG.
...
This is a concern that the document does not have broad
enough consensus to be a BCP. I believe that significant
areas of the IETF do not view management interoperability as
a goal--much less a guiding principle of management. I've
been involved in discussions in the Kerberos working group
where we explicitly discussed this and came to the conclusion
that management interoperability was not something anyone in
the room was going to work on. We did work on an information
model which covers aspects where people believed some degree
of management interoperability would be desirable. It does
not cover monitoring, faults, or the like--only provisioning
of the database.
Similarly, I'm quite certain that most web server vendors,
ATOM implementors, etc do not want management
interoperability. I understand that ISP operators very much
do want management interoperability. I think that we have a
significant conflict here and I think that we cannot approve
such a BCP without addressing that conflict. One possible
resolution would be to find an subsection of the IETF that
actually agrees with these guidelines and scoping the BCP.
Similarly, it has been my experience that the desire to
standardize information model semantics is not universal
across the IETF.
I believe that the document recognizes the variance in approaches for
the different areas, protocols, and working groups in the IETF and for
this reason rightly avoids making a prescription or imposing a fixed
solution or format in dealing with operational considerations and
manageability aspects of the IETF protocols. I think that it does make
however the point that operational deployment and manageability aspects
need to be taken into considerations for any new IETF work. The
awareness of these issue should exist in any work the IETF engages with,
after all we develop technologies and protocols to be deployed and
operated in the real life Internet, not abstract mathematical models. It
is fine if a WG decides that its protocol needs not interoperable
management or no standardized data model, but this should be the result
of discussions and decisions, not of mission.
Dan
_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
