Subject: Re: [nmrg] SNMP over TCP transport mapping
From: Wes Hardaker <[email-masked]>
To: [email-masked]
Cc: Juergen Schoenwaelder <[email-masked]>, [email-masked], [email-masked]
Date: 31 May 2000 07:02:18 -0700

>>>>> On Tue, 30 May 2000 10:21:13 -0700, Lauren Heintz <[email-masked]> said:

Lauren> It just seems counter-intuitive to me to have the server
Lauren> (notification generator) initiate connections to clients.

>> Who says that the notification originator is the server?

Lauren> I'll rephrase: It seems counter-intuitive to me to have the NG
Lauren> be the client.

Lauren> The direction of data flow is not always the best indicator of
Lauren> who the server is; I believe connection mgmt issues more
Lauren> properly dictate this.  To have the NG be the client entails a
Lauren> single client, multiple server paradigm, which seems odd.

You're arguments are certainly interesting to consider.  However, I
too am (still) of the belief that the Notification Generator (NG) is
the side that should initiate the connections.  However, I do
understand your arguments in favor of the reverse.

Maybe it would be possible to specify both connection methods in the
document, although this seems rather difficult to do as far as
connection management goes.  Maybe it should be configured at both ends 
who opens the connection, but then it makes it less "easy-to-use" to
the end user that has to walk around to all his boxes and specify who
is the client and who is the server.

Anyway, consider the following problems with the Notification
Responder (NR) opening the TCP connection:

1) It is the responsible for making sure the connection is up and
   since it is not the one responsible for sending the data, this
   like a difficult chore.  How often should it attempt to make
   connections to the NG when the last attempt failed or was closed?
   Certainly when the remote NG comes up and tries to send a linkUp
   trap it'll be forced to use UDP since the NR couldn't have opened a 
   connection to it yet.

2) The sheer volume of connections required in a large network is huge
   problem.  Consider the (common) case where the number of network
   boxes is about the size of a class B network and there is one NR
   configured for most of the network (again, common place setup
   [though I'd argue that the network administrator has never had
   problems serious enough that caused his NR to be flooded with
   requests]).  Certainly, I don't want my NR to be attempting
   connections to all those devices.  I'd rather have each device open
   a connection when they thought they'd need to be sending data that
   warranted a TCP connection (as opposed to a UDP one).  Certainly I
   don't want the NR opening 255^2 connections that would be required
   to allow it to accept TCP notifications from each of those possible
   sources.

3) Many applications are short lived and may wish to send a trap or
   two while it is up and then shutdown again.  Certainly the NR
   couldn't predict the window when the application might be up and
   open a connection to it.

4) Multiple applications on the same host might need to send
   notifications, and hence multiple ports would have to be opened
   from the NR side.

Anyway, due to the above problems I hope you're not suggesting that
the NR always be the only one responsible for opening a connection for
notifications to be sent through.

-- 
Wes Hardaker
Distributed Computing Analysis and Support
University of California at Davis

Date: Mon, 29 May 2000 17:05:08 +0200
From: Juergen Schoenwaelder <[email-masked]>
To: [email-masked]
CC: [email-masked], [email-masked], [email-masked]
Subject: Re: [nmrg] SNMP over TCP transport mapping
Sender: [email-masked]
Status: RO

>>>>> D Harrington writes:

D> Comments on SNMP over TCP (draft-irtf-nmrg-snmp-tcp-04.txt)

D> 1) footer/header correction - incorrect title

fixed
	
D> 2) I am unaccustomed to seeing organization names incorporated into
D> the MIB module name and the MODULE-IDENTITY except for private
D> MIBs. I am also concerned that having IRTF in the name may cause
D> people to consider it purely research and not really usable. Can
D> these be made more generic?

see previous response

D> 3) Section 3 says "applications using SNMP over TCP may choose to
D> switch". Would it be more appropriate to say "engines using SNMP
D> ..."?

fixed

D> 4) Section 3 has just a touch of ambiguity between "MUST NOT change
D> during a transaction" and "refusing new TCP connections whenever
D> necessary". If we dispense with the assumption that a connection is
D> opened for a whole transaction, then it is possible that a new
D> connection for returning the response for a processed request could
D> be refused. Should we add "except during a transaction"?

Good point. So far we always assumed that a transaction is carried
over a single TCP connection. This needs to be clarified, either by
making this assumption explicit or by documenting what happens in this
case.

D> 5) "requires to transfer" should be "requires the transfer of"

fixed

D> 6) section 3.3 says "However, SNMP engines MUST NOT discard SNMP
D> requests if only the incoming half of the TCP connection is
D> closed." It is not obvious to me why this is a MUST NOT. Can you
D> add explanatory text that explains the problem with discarding the
D> request?

see previous response

D> 7) "halfs" should be "halves"

fixed

D> 8) 'noResponse' is not an SNMP error code. Is it defined someplace,
D> or is this recommended signal an implementation-dependent action?
D> Should there be a recommended SNMP error code for this condition,
D> to be returned to the requesting application? or should this just
D> be part of the implementation-specific handling of timeouts and
D> other connection loss conditions?

see previous response

D> 9) I have a concern with section 3.4. It is important that
D> developers not think that the *contents* of an Inform are
D> guaranteed to have been processed when the response is
D> received. The receiving engine only acknowledges receipt of the
D> inform. I suggest a rewording:

D> "There is an important difference between an unconfirmed protocol
D> operation sent over a reliable transport and a confirmed protocol
D> operation. A reliable transport such as TCP reports that it has
D> delivered data to the application process. It does not guarantee
D> that

D> the data was actually processed in any way by the application
D> process."

D> "With a confirmed SNMP operation, the receiving SNMP engine
D> acknowledges that the data was actually received. Depending on the
D> SNMP operation, a confirmation may indicate that further processing
D> was done. For example, ..."

D> "A reliable transport is thus only a poor approximation for
D> confirmed operations. Applications that need confirmation of
D> delivery or processing are encouraged to use the confirmed
D> operations, such as the InformRequest-PDU, rather than using
D> unconfirmed operations, such as traps, over a reliable transport."

I have integrated the suggested wordings.

D> 10) Is it appropriate to cite URLS in references, given how often
D> URLs change in today's world?

see previous response

D> 11) Should this document use some O&M boilerplate text, such as the
D> MIB boilerplate and the security considerations?

see previous response

Thanks for your comments and the suggested new wordings.

/js

-- 
Juergen Schoenwaelder      Technical University Braunschweig
<[email-masked]>  Dept. Operating Systems & Computer Networks
Phone: +49 531 391 3289    Bueltenweg 74/75, 38106 Braunschweig, Germany
Fax:   +49 531 391 5936    <URL:http://www.ibr.cs.tu-bs.de/~schoenw/>

Date: Mon, 29 May 2000 16:52:51 +0200
From: Juergen Schoenwaelder <[email-masked]>
To: [email-masked]
CC: [email-masked], [email-masked], [email-masked]
Subject: Re: [nmrg] SNMP over TCP transport mapping
Sender: [email-masked]
Status: RO

>>>>> D Harrington writes:

dbh> Comments on TCP over SNMP draft

dbh> 1) I think it is atypical to include the name of the authoring
dbh> group in the module name, and it will make it difficult to
dbh> remember. This also applies to the MODULE-IDENTITY.

The prefix allows to move the definitions to the "right" place if they
ever go onto the standards track. Of course, if people implement and
field the experimental version, then renaming/renumbering will be
harder later on. I am open to suggestions - but I guess some folks
will scream if the NMRG allocates domains below snmpDomains.

Given this, we decided to register everything below the experimental
node assigned for the NMRG. Since the IRTF is the hosting
organization, we decided to use IRTF-NMRG-SNMP-TM to even prevent name
clashes in the IRTF. (Perhaps this is really unlikely and IRTF-SNMP-TM
would do the job as well. Opinions welcome.)

dbh> 2) I know the issue of IPv6 addresses has been raised numerous
dbh> times in the SNMP community. It is my impression that the
dbh> community has decided to defer the issue, and supplement existing
dbh> definitions in the future by defining addition objects and
dbh> textual conventions. On that basis, I consider this IPv4 only
dbh> mapping adequate.

There will be an ID pretty soon which tries to define generic TCs and
domains for transport addresses. I think the SNMPv3 needs to take a
close look at it since this ID may pave the way for SNMPv3 over IPv6
transport mappings.

dbh> 3) In section 3.3, "halfs" should be "halves"

fixed

dbh> 4) "However, SNMP engines MUST NOT discard SNMP requests if only
dbh> the incoming half of the TCP connection is closed." The text
dbh> doesn't explain WHY this rule must be observed, and the reasoning
dbh> is not obvious to me.  Can this be expanded?

See the other postings related to this. It allows some TCP
optimization - but it is unclear right now whether the benefits
outweight the implementation costs and risks that people do not get it
right.

dbh> 5) section 3.3 calls for a noResponse error condition. Where is
dbh> this error condition defined? Shouldn't the engine also return an
dbh> SNMP error code, as enumerated in rfc1905? Which error code would
dbh> be appropriate - genErr? or should it be handled by
dbh> application-specific timeout handler code?

It refers to an application specific timeout handler code. I will try
to make that clearer.

dbh> 6) section 3.4 says "A confirmed operation indicates that the
dbh> data was actually delivered and processed by the receiving
dbh> application process."  I find this slightly misleading. I
dbh> consider it important that developers realize that the receiver
dbh> has the option of not processing the *contents* of the Inform.

dbh> Could we add ", at least to some degree" to this sentence? The
dbh> following examples then illustrate varying degrees.

dbh> Alternately, could we reword to "With a reliable transport, the
dbh> transport layer reports that the data was delivered to an upper
dbh> (application) layer process."  "With a confirmed operation, the
dbh> application process acknowledges that the data was actually
dbh> received."

I will try to find better wordings.

dbh> 7) Is it appropriate to reference URLs in references?

They are not normative and I think they are helpful in an experimental
document such as this.

dbh> 8) should this have some of the standard boilerplate stuff? the
dbh> boilerplate for MIB documents, the security considerations, etc.?
dbh> Does it meet all the RFC2223 requirements?

I will add the boilerplate and a security section.

Thanks for your comments.

/js

-- 
Juergen Schoenwaelder      Technical University Braunschweig
<[email-masked]>  Dept. Operating Systems & Computer Networks
Phone: +49 531 391 3289    Bueltenweg 74/75, 38106 Braunschweig, Germany
Fax:   +49 531 391 5936    <URL:http://www.ibr.cs.tu-bs.de/~schoenw/>

Date: Mon, 29 May 2000 15:57:40 +0200
From: Juergen Schoenwaelder <[email-masked]>
To: [email-masked]
CC: [email-masked], [email-masked]
Subject: Re: [nmrg] SNMP over TCP transport mapping
Sender: [email-masked]
Status: RO

>>>>> Bill Fenner writes:

Bill> Half-closed connections are not necessarily trouble.  Consider a
Bill> bulk transfer request that can be sent in a single packet
Bill> (SYN+data+FIN); the reply can occur on the other half of the TCP
Bill> connection while the request side is already closed.

Nobody says that half-closed connections are a bad thing. 

I think the question here is whether optimizations like the one
described above make a real difference in operational environments and
whether the benefits of allowing them are well balanced with the
implementation costs for supporting half-closed connections in all
implementations and the risks of potential interoperablity problems if
implementors do not get things right.

[A good test is probably to challenge the implementations we have
 today to see whether they handle half-closed connections correctly.]

/js

-- 
Juergen Schoenwaelder      Technical University Braunschweig
<[email-masked]>  Dept. Operating Systems & Computer Networks
Phone: +49 531 391 3289    Bueltenweg 74/75, 38106 Braunschweig, Germany
Fax:   +49 531 391 5936    <URL:http://www.ibr.cs.tu-bs.de/~schoenw/>

Date: Mon, 29 May 2000 12:01:06 +0200
From: Juergen Schoenwaelder <[email-masked]>
To: [email-masked]
CC: [email-masked], [email-masked]
Subject: Re: [nmrg] SNMP over TCP transport mapping
Sender: [email-masked]
Status: RO

>>>>> Lauren Heintz writes:

Lauren> It seems to me that with TCP (and keepalives), a trap receiver
Lauren> application can be better designed to *minimize* polling while
Lauren> achieving high assurance (maybe even 100% ?) that it knows
Lauren> about all outstanding alarm situations at any given moment.
Lauren> At this point SNMP trap delivery becomes *just* as reliable
Lauren> as, for example, Corba delivery mechanisms.

I do not agree with the "nearly or maybe even 100%" statement. If the
_sender_ needs to know that his notification reached the receiver(s),
then there is no way around an application level acknowledgment. I
think IIOP - the protocol behind CORBA - also acknowledges a method
invocation unless the method is declared to be oneway. (I guess that
CORBA event services are not oneway - but I am not 100% without
looking this up.)

Lauren> Also, some markets just don't seem willing to accept the
Lauren> inform/response model -- I guess believing that TCP mechanisms
Lauren> provide for sufficient reliability with lower overhead?  If
Lauren> true, this doc should indicate that SNMP now meets their
Lauren> needs.

The SNMP over TCP specification is a technical document and I think it
should say what technically is the right answer. For this document, it
does not really matter what the market believes. I think the IETF and
especially the IRTF makes itself superfluous if they start to document
what the market believes rather than the correct technical solutions
to a given problem.

Lauren> It just seems counter-intuitive to me to have the server
Lauren> (notification generator) initiate connections to clients.

Who says that the notification originator is the server? 

Lauren> I'm not suggesting the doc describe an algorithm for managing
Lauren> connections, only that because it specifies connections are
Lauren> initiated by the server, both server and client
Lauren> implementations will suffer, and maybe not be as
Lauren> interoperable.

Only the notification originator knows when it has to send a
notification and to one or multiple notification receivers. So it is
the notification originator who can implement reasonable algorithms to
keep the amount of resources spend for open connections balanced. It
is also the notification originator who has to deal with error
situations in case he needs to send a notification but the transport
fails.

/js

-- 
Juergen Schoenwaelder      Technical University Braunschweig
<[email-masked]>  Dept. Operating Systems & Computer Networks
Phone: +49 531 391 3289    Bueltenweg 74/75, 38106 Braunschweig, Germany
Fax:   +49 531 391 5936    <URL:http://www.ibr.cs.tu-bs.de/~schoenw/>

Date: Fri, 26 May 2000 17:49:00 +0200
From: Juergen Schoenwaelder <[email-masked]>
To: [email-masked]
CC: [email-masked], [email-masked]
Subject: Re: [nmrg] SNMP over TCP transport mapping
Sender: [email-masked]
Status: RO

>>>>> Lauren Heintz writes:

Lauren> I have some comments....

Lauren> 3. (1st par) - I've already seen one telecom Element Mgmt
Lauren> System opt to use Corba alarm delivery methods instead of
Lauren> relying on SNMP UDP traps.  I would therefore suggest the
Lauren> following rewording of the 1st par to say something like:

Lauren>    SNMP over TCP is an optional transport
Lauren> mapping. Implementors are encouraged to support SNMP over TCP
Lauren> whenever possible because this enables applications to make
Lauren> more efficient bulk transfers of MIB data [7] and also to
Lauren> provide more reliable delivery of alarm messages (i.e traps).

No. In fact, the purpose of section 3.4 is actually to explain why TCP
does not provide for more reliable delivery of alarm messages. If your
management system depends on the delivery of alarm messages, then you
need confirmed operations. (Perhaps an indication that the text in
section 3.4 is not clear enough...)

Lauren> 3.1 - I think it's not clearly stated that two or more
Lauren> messages on the same connection MUST not be interleaved
Lauren> together.  RFC2741, for example, contains the following text:

Lauren>    The AgentX entity must not "interleave" AgentX PDUs within
Lauren> the TCP byte stream.  All the bytes of one PDU must be sent
Lauren> before any bytes of a different PDU.  The receiving entity
Lauren> must be prepared for TCP to deliver byte sequences that do not
Lauren> coincide with AgentX PDU boundaries.

It was so obvious to us that this does not make sense so that nobody
cared to write something about it. But such a warning may certainly
be helpful for others.

Lauren> 3.1 - I gather it's OK for the responding entity to transmit
Lauren> responses in an order other than that originally received.

Yes. I agree that the text should say that explicitly.

Lauren> 3.2 - Since the notification receiver (NR) is to listen for
Lauren> connections, does this imply that an SNMP entity that supports
Lauren> the target and notification MIBs would implicitly create
Lauren> connections to one or more notification receivers at some
Lauren> point during MIB configuration, possibly as a side effect to a
Lauren> SET request?  If so, how and when so?  If an NR is taken down
Lauren> temporarily but the target/notify MIBs don't change, does the
Lauren> NG attempt another connection?  Has there been any thought to
Lauren> having the notification generator instead do the listening and
Lauren> letting the NRs explicitly initiating connections?  Seems that
Lauren> connection mgmt is easier for NRs, not to mention that the
Lauren> number of connections might be more easily minimized in
Lauren> environments where such matters are critical.

The document does not try to dictate an algorithm for managing
connections. I have implemented a strategy which keeps a pool of
connections open that are closed if they are inactive or if new
connections must be establised. This means that I would not open
connections to all potential notification receivers just in case there
might be a notification to send. But this is certainly implementation
dependent and I can even imagine to have different algorithms in a
single package so the user can control which works best in a given
environment.

Anyway, thanks for your comments.

/js

-- 
Juergen Schoenwaelder      Technical University Braunschweig
<[email-masked]>  Dept. Operating Systems & Computer Networks
Phone: +49 531 391 3289    Bueltenweg 74/75, 38106 Braunschweig, Germany
Fax:   +49 531 391 5936    <URL:http://www.ibr.cs.tu-bs.de/~schoenw/>

Date: Fri, 26 May 2000 17:37:34 +0200
From: Juergen Schoenwaelder <[email-masked]>
To: [email-masked]
CC: [email-masked], [email-masked]
Subject: Re: [nmrg] SNMP over TCP transport mapping
Sender: [email-masked]
Status: RO

>>>>> Dave Shield writes:

Dave>   Section 3.1, paragraph 2 "It is possible to exchange multiple
Dave> SNMP request/response pairs over a single connection".

Dave>    Is this intended to imply a tightly-locked
Dave> request/response/request/response alternation, or are
Dave> implementors expected to support an asynchronous model
Dave> (e.g. request/request/response/request/response/response) ?  [I
Dave> presume the latter, but it could be read as the former]

Your assumption is right. But I agree that we need to be more explicit
to avoid mis-understandings.

Dave>    Is this connection intended to support bidirectional
Dave> requests, or will the application opening the connection always
Dave> act as the originating engine ?  This is particularly relevant
Dave> for notification messages, which could travel in either
Dave> direction.

Kind of unlikely for notification messages. But we should probably say
something about it.

Dave>   Section 3.3, paragraph 2

Dave>     The second sentence doesn't really make sense.  "The
Dave> transport of SNMP messages over UDP requires to transfer large
Dave> amounts ...."  ^^^^^^^^^^^

Dave>   I can understand what it's trying to say, but it's not
Dave> particularly clear.

I will try to fix up the wordings.

Dave>   Section 3.3, paragraph 3

Dave>   An application needs to support SNMP over UDP as well, so
Dave> *will* require the application-level transport management.  The
Dave> "simpler management application" is unlikely to be realised.

Yep.

Dave>   Section 3.4, paragraph 4

Dave>   This refers to "... data passed the transport ...."

Dave> Again, it's reasonably clear what this means, but it doesn't
Dave> read properly.

Will try to fix it in the next revision.

Thanks for your comments.

/js

-- 
Juergen Schoenwaelder      Technical University Braunschweig
<[email-masked]>  Dept. Operating Systems & Computer Networks
Phone: +49 531 391 3289    Bueltenweg 74/75, 38106 Braunschweig, Germany
Fax:   +49 531 391 5936    <URL:http://www.ibr.cs.tu-bs.de/~schoenw/>

Date: Fri, 26 May 2000 17:32:19 +0200
From: Juergen Schoenwaelder <[email-masked]>
To: [email-masked]
CC: [email-masked], [email-masked]
Subject: Re: [nmrg] SNMP over TCP transport mapping
Sender: [email-masked]
Status: RO

>>>>> Randy Presuhn writes:

Randy> This might be a pain to implement consistently across platforms
Randy> with different TCP/IP stacks and socket libraries.  Wouldn't it
Randy> be simpler for applications to just close the socket if either
Randy> the incoming or the outgoing half is in trouble?  Otherwise,
Randy> the half-closed socket would need to be excluded from
Randy> poll/select lists input checking (since the descriptor would
Randy> always come up ready for read) but be left in the write list
Randy> until the application decides to close the socket after writing
Randy> the response.

This is certainly an option to consider. I agree that not dealing with
half closed connections simplifies implementations and is likely to
increase interoperability. I will take this back to the NMRG for
discussion.

Thanks for your comments (and sorry for delayed reaction).

/js

-- 
Juergen Schoenwaelder      Technical University Braunschweig
<[email-masked]>  Dept. Operating Systems & Computer Networks
Phone: +49 531 391 3289    Bueltenweg 74/75, 38106 Braunschweig, Germany
Fax:   +49 531 391 5936    <URL:http://www.ibr.cs.tu-bs.de/~schoenw/>

Date: Fri, 26 May 2000 13:52:30 +0200
From: Juergen Schoenwaelder <[email-masked]>
To: [email-masked]
CC: [email-masked], [email-masked], [email-masked]
Subject: Re: [nmrg] SNMP over TCP transport mapping
Sender: [email-masked]
Status: RO

>>>>> Ayers, Mike writes:

Mike> Equally open to exploitation by barracksroom lawyers, I
Mike> suspect.  How about:

>     The SNMP over TCP transport mapping is an optional transport
>     mapping. SNMP Applications that respond to messages sent via
>     TCP MUST also respond to messages sent via the UDP transport
>     mapping as defined in RFC 1906 <xref target="refs.RFC1906"/>
>     and MUST NOT preferentially process messages sent via TCP.

[...]

Mike> 	Okay, beat me up now...  ;-)

I think we can't require that every implementation must _respond_ to
messages sent via the UDP transport mapping. We can only require that
implementations are in principle able to do so if the user configured
it to do so. In other words, we can only require that every conforming
implementation _implements_ the UDP transport mapping.

I also have serious doubts that we should put out requirements how
received messages are handled internally. We have avoided that in the
past and I do not see a good reason to do it now. (BTW, there is
nothing in RFC 1906 which says similar things for agents that e.g.
support SNMP over IPX and SNMP over UDP.)

And once again: This SNMP over TCP mapping document is _not_ going on
the standards track. So any discussion about compliance is IMHO
misplaced (which was one of the main reasons why I rewrote the text
Keith proposed - because he argued about compliance).

The "since clause" in my proposal had the only purpose to give an
explanation for the requirement stated before. Keith and others have
problems with this explanation, so I propose to just nuke it. This
leads to:

>     The SNMP over TCP transport mapping is an optional transport
>     mapping. SNMP protocol engines that implement the SNMP over
>     TCP transport mapping MUST also implement the SNMP over UDP
>     transport mapping as defined in RFC 1906 <xref
>     target="refs.RFC1906"/>.

I really think this is all we can do.

Everything else goes into the old SNMP tradition to not only define
the protocol, but also trying to setup rules how people are
"permitted" to use the technology. (Don't get me wrong: I am all in
favour of recommendations on how to best use a technology. But this
clearly belongs into BCP like documents and should not be hard-wired
into MUSTs or MUST NOTs in (experimental) protocol specifications.)

/js

-- 
Juergen Schoenwaelder      Technical University Braunschweig
<[email-masked]>  Dept. Operating Systems & Computer Networks
Phone: +49 531 391 3289    Bueltenweg 74/75, 38106 Braunschweig, Germany
Fax:   +49 531 391 5936    <URL:http://www.ibr.cs.tu-bs.de/~schoenw/>

Date: Fri, 26 May 2000 11:06:21 +0200
From: Juergen Schoenwaelder <[email-masked]>
To: [email-masked]
CC: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: [nmrg] SNMP over TCP transport mapping
Sender: [email-masked]
Status: RO

>>>>> Moshe Rozenblit writes:

Moshe> I have some concerns about mandating UDP for SNMP. Those
Moshe> concerns fall into 3 categories: architecture, security, and
Moshe> "Big Brother".

[...]

I think we are mixing two things up here. I think we need to clearly
distinguish between (a) what is required for an SNMP implementation to
be conformant and (b) what the operators options are to configure and
use conformant SNMP implementations.

I agree that every conformant implementation should support SNMP over
UDP since this is what guarantees interoperability. This is something
the WG should worry about and specify. But the fact that SNMP over UDP
is required for implementation conformance does not mean it is
"illegal" for an operator to decides to generally disable SNMP over
UDP. It is certainly the operators choice and he certainly has to take
responsibility what he is doing. The WG should IMHO not try to forbid
certain end user configurations. In fact, recommendations about how to
configure (or not to configure) systems in certain environments is
something that may be best dealt with in a BCP document.

Anyway, the whole debate is somewhat moot since SNMP over TCP is going
for experimental and talking about compliance in this context is a bit
strange. What is far more important are the wordings that end up in
the RFC 1906 revision. I personally think the text in RFC 1906 is not
as clear as it should be since it talks about "preferred mappings" and
"proxy service" and you can very well debate what that means. This
perhaps also explains my final comment in my posting yesterday on the
rfc1157Domain resolution.

/js

-- 
Juergen Schoenwaelder      Technical University Braunschweig
<[email-masked]>  Dept. Operating Systems & Computer Networks
Phone: +49 531 391 3289    Bueltenweg 74/75, 38106 Braunschweig, Germany
Fax:   +49 531 391 5936    <URL:http://www.ibr.cs.tu-bs.de/~schoenw/>

Date: Sat, 20 May 2000 14:28:25 +0200
From: Juergen Schoenwaelder <[email-masked]>
To: [email-masked]
CC: [email-masked], [email-masked]
Subject: Re: [nmrg] SNMP over TCP transport mapping
Sender: [email-masked]
Status: RO

Keith> It is non-compliant to this specification to implement and
Keith> enable SNMP over TCP without also implementing and concurrently
Keith> enabling SNMP over UDP.

Wes> I definitely think its well worth saying, regardless.

What about the following text:

    The SNMP over TCP transport mapping is an optional transport
    mapping. Implementations that implement SNMP over TCP must also
    implement the SNMP over UDP transport mapping as defined in RFC
    1906 <xref target="refs.RFC1906"/> since SNMP over UDP provides
    for the greatest level of interoperability.

I think the above text is also pretty clear and it avoids to talk
about compliance to an experimental document.

/js

-- 
Juergen Schoenwaelder      Technical University Braunschweig
<[email-masked]>  Dept. Operating Systems & Computer Networks
Phone: +49 531 391 3289    Bueltenweg 74/75, 38106 Braunschweig, Germany
Fax:   +49 531 391 5936    <URL:http://www.ibr.cs.tu-bs.de/~schoenw/>

To: Keith McCloghrie <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: [nmrg] SNMP over TCP transport mapping
From: Wes Hardaker <[email-masked]>
Organization: U.C.Davis, Information Technology - D.C.A.S.
Date: 19 May 2000 16:44:22 -0700
Lines: 18
Sender: [email-masked]
Status: RO

>>>>> On Fri, 19 May 2000 13:46:27 -0700 (PDT), Keith McCloghrie <[email-masked]> said:

Keith> It is non-compliant to this specification to implement and enable
Keith> SNMP over TCP without also implementing and concurrently enabling
Keith> SNMP over UDP.

Keith> One can argue that compliance doesn't mean much in an
Keith> Experimental RFC, but nevertheless, I suggest that the simplest
Keith> and strongest way to say it.

I definitely think its well worth saying, regardless.  That way if it
ever does move towards something stronger than Experimental the note
will not be forgotten.

-- 
Wes Hardaker
Distributed Computing Analysis and Support
University of California at Davis

Date: Tue, 16 May 2000 14:55:13 +0200
From: Juergen Schoenwaelder <[email-masked]>
To: [email-masked]
CC: [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: [nmrg] SNMP over TCP transport mapping
Sender: [email-masked]
Status: RO

>>>>> Keith McCloghrie writes:

Keith> Thus, I suggest the Internet-Draft needs to strength the
Keith> following paragraph:

Keith>    A reliable transport is thus only a poor approximation for
Keith> confirmed operations. Applications that need confirmed delivery
Keith> of notifications are thus encouraged to use the confirmed
Keith> InformRequest-PDU rather than just sending unconfirmed traps
Keith> over a reliable transport.

Keith> "encouraged to use" here needs to be "can only depend upon"

I agree.

Keith> No doubt it also needs to provide additional rationale and
Keith> "evidence" (such as I present above) in order to overcome the
Keith> all too common misunderstanding of what "TCP is reliably"
Keith> means.

I have added some more text on this issue, although I think that a
really detailed explanation probably belongs into a separate document.
The misunderstanding of what "TCP is reliable" means is not only
present in the SNMP world.

Thanks for your comments.

/js

-- 
Juergen Schoenwaelder      Technical University Braunschweig
<[email-masked]>  Dept. Operating Systems & Computer Networks
Phone: +49 531 391 3289    Bueltenweg 74/75, 38106 Braunschweig, Germany
Fax:   +49 531 391 5936    <URL:http://www.ibr.cs.tu-bs.de/~schoenw/>

Date: Tue, 16 May 2000 13:31:49 +0200
From: Juergen Schoenwaelder <[email-masked]>
To: [email-masked]
CC: [email-masked], [email-masked], [email-masked]
Subject: Re: [nmrg] SNMP over TCP transport mapping
Sender: [email-masked]
Status: RO

>>>>> Mike Daniele writes:

Mike> A couple of things in section 3.3 confused me.

>> However, SNMP engines MUST NOT discard SNMP requests if only the
>> incoming half of the TCP connection is closed.

Mike> What is a half of a connection?  When one side closes, the
Mike> connection is gone.

Bill already provided an answer. You can close one half of the
bidirectional TCP connection. The purpose of the text is to explain
that an engine should continue processing SNMP messages as long as the
connection used to send a response is open.

I will try to reword this by saying what an engine is required to do
(instead of saying what it is not expected to do). Hope this will help
to clarify this point.

>> A `noResponse' error condition SHOULD be signalled for outstanding
>> requests for command generator applications if the TCP connection
>> is closed before a response has been received.

Mike> Should be signalled by (not for) the command generator
Mike> application, right?

Yes. Fixed.

Thanks for your feedback.

/js

-- 
Juergen Schoenwaelder      Technical University Braunschweig
<[email-masked]>  Dept. Operating Systems & Computer Networks
Phone: +49 531 391 3289    Bueltenweg 74/75, 38106 Braunschweig, Germany
Fax:   +49 531 391 5936    <URL:http://www.ibr.cs.tu-bs.de/~schoenw/>

Date: Fri, 12 May 2000 09:25:00 +0200
From: Juergen Schoenwaelder <[email-masked]>
To: [email-masked]
CC: [email-masked]
Subject: Re: [nmrg] Apologies
Sender: [email-masked]
Status: RO

>>>>> Ron Sprenkels writes:

Ron> My apologies for clutering this list with my obvious selection of
Ron> the wrong email alias; nmrg is to similar to nm for my email
Ron> program :-( Won't happen again I hope.

Perhaps you too need some sleep. :-)

/js

Date: Fri, 12 May 2000 09:21:58 +0200
From: Ron Sprenkels <[email-masked]>
To: Network Management Research Group <[email-masked]>
Subject: [nmrg] Apologies
Sender: [email-masked]
Status: RO

Hi everybody,

My apologies for clutering this list with my obvious selection of the wrong
email alias; nmrg is to similar to nm for my email program :-( Won't happen
again I hope. 

Ron.

--------------------------------------------------------------------------
Ron Sprenkels  [email-masked]   http://www.cs.utwente.nl/~sprenkel
University of Twente, Department of Computer Science, TSS Management group
P.O. Box 217, 7500 AE Enschede, The Netherlands.    (Tel. +31 53 489 4663)

Date: Fri, 12 May 2000 09:18:34 +0200
From: Ron Sprenkels <[email-masked]>
To: Network Management Research Group <[email-masked]>
Subject: [nmrg] Coming in later this morning
Sender: [email-masked]
Status: RO

Hi,

This morning I'll be at home, to let Joyce catch up on some needed sleep.
I'll probably be in around lunch time. If you need me before lunch, feel
free to email or call me.

Ron.

--------------------------------------------------------------------------
Ron Sprenkels  [email-masked]   http://www.cs.utwente.nl/~sprenkel
University of Twente, Department of Computer Science, TSS Management group
P.O. Box 217, 7500 AE Enschede, The Netherlands.    (Tel. +31 53 489 4663)

To: [email-masked]
Subject: [nmrg] ucd-snmp tcp support on a public test agent
From: Wes Hardaker <[email-masked]>
Organization: U.C.Davis, Information Technology - D.C.A.S.
Date: 11 May 2000 12:55:27 -0700
Lines: 14
Sender: [email-masked]
Status: RO

The ucd-snmp demonstration/interoperability agent (see
http://ucd-snmp.ucdavis.edu/snmpv3.html) now supports the tcp layer as well.

I've actually been meaning to do this for a while, but I only got
around to enabling the ability for the agent to open multiple ports
yesterday.  Anyway, if anyone else is working on TCP support for
management apps, you're welcome to use our host as a target for
interoperability tests.  See the above URL for security names, etc.

-- 
Wes Hardaker
Distributed Computing Analysis and Support
University of California at Davis

From: "Wijnen, Bert (Bert)" <[email-masked]>
To: [email-masked], "Carl W. Kalbfleisch" <[email-masked]>
Cc: Network Management Research Group <[email-masked]>
Subject: RE: [nmrg] SNMP over TCP transport mapping
Date: Wed, 10 May 2000 23:25:43 +0200
Sender: [email-masked]
Status: RO

There is a widespread mis-understanding of what it means for a
document to be Informational, Experimental or Standards track.

Many people believe that Experimental means "you're doomed".
Not so. Experimental means that we have a specification. We're
not sure yet we all agree on all the technicalities and specifications.
But we do want people to play and experiment with it, so that we
can figure out if the specification makes sense, and is usefull and
what needs to be fixed/changed etc.
Multiple specs that try to address/solve the same problem (space)
may go as experimental so that we can find out by experience as
to which protocol/specification  makes the most sense to 
standardize.

So certainly, Experimental allows to later move it forward onto
the standards track. It is also possible that we find out that it
was a bad idea, in which case we probably reclassify it as historic.

HHHope this expalins/helps,
Bert

> ----------
> From: 	Carl W. Kalbfleisch[SMTP:[email-masked]]
> Sent: 	Wednesday, May 10, 2000 10:55 PM
> To: 	Wijnen, Bert (Bert); [email-masked]
> Cc: 	Network Management Research Group
> Subject: 	RE: [nmrg] SNMP over TCP transport mapping
> 
> 
> Bert,
> 
> What are the implications of publishing as experimental verses standards
> track? Could it be moved to standards track later?
> 
> Carl
> 
> > -----Original Message-----
> > From: [email-masked]
> > [mailto:[email-masked]]On Behalf Of Wijnen, Bert (Bert)
> > Sent: Tuesday, May 09, 2000 4:52 AM
> > To: [email-masked]
> > Cc: Network Management Research Group
> > Subject: RE: [nmrg] SNMP over TCP transport mapping
> >
> >
> > I have not (yet) seen any comments on this document.
> > So I am starting to assume that the SNMP community at large
> > thinks that this is a usefull document and that if we get a
> > request to publish it as an Experimental RFC, that I can
> > report that the SNMP community seems OK with it.
> > If such is the case, then at least a few expressions of
> > agreement would be great too.
> >
> > Thanks,
> > Bert
> >
> > > ----------
> > > From: 	Juergen Schoenwaelder[SMTP:[email-masked]]
> > > Sent: 	Monday, May 01, 2000 1:56 PM
> > > To: 	[email-masked]
> > > Cc: 	Network Management Research Group
> > > Subject: 	[nmrg] SNMP over TCP transport mapping
> > >
> > >
> > > The NMRG is ready to submit the SNMP over TCP transport mapping for
> > > publication as Experimental RFC. This transport mapping is one of
> > > several SNMP extensions to make bulk transfers more efficient. The
> > > location of the current ID is:
> > >
> > >     ftp://ietf.org/internet-drafts/draft-irtf-nmrg-snmp-tcp-04.txt
> > >
> > > The purpose of this message is to make the larger SNMP community aware
> > > of this piece of work and to give you a chance to raise any comments
> > > before we actually submit the ID to the RFC editor. Please raise any
> > > comments before May 12th.
> > >
> > > /js
> > >
> > > --
> > > Juergen Schoenwaelder      Technical University Braunschweig
> > > <[email-masked]>  Dept. Operating Systems & Computer Networks
> > > Phone: +49 531 391 3289    Bueltenweg 74/75, 38106 Braunschweig,
> Germany
> > > Fax:   +49 531 391 5936    <URL:http://www.ibr.cs.tu-bs.de/~schoenw/>
> > >
> > >
> 

To: Dave Shield <[email-masked]>
Cc: "Wijnen, Bert (Bert)" <[email-masked]>, [email-masked], Network Management Research Group <[email-masked]>
Subject: Re: [nmrg] SNMP over TCP transport mapping
From: Wes Hardaker <[email-masked]>
Organization: U.C.Davis, Information Technology - D.C.A.S.
Date: 10 May 2000 09:59:27 -0700
Lines: 44
Sender: [email-masked]
Status: RO

>>>>> On Wed, 10 May 2000 16:55:32 +0100, Dave Shield <[email-masked]> said:

Dave> Section 3.1, paragraph 2
Dave> "It is possible to exchange multiple SNMP request/response pairs
Dave> over a single connection".

Dave> Is this intended to imply a tightly-locked
Dave> request/response/request/response alternation, or are
Dave> implementors expected to support an asynchronous model
Dave> (e.g. request/request/response/request/response/response) ?  [I
Dave> presume the latter, but it could be read as the former]

Thats certainly a good point, although your assumption that it should
be the first is correct.  I don't think the document warns about
scenarios like: .5requests/1.3requests/response/.2requests/response as
well.

Dave> Is this connection intended to support bidirectional requests,
Dave> or will the application opening the connection always act as the
Dave> originating engine ?  This is particularly relevant for
Dave> notification messages, which could travel in either direction.

Well since PDU handling negotiation doesn't exist, then this would
rarely be a proper thing to do.  Since the notification generator
won't know if the other side of the connection is the same process
that is supposed to handle traps, it'll most likely need to open a new
connection to the (configured) trap handling port.  Now, if the
incoming request TCP connection originated from the trap handling port
then, um, I think it should probably say you still can't use it as its 
up to the side sending the "request" to initiate the connection.  This 
is somewhat indicated in section 3:

   The originator of a request/response transaction chooses the
   transport protocol for the entire transaction. The transport
   protocol MUST NOT change during a transaction. 

Though it doesn't explicitly say you must initiate a new one.

Interesting point, though.

-- 
Wes Hardaker
Distributed Computing Analysis and Support
University of California at Davis

Date: Wed, 10 May 2000 10:27:57 +0200
From: Juergen Schoenwaelder <[email-masked]>
To: Network Management Research Group <[email-masked]>
Subject: [nmrg] snmp over tcp discussion
Sender: [email-masked]
Status: RO

Some messages in this thread do not find their way to this list since
the sender is not allowed to post here. Since I do not like to
manually forward all these messages here, I would like to ask those
interested in the whole discussion to subscribe to the snmpv3 mailing
list (if not done yet) where you can read all messages.

/js

-- 
Juergen Schoenwaelder      Technical University Braunschweig
<[email-masked]>  Dept. Operating Systems & Computer Networks
Phone: +49 531 391 3289    Bueltenweg 74/75, 38106 Braunschweig, Germany
Fax:   +49 531 391 5936    <URL:http://www.ibr.cs.tu-bs.de/~schoenw/>

To: Keith McCloghrie <[email-masked]>
Cc: [email-masked] (Wes Hardaker), [email-masked] ("Wijnen, Bert (Bert)"), [email-masked], [email-masked] (Network Management Research Group)
Subject: Re: [nmrg] SNMP over TCP transport mapping
From: Wes Hardaker <[email-masked]>
Organization: U.C.Davis, Information Technology - D.C.A.S.
Date: 09 May 2000 13:52:54 -0700
Lines: 15
Sender: [email-masked]
Status: RO

>>>>> On Tue, 9 May 2000 13:16:19 -0700 (PDT), Keith McCloghrie <[email-masked]> said:

Keith> I've seen several examples recently of people wanting to define
Keith> MIB objects with a maximum length larger than 256 octets.  We
Keith> have always advised against this in the past, because of the
Keith> need for values to fit within a single SNMP message.

FYI, I was referring more to the problem of trying to get large PDUs
through that contained a high object count, rather than transmitting
objects with a large size...

-- 
Wes Hardaker
Distributed Computing Analysis and Support
University of California at Davis

To: "Wijnen, Bert (Bert)" <[email-masked]>
Cc: [email-masked], Network Management Research Group <[email-masked]>
Subject: Re: [nmrg] SNMP over TCP transport mapping
From: Wes Hardaker <[email-masked]>
Organization: U.C.Davis, Information Technology - D.C.A.S.
Date: 09 May 2000 10:38:17 -0700
Lines: 22
Sender: [email-masked]
Status: RO

>>>>> On Tue, 9 May 2000 11:51:57 +0200 , "Wijnen, Bert (Bert)" <[email-masked]> said:

Bert> I have not (yet) seen any comments on this document.  So I am
Bert> starting to assume that the SNMP community at large thinks that
Bert> this is a usefull document and that if we get a request to
Bert> publish it as an Experimental RFC, that I can report that the
Bert> SNMP community seems OK with it.  If such is the case, then at
Bert> least a few expressions of agreement would be great too.

I've mentioned on the nmrg list (but probably should here) that I'd
prefer to see it go forward as something more along the normal
standards track rather than the experimental, but either way I agree
that it should be published as a formal RFC.

The SNMP protocol has been dropped as a possible solution in many
other WGs for many reasons, but its lack of TCP support has definitely 
been one of the more frequently mentioned reasons (usually because of
a need for higher packet sizes).
-- 
Wes Hardaker
Distributed Computing Analysis and Support
University of California at Davis

Date: Tue, 09 May 2000 12:05:17 -0400
From: "D. Harrington" <[email-masked]>
To: "Wijnen, Bert (Bert)" <[email-masked]>, [email-masked], Network Management Research Group <[email-masked]>
Subject: [nmrg] Re: SNMP/TCP part 4
Sender: [email-masked]
Status: RO

Whoops,

I thought I'd lost this message before sending, so I wrote a new version
and sent it again. They're almost the same.

dbh

"D. Harrington" wrote:
> 
> Comments on TCP over SNMP draft
> 
> 1) I think it is atypical to include the name of the authoring group in
> the module name, and it will make it difficult to remember. This also
> applies to the MODULE-IDENTITY.
> 
> 2) I know the issue of IPv6 addresses has been raised numerous times in
> the SNMP community. It is my impression that the community has decided
> to defer the issue, and supplement existing definitions in the future by
> defining addition objects and textual conventions. On that basis, I
> consider this IPv4 only mapping adequate.
> 
> 3) In section 3.3, "halfs" should be "halves"
> 
> 4) "However, SNMP engines MUST NOT discard SNMP requests if only the
> incoming half of the TCP connection is closed." The text doesn't explain
> WHY this rule must be observed, and the reasoning is not obvious to me.
> Can this be expanded?
> 
> 5) section 3.3 calls for a noResponse error condition. Where is this
> error condition defined? Shouldn't the engine also return an SNMP error
> code, as enumerated in rfc1905? Which error code would be appropriate -
> genErr? or should it be handled by application-specific timeout handler
> code?
> 
> 6) section 3.4 says "A confirmed operation indicates that the data was
> actually delivered and processed by the receiving application process."
> I find this slightly misleading. I consider it important that developers
> realize that the receiver has the option of not processing the
> *contents* of the Inform.
> 
> Could we add ", at least to some degree" to this sentence? The following
> examples then illustrate varying degrees.
> 
> Alternately, could we reword to
> "With a reliable transport, the transport layer reports that the data
> was delivered to an upper (application) layer process."
> "With a confirmed operation, the application process acknowledges that
> the data was actually received."
> 
> 7) Is it appropriate to reference URLs in references?
> 
> 8) should this have some of the standard boilerplate stuff? the
> boilerplate for MIB documents, the security considerations, etc.?
> Does it meet all the RFC2223 requirements?
> 
> dbh

Date: Tue, 09 May 2000 12:02:29 -0400
From: "D. Harrington" <[email-masked]>
To: "Wijnen, Bert (Bert)" <[email-masked]>
CC: [email-masked], Network Management Research Group <[email-masked]>
Subject: Re: [nmrg] SNMP over TCP transport mapping
Sender: [email-masked]
Status: RO

Comments on SNMP over TCP (draft-irtf-nmrg-snmp-tcp-04.txt)

1) footer/header correction - incorrect title
	
2) I am unaccustomed to seeing organization names incorporated into the
MIB module name and the MODULE-IDENTITY except for private MIBs. I am
also concerned that having IRTF in the name may cause people to consider
it purely research and not really usable. Can these be made more
generic?

3) Section 3 says "applications using SNMP over TCP may choose to
switch". Would it be more appropriate to say "engines using SNMP ..."?

4) Section 3 has just a touch of ambiguity between "MUST NOT change
during a transaction" and "refusing new TCP connections whenever
necessary". If we dispense with the assumption that a connection is
opened for a whole transaction, then it is possible that a new
connection for returning the response for a processed request could be
refused. Should we add "except during a transaction"?

5) "requires to transfer" should be "requires the transfer of"

6) section 3.3 says "However, SNMP engines MUST NOT discard SNMP
requests if only the incoming half of the TCP connection is closed." It
is not obvious to me why this is a MUST NOT. Can you add explanatory
text that explains the problem with discarding the request?

7) "halfs" should be "halves"

8) 'noResponse' is not an SNMP error code. Is it defined someplace, or
is this recommended signal an implementation-dependent action? Should
there be a recommended SNMP error code for this condition, to be
returned to the requesting application? or should this just be part of
the implementation-specific handling of timeouts and other connection
loss conditions?

9) I have a concern with section 3.4. It is important that developers
not think that the *contents* of an Inform are guaranteed to have been
processed when the response is received. The receiving engine only
acknowledges receipt of the inform. I suggest a rewording:

"There is an important difference between an unconfirmed protocol
operation sent over a reliable transport and a confirmed protocol
operation. A reliable transport such as TCP reports that it has
delivered data to the application process. It does not guarantee that
the data was actually processed in any way by the application process."

"With a confirmed SNMP operation, the receiving SNMP engine acknowledges
that the data was actually received. Depending on the SNMP operation, a
confirmation may indicate that further processing was done. For example,
..."

"A reliable transport is thus only a poor approximation for confirmed
operations. Applications that need confirmation of delivery or
processing are encouraged to use the confirmed operations, such as the
InformRequest-PDU, rather than using  unconfirmed operations, such as
traps, over a reliable transport."

10) Is it appropriate to cite URLS in references, given how often URLs
change in today's world?

11) Should this document use some O&M boilerplate text, such as the MIB
boilerplate and the security considerations?

Hope this helps,
dbh

Date: Tue, 09 May 2000 11:02:45 -0400
From: "D. Harrington" <[email-masked]>
To: "Wijnen, Bert (Bert)" <[email-masked]>
CC: [email-masked], Network Management Research Group <[email-masked]>
Subject: Re: [nmrg] SNMP over TCP transport mapping
Sender: [email-masked]
Status: RO

Comments on TCP over SNMP draft

1) I think it is atypical to include the name of the authoring group in
the module name, and it will make it difficult to remember. This also
applies to the MODULE-IDENTITY.

2) I know the issue of IPv6 addresses has been raised numerous times in
the SNMP community. It is my impression that the community has decided
to defer the issue, and supplement existing definitions in the future by
defining addition objects and textual conventions. On that basis, I
consider this IPv4 only mapping adequate.

3) In section 3.3, "halfs" should be "halves"

4) "However, SNMP engines MUST NOT discard SNMP requests if only the
incoming half of the TCP connection is closed." The text doesn't explain
WHY this rule must be observed, and the reasoning is not obvious to me.
Can this be expanded?

5) section 3.3 calls for a noResponse error condition. Where is this
error condition defined? Shouldn't the engine also return an SNMP error
code, as enumerated in rfc1905? Which error code would be appropriate -
genErr? or should it be handled by application-specific timeout handler
code?

6) section 3.4 says "A confirmed operation indicates that the data was
actually delivered and processed by the receiving application process."
I find this slightly misleading. I consider it important that developers
realize that the receiver has the option of not processing the
*contents* of the Inform.

Could we add ", at least to some degree" to this sentence? The following
examples then illustrate varying degrees.

Alternately, could we reword to 
"With a reliable transport, the transport layer reports that the data
was delivered to an upper (application) layer process."
"With a confirmed operation, the application process acknowledges that
the data was actually received."

7) Is it appropriate to reference URLs in references?

8) should this have some of the standard boilerplate stuff? the
boilerplate for MIB documents, the security considerations, etc.?
Does it meet all the RFC2223 requirements?

dbh

Date: Tue, 9 May 2000 15:52:23 +0200
From: Juergen Schoenwaelder <[email-masked]>
To: [email-masked]
CC: [email-masked], [email-masked], [email-masked]
Subject: Re: [nmrg] SNMP over TCP transport mapping
Sender: [email-masked]
Status: RO

>>>>> D Harrington writes:

dbh> I'll point out that the footer/header on the document says:

[...]

dbh> This should probably be fixed before publication.

Fixed - and thanks for carefully looking at it.

/js

-- 
Juergen Schoenwaelder      Technical University Braunschweig
<[email-masked]>  Dept. Operating Systems & Computer Networks
Phone: +49 531 391 3289    Bueltenweg 74/75, 38106 Braunschweig, Germany
Fax:   +49 531 391 5936    <URL:http://www.ibr.cs.tu-bs.de/~schoenw/>

Date: Tue, 09 May 2000 09:33:42 -0400
From: "D. Harrington" <[email-masked]>
To: "Wijnen, Bert (Bert)" <[email-masked]>
CC: [email-masked], Network Management Research Group <[email-masked]>
Subject: Re: [nmrg] SNMP over TCP transport mapping
Sender: [email-masked]
Status: RO

Wel,,

I'll point out that the footer/header on the document says:

Schoenwaelder      Expires October 26, 2000                [Page 1]
Internet-Draft     TCs for Internet Network Addresses    April 2000

This should probably be fixed before publication.

This is a very small document. Can we get a few volunteers to sanity
check this latest revision before it becomes an Experimental RFC?

Thanks,
dbh
co-chair

"Wijnen, Bert (Bert)" wrote:
> 
> I have not (yet) seen any comments on this document.
> So I am starting to assume that the SNMP community at large
> thinks that this is a usefull document and that if we get a
> request to publish it as an Experimental RFC, that I can
> report that the SNMP community seems OK with it.
> If such is the case, then at least a few expressions of
> agreement would be great too.
> 
> Thanks,
> Bert
> 
> > ----------
> > From:         Juergen Schoenwaelder[SMTP:[email-masked]]
> > Sent:         Monday, May 01, 2000 1:56 PM
> > To:   [email-masked]
> > Cc:   Network Management Research Group
> > Subject:      [nmrg] SNMP over TCP transport mapping
> >
> >
> > The NMRG is ready to submit the SNMP over TCP transport mapping for
> > publication as Experimental RFC. This transport mapping is one of
> > several SNMP extensions to make bulk transfers more efficient. The
> > location of the current ID is:
> >
> >     ftp://ietf.org/internet-drafts/draft-irtf-nmrg-snmp-tcp-04.txt
> >
> > The purpose of this message is to make the larger SNMP community aware
> > of this piece of work and to give you a chance to raise any comments
> > before we actually submit the ID to the RFC editor. Please raise any
> > comments before May 12th.
> >
> > /js
> >
> > --
> > Juergen Schoenwaelder      Technical University Braunschweig
> > <[email-masked]>  Dept. Operating Systems & Computer Networks
> > Phone: +49 531 391 3289    Bueltenweg 74/75, 38106 Braunschweig, Germany
> > Fax:   +49 531 391 5936    <URL:http://www.ibr.cs.tu-bs.de/~schoenw/>
> >
> >

From: "Wijnen, Bert (Bert)" <[email-masked]>
To: [email-masked]
Cc: Network Management Research Group <[email-masked]>
Subject: RE: [nmrg] SNMP over TCP transport mapping
Date: Tue, 9 May 2000 11:51:57 +0200 
Sender: [email-masked]
Status: RO

I have not (yet) seen any comments on this document.
So I am starting to assume that the SNMP community at large
thinks that this is a usefull document and that if we get a
request to publish it as an Experimental RFC, that I can
report that the SNMP community seems OK with it.
If such is the case, then at least a few expressions of
agreement would be great too.

Thanks,
Bert

> ----------
> From: 	Juergen Schoenwaelder[SMTP:[email-masked]]
> Sent: 	Monday, May 01, 2000 1:56 PM
> To: 	[email-masked]
> Cc: 	Network Management Research Group
> Subject: 	[nmrg] SNMP over TCP transport mapping
> 
> 
> The NMRG is ready to submit the SNMP over TCP transport mapping for
> publication as Experimental RFC. This transport mapping is one of
> several SNMP extensions to make bulk transfers more efficient. The
> location of the current ID is:
> 
>     ftp://ietf.org/internet-drafts/draft-irtf-nmrg-snmp-tcp-04.txt
> 
> The purpose of this message is to make the larger SNMP community aware
> of this piece of work and to give you a chance to raise any comments
> before we actually submit the ID to the RFC editor. Please raise any
> comments before May 12th.
> 
> /js
> 
> -- 
> Juergen Schoenwaelder      Technical University Braunschweig
> <[email-masked]>  Dept. Operating Systems & Computer Networks
> Phone: +49 531 391 3289    Bueltenweg 74/75, 38106 Braunschweig, Germany
> Fax:   +49 531 391 5936    <URL:http://www.ibr.cs.tu-bs.de/~schoenw/>
> 
> 

Date: Mon, 1 May 2000 13:56:41 +0200
From: Juergen Schoenwaelder <[email-masked]>
To: [email-masked]
CC: Network Management Research Group <[email-masked]>
Subject: [nmrg] SNMP over TCP transport mapping
Sender: [email-masked]
Status: RO

The NMRG is ready to submit the SNMP over TCP transport mapping for
publication as Experimental RFC. This transport mapping is one of
several SNMP extensions to make bulk transfers more efficient. The
location of the current ID is:

    ftp://ietf.org/internet-drafts/draft-irtf-nmrg-snmp-tcp-04.txt

The purpose of this message is to make the larger SNMP community aware
of this piece of work and to give you a chance to raise any comments
before we actually submit the ID to the RFC editor. Please raise any
comments before May 12th.

/js

-- 
Juergen Schoenwaelder      Technical University Braunschweig
<[email-masked]>  Dept. Operating Systems & Computer Networks
Phone: +49 531 391 3289    Bueltenweg 74/75, 38106 Braunschweig, Germany
Fax:   +49 531 391 5936    <URL:http://www.ibr.cs.tu-bs.de/~schoenw/>