Re: [Isms] tmsm pre-16 - mandatory transport model
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Isms] tmsm pre-16 - mandatory transport model
Hi,
I think the discussion of the mandatory-to-implement transport mode
would distract rather than help make the point that each transport
model should specify a mandatory-to-implement security mechanism. That
is the reason I did not make the requested change in the last
revision.
So I more closely focused the sentence:
To encourage a basic level of interoperability, any Transport
Model SHOULD define one minimum-compliance security mechanism, but
should also be able to support additional existing and new mechanisms.
dbh
> -----Original Message-----
> From: dave.shield at googlemail.com
> [mailto:dave.shield at googlemail.com] On Behalf Of Dave Shield
> Sent: Friday, February 06, 2009 6:11 AM
> To: j.schoenwaelder at jacobs-university.de; David Harrington
> Cc: isms at ietf.org
> Subject: Re: [Isms] tmsm pre-16 - mandatory transport model
>
> 2009/1/23 Juergen Schoenwaelder
> <j.schoenwaelder at jacobs-university.de>:
> > On Thu, Jan 22, 2009 at 03:43:13PM -0500, David Harrington wrote:
> >
> >> I think I have covered all the WGLC comments.
> >
> > Can the WG members please review the changes?
>
> One issue which I don't think has ever been discussed:
>
> In section 3.2.1, para 4 states:
>
> To encourage a basic level of interoperability, IETF
standards
> typically require one mandatory-to-implement
> specification, with the
> capability of adding new mechanisms in the future.....
>
> (and then goes on to talk about the implications of this for any
> given transport model).
>
> Does the same thing apply to the SNMP Transport Subsystem as
> a whole? Is there a mandatory transport model? If so, what?
>
> Even if this is simply a conceptual transport model based on
> the standard UDP transport mapping (i.e. RFC3417), it might
> be sensible to state this explicitly here.
>
> Dave
>
Note: Messages sent to this list are the opinions of the senders and do not imply endorsement by the IETF.