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.