Subject: Re: [OPSAWG] OPSAWG]I-DAction:draft-ietf-opsawg-snmp-engineid-discovery-01.txt,

From: "Bert Wijnen" <[email-masked]>
Date: Fri, 1 Feb 2008 10:55:25 +0100

Resending, got bounced last night

Bert Wijnen

-----Oorspronkelijk bericht-----
31 Jan 2008 21:57:14 -0000
From: "Bert Wijnen" <[email-masked]>
To: <[email-masked]>
Cc: "Scott O. Bradner" <[email-masked]>,
	<[email-masked]>
Subject: RE: [OPSAWG]
Re:OPSAWG]I-DAction:draft-ietf-opsawg-snmp-engineid-discovery-01.txt,
Date: Thu, 31 Jan 2008 22:57:18 +0100
works for me.

Thanks,

Bert Wijnen

> -----Oorspronkelijk bericht-----
> Van: Juergen Schoenwaelder [mailto:[email-masked]]
> Verzonden: donderdag 31 januari 2008 22:53
> Aan: Bert Wijnen
> CC: Scott O. Bradner; [email-masked]
> Onderwerp: Re: [OPSAWG]
> Re:OPSAWG]I-DAction:draft-ietf-opsawg-snmp-engineid-discovery-01.txt,
>
>
> On Thu, Jan 31, 2008 at 06:02:24PM +0100, Bert Wijnen wrote:
>
> > > Good point. My proposal is the following change:
> > >
> > > OLD:
> > >
> > >    The localEngineID value always provides access to the
> default context
> > >    of an SNMP engine.
> > >
> > > NEW:
> > >
> > >    The localEngineID value always provides access to the
> default context
> > >    of an SNMP engine.  Note that the localEngineID value is
> intended to
> > >    be used as a contextEngineID.  It MUST NOT be used as a
> value in the
> > >    msgAuthoritativeEngineID field in the securityParameters
> of the User-
> > >    based Security Model (USM) [RFC3414].
> >
> > That is good. I think it also implies that it can never be the value
> > of snmpEngineID.0, right? Probably good to add that too.
>
> So what about this version:
>
>    The localEngineID value always provides access to the default context
>    of an SNMP engine.  Note that the localEngineID value is intended to
>    be used as a special value for the contextEngineID field in the
>    ScopedPDU.  It MUST NOT be used as a value to identify an SNMP
>    engine, that is this value MUST NOT be used in the snmpEngineID.0
>    scalar [RFC3418] or in the msgAuthoritativeEngineID field in the
>    securityParameters of the User-based Security Model (USM) [RFC3414].
>
> > >
> > >    IANA can assign new format values out of the originally
> assigned and
> > >    reserved number space 1-127.  For new assignments, a
> specification is
> > >    required as per [RFC2434].
> >
> > I think that is for new assignments by IANA, right.
> > Values between 128-255 inclusive do not need an specification in the
> > sense of RFC3434, do they? It is always good if such specs are available
> > somewhere, but we should not mandate them to be public, should we?
>
> So what about this:
>
>    IANA can assign new format values out of the originally assigned and
>    reserved number space 1-127.  For new assignments in this number
>    space, a specification is required as per [RFC2434].  The number
>    space 128-255 is enterprise specific and not controlled by IANA.
>
> /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/>
>

_______________________________________________
OPSAWG mailing list
[email-masked]
http://www.ietf.org/mailman/listinfo/opsawg