Re: [OPSAWG] Last Call: draft-ietf-opsawg-operations-and-management(Guidelines for Considering Operations and Management of NewProtocols and Protocol Extensions) to BCP

[Juergen Schoenwaelder]

On Thu, Jun 04, 2009 at 10:17:17PM +0200, Eric Rosen wrote:
 
> Generally,  the community (i.e.,  the folks  doing the  work in  the various
> areas) has never even heard  about these proposed requirements until after a
> BCP  appears, at  which  time they  are  told that  the  BCP "has  community
> consensus".  Perhaps  you're familiar with Douglas  Adams' "The Hitchhiker's
> Guide to the  Galaxy".  To paraphrase, "but the plan  for the destruction of
> earth was clearly posted in  the planning department on alpha centauri, it's
> not our fault you didn't see it".

There is a defined IETF review process and we just go through it and
from what I can tell the process works in making people comment on the
draft that was proposed to become a BCP.

While comments on the content of the draft are fine, I find comments
on the process pretty much out of scope.

/js

-- 
Juergen Schoenwaelder   Jacobs University Bremen gGmbH
Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103 
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Last Call: draft-ietf-opsawg-operations-and-management(Guidelines for Considering Operations and Management of NewProtocols and Protocol Extensions) to BCP

[Joel M. Halpern]

To put it differently, the OPS area has as much right to propose their 
requirements as any other area (Transport Congestion, Security, ...) 
has.  And generally, the community has listened to such requests and 
gone along with them.


Yes, we have produced a bit of a problem that our initial standards now 
have a quality bar comparable with completed work.  But we shouldn't 
suddenly pick on OPS for that.  If we are going to address that problem, 
it ought to be in a coherent fashion that discusses how we deal with all 
the legitimate requirements, including the fact that stuff has to be 
operable.


This does not mean we have to simply accept what they (OSP) say.  But it 
does mean we should give it a fair review, looking at the details, 
rather than objecting on principle.


Yours,
Joel M. Halpern


Sam Hartman wrote:

"Eric" == Eric Rosen  writes:


Eric> I don't see that OPSAWG has any business imposing
Eric> requirements on work done by other WGs in other Areas.

Obviously I agree with this statement.  However I do believe that the
ops area can propose and build consensus on requirements that we all
agree to follow.  I think this document may be a starting point in
such a discussion.  I think Eric and I probably both agree it should
not be the final word.
___
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

Re: Last Call: draft-ietf-opsawg-operations-and-management(Guidelines for Considering Operations and Management of NewProtocols and Protocol Extensions) to BCP

[Sam Hartman]

> "Eric" == Eric Rosen  writes:

Eric> I don't see that OPSAWG has any business imposing
Eric> requirements on work done by other WGs in other Areas.

Obviously I agree with this statement.  However I do believe that the
ops area can propose and build consensus on requirements that we all
agree to follow.  I think this document may be a starting point in
such a discussion.  I think Eric and I probably both agree it should
not be the final word.
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Last Call: draft-ietf-opsawg-operations-and-management(Guidelines for Considering Operations and Management of NewProtocols and Protocol Extensions) to BCP

[Sam Hartman]

> "Eric" == Eric Rosen  writes:
Eric> If we are going to talk about adding new hoops for folks to
Eric> jump through, we should first discuss whether any such hoops
Eric> are necessary.  We should not start the discussion by
Eric> looking at the details of the particular proposed hoops.

Agreed.  I think that if we don't have agreement with the
goals/high-level of this type of proposal, it's completely reasonable
to block review of details until that reaches agreement.
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Last Call: draft-ietf-opsawg-operations-and-management(Guidelines for Considering Operations and Management of NewProtocols and Protocol Extensions) to BCP

[Eric Rosen]

> This does not mean we have to simply accept what they (OPS) say.  But it 
> does mean we should give it a fair review, looking at the details, 
> rather than objecting on principle.

This is  absolute nonsense.  Most of  the people actually doing  work in the
various areas do not have the  time, interest, or expertise to do a detailed
review of  an OPS document.   However, these are  the people who are  in the
best position to determine whether "OAM Considerations" would help or hinder
the work that they do.

If we are going to talk about adding new hoops for folks to jump through, we
should first  discuss whether any such  hoops are necessary.   We should not
start the  discussion by looking at  the details of  the particular proposed
hoops. 

> the OPS area has as much  right to propose their requirements as any other
> area  (Transport  Congestion, Security,  ...)   has.   And generally,  the
> community has listened to such requests and gone along with them.

Generally,  the community (i.e.,  the folks  doing the  work in  the various
areas) has never even heard  about these proposed requirements until after a
BCP  appears, at  which  time they  are  told that  the  BCP "has  community
consensus".  Perhaps  you're familiar with Douglas  Adams' "The Hitchhiker's
Guide to the  Galaxy".  To paraphrase, "but the plan  for the destruction of
earth was clearly posted in  the planning department on alpha centauri, it's
not our fault you didn't see it".


___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Last Call: draft-ietf-opsawg-operations-and-management(Guidelines for Considering Operations and Management of NewProtocols and Protocol Extensions) to BCP

[Andy Bierman]

Joel M. Halpern wrote:
To put it differently, the OPS area has as much right to propose their 
requirements as any other area (Transport Congestion, Security, ...) 
has.  And generally, the community has listened to such requests and 
gone along with them.


Yes, we have produced a bit of a problem that our initial standards now 
have a quality bar comparable with completed work.  But we shouldn't 
suddenly pick on OPS for that.  If we are going to address that problem, 
it ought to be in a coherent fashion that discusses how we deal with all 
the legitimate requirements, including the fact that stuff has to be 
operable.




I agree, and I also agree with Randy about the lack of
standardized NETCONF content.  It is a clear indication
that the vendors do not want any standardized configuration
content.  Every time 'content' has come up for charter consideration,
the consensus has been to work on something else instead.

But the NETCONF/YANG pieces are coming together, and it will
allow WGs much more power and flexibility than SNMP/SMIv2
to define management interfaces which fit better with
the native CLI than anything the IETF has had before.

That is about as far as OPS-NM area can go.
If a protocol WG do not want to define a
standard configuration interface, then it
does not matter how well SNMP or NETCONF supports
this sort of work.

(One might question whether using the same NM standardization
methodology for 20 years and achieving consistently pathetic
results means the methodology itself needs to be changed,
not just the technology.)


This does not mean we have to simply accept what they (OSP) say.  But it 
does mean we should give it a fair review, looking at the details, 
rather than objecting on principle.


Yours,
Joel M. Halpern



Andy

___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Last Call: draft-ietf-opsawg-operations-and-management(Guidelines for Considering Operations and Management of NewProtocols and Protocol Extensions) to BCP

[Eric Rosen]

Adopting this document  as a BCP would  be a serious mistake, and  I hope it
will be strongly opposed.

There is absolutely no evidence that following the dictates of this document
will improve the quality of the  IETF's work, and we certainly know it won't
improve the timeliness.  There is no evidence that ignoring it will harm the
Internet.

I don't see that OPSAWG has  any business imposing requirements on work done
by  other WGs  in other  Areas.   There are  already an  adequate number  of
obstacles to getting work done.  The  last thing we need is another required
"considerations" section, or another set of excuses for ADs from one Area to
block documents from other Areas.













___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Last Call: draft-ietf-opsawg-operations-and-management(Guidelines for Considering Operations and Management of NewProtocols and Protocol Extensions) to BCP

[Eliot Lear]

[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

RE: Last Call: draft-ietf-opsawg-operations-and-management(Guidelines for Considering Operations and Management of NewProtocols and Protocol Extensions) to BCP

[Romascanu, Dan (Dan)]

Hi Sam,

A clarification and a clarification question in-line.

Dan
 

> -Original Message-
> From: Sam Hartman [mailto:hartmans-i...@mit.edu] 
> Sent: Thursday, June 04, 2009 2:23 PM
> To: Romascanu, Dan (Dan)
> Cc: Sam Hartman; ietf@ietf.org; ops...@ietf.org
> Subject: Re: Last Call: 
> draft-ietf-opsawg-operations-and-management(Guidelines for 
> Considering Operations and Management of NewProtocols and 
> Protocol Extensions) to BCP
> 
> >>>>> "Dan" == Romascanu, Dan (Dan)  writes:
> 
> Dan> Sam, Thank you for your review and opinions.
> 
> Dan> I would like to remind you and let many people that are not
> Dan> aware about the history of the document know one fact that
> Dan> may be important. This document is an outcome of the
> Dan> discussions hold at the IESG retreat in May 2006. I was then
> Dan> the 'fresh' AD bringing this issue to the IESG table, we
> Dan> discussed approaches on dealing with management in the IETF
> Dan> and the need for a different approach of looking at
> Dan> management than the 'write a MIB' which was the rule in the
> Dan> IETF WGs until then. I took the action item to 'write a
> Dan> draft' on this issue - which then developped in this piece of
> Dan> work chartered in the OPSAWG.
> I certainly appreciate the work that has gone into this 
> draft.  I'm not sure why the origins here are important.  If 
> you're saying that it should have special status because the 
> original discussion happened at the IESG level, I disagree.  
> If you're saying that the content has broad consensus because 
> it started at the IESG level, I disagree.  If you're saying 
> that it's important work with a long history, I agree.

None of these - just background information to place this document in
context. 

...

> 
> Dan> and for this reason rightly avoids making
> Dan> a prescription or imposing a fixed solution or format in
> Dan> dealing with operational considerations and manageability
> Dan> aspects of the IETF protocols. I think that it does make
> Dan> however the point that operational deployment and
> Dan> manageability aspects need to be taken into considerations
> Dan> for any new IETF work. The awareness of these issue should
> Dan> exist in any work the IETF engages with, after all we develop
> Dan> technologies and protocols to be deployed and operated in the
> Dan> real life Internet, not abstract mathematical models. It is
> Dan> fine if a WG decides that its protocol needs not
> Dan> interoperable management or no standardized data model, but
> Dan> this should be the result of discussions and decisions, not
> Dan> of mission.
> 
> 
> It's not at all clear to me from this document that would be fine.
> That's one of my most serious problems with the document.


Can you clarify? I cannot understand what is clear to you and what is
not, and with which statement you do not agree. 


> 
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Last Call: draft-ietf-opsawg-operations-and-management(Guidelines for Considering Operations and Management of NewProtocols and Protocol Extensions) to BCP

[Sam Hartman]

> "Dan" == Romascanu, Dan (Dan)  writes:

Dan> Sam, Thank you for your review and opinions.

Dan> I would like to remind you and let many people that are not
Dan> aware about the history of the document know one fact that
Dan> may be important. This document is an outcome of the
Dan> discussions hold at the IESG retreat in May 2006. I was then
Dan> the 'fresh' AD bringing this issue to the IESG table, we
Dan> discussed approaches on dealing with management in the IETF
Dan> and the need for a different approach of looking at
Dan> management than the 'write a MIB' which was the rule in the
Dan> IETF WGs until then. I took the action item to 'write a
Dan> draft' on this issue - which then developped in this piece of
Dan> work chartered in the OPSAWG.
I certainly appreciate the work that has gone into this draft.  I'm
not sure why the origins here are important.  If you're saying that it
should have special status because the original discussion happened at
the IESG level, I disagree.  If you're saying that the content has
broad consensus because it started at the IESG level, I disagree.  If
you're saying that it's important work with a long history, I agree.

  
Dan> I believe that the document recognizes the variance in
Dan> approaches for the different areas, protocols, and working
Dan> groups in the IETF 

I strongly disagree that it succeeds in this goal.
I agree it tries.
As an example, section 3.1 says that the primary goal when considering 
management should be interoperability.
That's a broad statement that does not have IETF consensus and is inappropriate 
for a BCP.

Dan> and for this reason rightly avoids making
Dan> a prescription or imposing a fixed solution or format in
Dan> dealing with operational considerations and manageability
Dan> aspects of the IETF protocols. I think that it does make
Dan> however the point that operational deployment and
Dan> manageability aspects need to be taken into considerations
Dan> for any new IETF work. The awareness of these issue should
Dan> exist in any work the IETF engages with, after all we develop
Dan> technologies and protocols to be deployed and operated in the
Dan> real life Internet, not abstract mathematical models. It is
Dan> fine if a WG decides that its protocol needs not
Dan> interoperable management or no standardized data model, but
Dan> this should be the result of discussions and decisions, not
Dan> of mission.


It's not at all clear to me from this document that would be fine.
That's one of my most serious problems with the document.
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

RE: Last Call: draft-ietf-opsawg-operations-and-management(Guidelines for Considering Operations and Management of NewProtocols and Protocol Extensions) to BCP

[Romascanu, Dan (Dan)]

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