Subject: [OPS-AREA] draft-ietf-opsawg-operations-and-management-00.txt

From: "David Harrington" <[email-masked]>
Date: Mon, 12 Nov 2007 11:20:32 -0500

inline. 

> The last sentence of the abstract is a bit convoluted. Suggest:
> OLD
>    The purpose of this document is to provide guidance to authors of
>    protocol documents about aspects to consider related to the
>    operations and management that should be considered for 
> inclusion in
>    documents defining requirements or functionality of new 
> protocols or
>    protocol extensions.
> NEW
>    The purpose of this document is to provide guidance to authors of
>    documents that define requirements or functionality of new 
> protocols
>    or that define protocol extensions. The guidance is about aspects
>    related to operations and management that should be considered
for
>    inclusion.

Thank you for the NEW text. 
I think it can be made even more concise. How about this?
"The purpose of this document is to provide guidance to authors of
documents defining new protocols or protocol extensions. The guidance
covers aspects of operations and management that should be
considered."

> ===
> Introduction. First paragraph.
> First sentence rightly refers to new protocols or protocol
extensions.
> Last sentence refers only to new protocols.

fixed.
> ===
>    [DISCUSS - This document seems to be just as concerned with the
>    protocol designer's "mind-set" and the protocol development
process
>    as it is with the protocol as a finished product.  While 
> we all agree
>    that it would be a good thing to imprint operational
sensitivities
>    into the consciousness of the protocol developer, I do not 
> think that
>    this is a practical goal.  The best that we can do is to 
> set forth a
>    list of objective criteria by which a protocol designer 
> can evaluate
>    whether the protocol that he/she has developed is manageable.]
> I think this point is worth crystalising in the text. But we 
> shoud also
> give some guidance about things to include/exclude in order to
achieve
> the goal of being manageable.

I have this listed as a DISCUSS. The WG needs to discuss this and
reach consensus on what this document should focus on. Different
people have different ideas of what this document is for.

> ===
>    [DISCUSS: - the document may attempt to cover too much 
> ground.  Maybe
>    it will develop into a framework document, supported by 
> documents of
>    the following sort: . what makes a MIB usable? . how much
protocol
>    state information needs to be exposed and how? . how much 
> performance
>    information needs to be exposed and how?]
> Certainly too much detail will render the document unreadable 
> by all but
> the management geeks (who we assume are already the converted in
this
> matter. Better to be short and pithy with pointers to more
information
> on specific topics in different places.
> In fact, a good piece of the docment seems to be about the
philosophy
> underlying the giving of guidance. maybe that should be separated
from
> the guidance itself and the philosophy underlying the guidance.
> My feeling is that, at 37 pages, it is already unlikely to be read
by
> many people. That may be unfortunate, but it fact. I think you have
to
> get your base document down to around 15 pages.

Suggestions for specific text that can be eliminated are welcome. 

I think most of the discussion about the philosophy of giving guidance
are in DISCUSS sections, where the comments I have received reflect
different opinions about what this document should focus on, and I do
not see a consensus on the point. The WG needs to make a decision, and
then all these DISCUSSes will go away.

Some of the philosophy text is here because people are concerned about
having another required "considerations" section, or having more
requirements that might slow the standards approval process. When this
document was started, I was told by one OPS AD to make it very clear
this imposed no requirements on document authors or protocol
designers. The other OPS AD now seems to want this document to be more
of a checklist of requirements that must be met for document approval.
My personal take on this is that this document can provide guidelines,
but the (ever-changing membership of the) IESG can make a decision
about how the guidelines should be used over time.

> ===
>    Experiments
>    to require such sections have had a mixed reaction from protocol
>    developers.
> Not for inclusion in the I-D, but have you any details of negative
> reactions to such experiments?

No. I believe this is cut and paste from somebody's email comments. I
do not have specific details of the "experiments" done in the routing
area or various WGs. My impression from presentations in Montreal is
there was a mixed reaction.

> ===
> Section 4 (maybe 4.1?)
> It might be interesting to consider extensibility. For example, a
MIB
> module structure that is open to future protocol extensions or to
> proprietary extensions provide greater manageability.

I think that belongs in a "guidance for MIB designers" document, not
this document. The book "SNMP MIBs" provides hundreds of pages of MIB
design guidance.

> ===
> Section 4.3.1
>    [DISCUSS:: 'control plane' and 'data plane' are such slippery
terms
>    that I think they need to be defined.]
> Probably, this being mainly an IP-centric world, you could use:
> - control protocol fault
> - data forwarding fault

following Bert's suggestion, I eliminated the DISCUSS.

> ===
> Sections 4.6, 6.5, and 9
> I find the subtly of difference between 4.6 and 6.5 hard. Could the
> sections reference each other for some clarification?

section 4 is "guidelines for making a protocol manageable"; Section
4.6 is about monitoring performance. Did you mean 4.7, which is about
security management? Section 6 discusses specific standard data
models; Section 6.5 is about specific data models designed for
monitoring security protocols. We have  aproblen in the IETF. Security
WGs apparently think their protocols do not need to be manageable, so
we have a dearth of data models for managing security protocols.

I don't see a subtly of difference between section 4 and section 6. I
can see the possible confusion about the difference between 4.67 and
6.5. 

Text would be welcome. If you think some sentences from 6.5 belong in
4.7, or vice-vera, suggestions welcome. Concrete suggestions are more
useful to me than abstract observations.

> I think section 9 should at least reference 4.6 and 6.5.
> But we also need to consider security vulnerabilities introduced by
> management techniques. For example, if you cannot configure a 
> router, it
> is hard to make it do bad things. For example, OAM techniques can be
> used to swamp the forwarding plane achieving a DoS attack.

It is true that if you cannot configure a router it is hard to make it
do bad things. But it is also hard to make it do good things. What do
you consider the best current practice guideline on this point? Text
welcome.

It is also true that if you cannot provide power to a router it is
hard to make the router do bad things. Should we recommend that router
vendors not include power cords or power supplies with their products?

You have a good point that adding management (or any protocol) creates
new opportunities for security vulnerabilities. I don't know what you
want me to say. What specific text would you like to see inserted into
which section to address this issue?

> ===
> 
> Hope this is useful.
> 
> Cheers,
> Adrian 
> 
> 
> 
> 
> _______________________________________________
> OPS-AREA mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/ops-area
> 

_______________________________________________
OPS-AREA mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ops-area

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Mon, 12 Nov 2007 17:25:55 +0100

> -----Original Message-----
> From: David Harrington [mailto:[email-masked]] 
> Sent: Monday, November 12, 2007 6:21 PM
> To: 'Adrian Farrel'; [email-masked]
> Cc: [email-masked]
> Subject: [OPS-AREA] 
> draft-ietf-opsawg-operations-and-management-00.txt 
> 
> inline. 
> 
> inclusion 
> > in
> > or

I would add to the first phrase '... and to reviewers of such
documents.'

Dan

---

From: "Adrian Farrel" <[email-masked]>
Date: Mon, 12 Nov 2007 16:43:57 -0000

Hi,

>> The last sentence of the abstract is a bit convoluted. Suggest
[SNIP]
> covers aspects of operations and management that should be

WFM

>>    process as it is with the protocol as a finished product.  While
>>    we all agree  that it would be a good thing to imprint operational
>>    sensitivities into the consciousness of the protocol developer, I
>>    do not think that this is a practical goal.  The best that we can
>>    do is to set forth a list of objective criteria by which a protocol
>>    designer can evaluate whether the protocol that he/she has
>>    developed is manageable.]
>>
>> shoud also give some guidance about things to include/exclude
>> in order to achieve the goal of being manageable.
>

Agreed. That was jst me contributing to the discussion.

>>   ground.  Maybe it will develop into a framework document,
>>   supported by documents of the following sort:
>>   . what makes a MIB usable?
>>   . how much protocol state information needs to be exposed and how?
>>   . how much performance  information needs to be exposed and how?]
>>
>> by all but the management geeks (who we assume are already
>> the converted in this matter. Better to be short and pithy with
>> pointers to more information on specific topics in different places.
>> philosophy underlying the giving of guidance. maybe that
>> should be separated from the guidance itself and the
>> philosophy underlying the guidance.
>> by many people. That may be unfortunate, but it fact. I think
>> you have to get your base document down to around 15 pages.
>

OK. I'll take a look.

> then all these DISCUSSes will go away.

That helps.

> about how the guidelines should be used over time.

Hmmm. I wonder if we can replace the "philospohy text" with just that short 
statement?

>> MIB module structure that is open to future protocol extensions
>> or to proprietary extensions provide greater manageability.
>

Right. Perhaps I should not have given an example.
What I meant was that a manageability consideration is "extensibility." The 
general question to be answered by I-D authors is "How open to future 
protocol extensions are the management techniques you are defining?"

> useful to me than abstract observations.

Understood. Now I know what the intended drift is, I'll look at the text 
again.

>> router, it is hard to make it do bad things. For example, OAM
>> techniques can be used to swamp the forwarding plane achieving
>> a DoS attack.
>

Will try to make some concrete.

A