Hi,I think it would be advantageous to have a onr-paragrapgh boilerplate in each capabilitieas draft to explain this, just as most ietf drafts have a statement about rfc2119 teeminology, even though the full description is written in rfc2119.
1.5. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 9
1.6. Intended Audience . . . . . . . . . . . . . . . . . . . . 10
1.7. Format and Definition of Capabilities . . . . . . . . . . 10
1.8. Applicability . . . . . . . . . . . . . . . . . . . . . . 11
1.9. Intended Use . . . . . . . . . . . . . . . . . . . . . . . 11
dbh
From: owner-opsec@psg.com [mailto:owner-opsec@psg.com] On Behalf Of George Jones
Sent: Tuesday, July 25, 2006 6:06 AM
To: Zhao Ye
Cc: opsec@ops.ietf.org
Subject: Re: Comments on draft-zhao-opsec-routing-capabilities-02.txtOn 7/24/06, Zhao Ye < yezhao@huawei.com> wrote:> 1.2. Capabilities versus Requirements
>
> Capabilities may or may not be requirements. That is a local
> determination that must be made by each operator with reference to
> the policies that they must support. It is hoped that this
> document,
> together with [OSCP] will assist operators in identifying their
> security capability requirements and communicating them clearly to
> vendors.
>
> ...
> gmj> We need a standard text for this section to be used in all
> capability drafts.
> gmj> I will work on this.
> ...
Ok, waiting for your normative description.
It turns out that we don't need this at all in the capabilty drafts.
Section 1.7 of the framework covers it.
---George