RE: A few comments on the Midcom MIB-00

hi

Comments inline ...

-----Original Message-----
From: Martin Stiemerling [mailto:[email protected]] 
<clip>

|
| 1. In the Overview section, how do the managed objects described in 
| the third paragraph relate to the solution described in the second 
| paragraph? This connection has not been made.

Martin>Actually I'm not sure to what you refer. Could please cite the
paragraphs 
Martin>by email?

Like most of my comments, this relates to readability. These are the two
paragraphs in question:

"As one possible solution for this problem, the IETF MIDCOM working
   group defined a framework [RFC3303], requirements [RFC3304] and
   protocol semantics [RFCXXXX] for communication between applications
   and middleboxes acting as firewalls, NATs or a combination of both.

   The managed objects defined in this document can be used for
   dynamically configuring middleboxes on the datagram path in order to
   enable datagram streams to pass the middlebox.  This way,
   applications can request pinholes at firewalls and address bindings
   at NATs."

|
| 2. In section 3.1, on Terminology, it would be good to tell us what 
| RFCXXXX is. Right now I have no idea what document you are referring 
| to, but even after it is published, I think including the title of the 
| RFC would greatly increase readability.

Martin>See Section 11 References: RFCXXX is the MIDCOM semantics document
that is 
Martin>currently in IESG review.

Again, from a readability perspective, it would be better to provide the
title of the ID/RFC within the paragraph instead of forcing the reader to
jump around the document.

|
| 3. In section 3.1 in Terminology, it might be worth noting that the 
| latest terminology in SNMP is 'SNMP entity' and using this should 
| clarify things for you. See section 2.1 in RFC3410. You could then 
| indicate that the Midcom SNMP Entity acts in both the manager and 
| agent roles, or something along those lines.

Martin> We have actually chosen (after long discussions) MIDCOM client for 
Martin>clarification. I feel that this brings it to the point, but MIDCOM
SNMP 
Martin>entity will confuse readers even more (considering that they like
more 
Martin>MIDCOM-folks)

I think it's fine to use this MIDCOM client term if you feel it meetings to
needs of the draft, but the way it is currently being introduced/defined and
its relation to SNMP could use some work. For that portion, I would suggest
using text more in line with what I suggest above. I'm not providing a
formal MIB Doctor review here, but I imagine the current text is going to
raise flags when it is formally reviewed.

|
| 4. In section 4, the first paragraph, I might suggest something more 
| along the lines of "This memo describes a method of using managing 
| Midcom in SNMP and also provides the necessary MIB objects to support 
| this method."
|

Martin> Why do you think it is not appropriate? I have problems to follow
your 
Martin> suggestion "...using managing Midcom in SNMP". This sounds rather
confusing 
Martin> for me.
Martin> Here is the original excerpt:
Martin> "In order to realize middlebox communication as described in RFC
XXXX, several Martin> aspects and properties of the MIDCOM protocol need to
be mapped to SNMP 
Martin> capabilities and expressed in terms of the Structure of Management
Information
Martin> version 2 (SMIv2)."

Ok, this one might be more word smithing. I think it's the idea that you are
claiming to be mapping to SNMP rather than using it, which from what I can
tell is what you are doing. Sure, you've got network elements also acting in
the manager role, but the Internet Management Framework allows for that.

Sharon