Subject: Re: [Isms] WGLC comments - draft-ietf-isms-transport-security-model-05.txt

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 11 Sep 2007 10:04:52 +0200

On Thu, Aug 09, 2007 at 01:56:23PM +0200, Romascanu, Dan (Dan) wrote:
> 
> 1. Is RFC 2828 referred by other security-related documents? I find this
> document problematic, there is a revision on the table IESG table that
> has also problems and I decided that I cannot support it because among
> other inadequate terminology concerning SNMP and management aspects. The
> way it is mentioned in Section 1.2 may be interpreted that with the
> right timing this document could be relevant, which is not the case IMO.
> I would either ignore it, or just mention that the terminology in this
> document is not intended to be consistent with RFC 2828. 

There seems to be consensus that it is fine to stick with the SNMP
terminology here. Furthermore, it seems we are doing better if we
avoid an explicit reference to RFC 2828 since there is an update
pending. So I propose that David wordsmiths the text to say we use
SNMP terminology and to avoid explicit references to sources of other
terminology.
 
> 2. It would be good to include the comment that MIB objects defined here
> SHOULD not be referenced in other documents in the MIB module itself,
> maybe in the DESCRIPTION clause. 
> 
> 3. Bert already mentioned the issue of
> 
>         ::= { snmpModules xxxx }
> 
> Actually I believe there is a justification of consistency with the
> snmpUsmMIB which was defined prior to RFC 4181 if the authors believe
> that this is important, but I agree that snmpTsmMIB is a better MIB. 
> 
> If you do take this path, I believe that you should clarify in the IANA
> considerations section that the policy of further assignments of new
> values under snmpModules is Standards Action.

So I suggest we stick to snmpModules, change the OID descriptiors for
the module identity to have an snmp prefix, and document for IANA that
registrations under snmpModules requires a Standards Action.

> 4. Some abbreviations (MPM, ASI) are being reused from other SNMP
> documents as RFC 3411 without being expanded at first occurrence or the
> origin being referred to. 

editorial

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>

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

---

From: "tom.petch" <[email-masked]>
Date: Wed, 12 Sep 2007 15:07:59 +0200

----- Original Message -----
From: "Juergen Schoenwaelder" <[email-masked]>
To: "Romascanu, Dan (Dan)" <[email-masked]>
Cc: <[email-masked]>
Sent: Tuesday, September 11, 2007 10:04 AM
Subject: Re: [Isms] WGLC
comments -draft-ietf-isms-transport-security-model-05.txt

> SNMP terminology and to avoid explicit references to sources of other

RFC4949 has indeed superseded RFC2828 and I now understand that the former lacks
the community support enjoyed by the latter so I am content for the explicit
reference to an RFC to be omitted, keeping David's text about using terminology
consistent with STD62, something like

'This document favors terminology consistency with the existing  IETF SNMPv3
Standard (STD62) particularly with  regard to security.
This is consistent with the IESG
   decision not to require the SNMPv3 terminology be modified to reflect more
recent developments when SNMPv3From [email-masked] Wed Sep 12 10:21:59 2007
From: "tom.petch" <[email-masked]>
To: <[email-masked]>,
	"Romascanu, Dan (Dan)" <[email-masked]>
Subject: Re: [Isms] WGLC comments
	-draft-ietf-isms-transport-security-model-05.txt
Date: Wed, 12 Sep 2007 15:07:59 +0200
Cc: [email-masked]
Reply-To: "tom.petch" <[email-masked]>

----- Original Message -----
From: "Juergen Schoenwaelder" <[email-masked]>
To: "Romascanu, Dan (Dan)" <[email-masked]>
Cc: <[email-masked]>
Sent: Tuesday, September 11, 2007 10:04 AM
Subject: Re: [Isms] WGLC
comments -draft-ietf-isms-transport-security-model-05.txt

> SNMP terminology and to avoid explicit references to sources of other

RFC4949 has indeed superseded RFC2828 and I now understand that the former lacks
the community support enjoyed by the latter so I am content for the explicit
reference to an RFC to be omitted, keeping David's text about using terminology
consistent with STD62, something like

'This document favors terminology consistency with the existing  IETF SNMPv3
Standard (STD62) particularly with  regard to security.
This is consistent with the IESG
   decision not to require the SNMPv3 terminology be modified to reflect more
recent developments when SNMPv3 was advanced to Full Standard.'

I find this hard to write, needing to be clear what is being alluded to without
setting a load of hares running in all directions; needs to be coy but not too
coy.

Tom Petch
<snip>

---

From: "David Harrington" <[email-masked]>
Date: Mon, 17 Sep 2007 16:31:31 -0400

> -----Original Message-----
> From: Juergen Schoenwaelder 
> [mailto:[email-masked]] 
> Sent: Tuesday, September 11, 2007 4:05 AM
> To: Romascanu, Dan (Dan)
> Cc: [email-masked]

I checked with Dan, who said one of the goals of 4181 was to become
the reference for such controversies. 

The USM naming was done prior to the development of guideliens. But we
are now post-guidelines, So I will make naming and assignments
consistent with RFC4181.

dbh

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 18 Sep 2007 08:55:09 +0200

> are now post-guidelines, So I will make naming and assignments

Fine with me.

/js