Subject: draft-shirey-secgloss-v2-08.txt

From: "David Harrington" <[email-masked]>
Date: Thu, 9 Aug 2007 09:32:51 -0400

Hi,

The issue was raised during ISMS WGLC that there is a difference
between our use of the word authenticate and the glossary in RFC2828.
Since ISMS extends SNMPv3, ISMS is using terminology consistent with
the SNMPv3 standard, which reflects English usage.

I think re-defining the word authenticate is not a good idea. I think
it will not help the IETF write clear and unambiguous specifications
to redefine words for IETF usage that are already clearly defined in
English. if we want new keywords, then the IETF should invent new
terms, not redefine existing terms.

I encourage the security community to provide an informational
glossary. I recommend that if a document author wants to use
terminology consistent with RFC2828bis, they should state that, and
list the specific RFC28282bis-consistent terms used in their document
in a "Terminology" section. 

But I do not think the glossary terms should be required usage in the
IETF, and if a document does use the RFC2828(bis) definitions, then I
think it would be a bad idea to simply claim consistency with
RFC2828bis. It will be tremendously hard to verify that every word or
phrase covered in RFC2828(bis) is used correctly in the document
claiming consistency with RFC2828(bis). It is already hard to verify
that MUST/SHOULD/MAY are used correctly per RFC2119, and RFC2828bis
has 300 pages of definitions, re-definitions, and phrases.

David Harrington
[email-masked]
[email-masked]

_______________________________________________
Ietf mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ietf

---

From: Stephen Kent <[email-masked]>
Date: Thu, 9 Aug 2007 10:17:12 -0400

>the SNMPv3 standard, which reflects English usage.

Could you identify the specific I-D with which this mismatch between 
the 2828(bis) definition  arises?

>terms, not redefine existing terms.

I would not make that argument in general, because technologies very 
often assign special or narrow definitions for common English words. 
In the IETF context, "tunnel" might be a good example, "peer," etc.

Steve

---

From: Sam Hartman <[email-masked]>
Date: Thu, 09 Aug 2007 15:28:11 -0400

>>>>> "David" == David Harrington <[email-masked]> writes:

    David> Hi, The issue was raised during ISMS WGLC that there is a
    David> difference between our use of the word authenticate and the
    David> glossary in RFC2828.  Since ISMS extends SNMPv3, ISMS is
    David> using terminology consistent with the SNMPv3 standard,
    David> which reflects English usage.

First, I'll only speak to 2828; 2828bis is not an IETF product and I
disclaim all interest in it.

    David> I think re-defining the word authenticate is not a good
    David> idea. I think it will not help the IETF write clear and
    David> unambiguous specifications to redefine words for IETF usage
    David> that are already clearly defined in English. if we want new
    David> keywords, then the IETF should invent new terms, not
    David> redefine existing terms.

It's my understanding that the definition of authenticate in 28282 is
a subset of the English definition.  If you don't think that is the
case I'd like to hear your reasoning.

    David> I encourage the security community to provide an
    David> informational glossary. I recommend that if a document
    David> author wants to use terminology consistent with RFC2828bis,
    David> they should state that, and list the specific
    David> RFC28282bis-consistent terms used in their document in a
    David> "Terminology" section.
Agreed.

    David> But I do not think the glossary terms should be required
    David> usage in the IETF, 

They are not required usage.  However to the extent that they are
agreed usage (and I think 2828 basically is), you need to have a good
reason for using a different definition of the same word.  "Please be
consistent with the terminology we tend to be using elsewhere" is a
reasonable (and often blocking) comment to make on a document.  There
are valid reasons to disagree with such a comment.

--Sam