RE: I-D ACTION:draft-ietf-rmonmib-raqmon-pdu-08.txt

Mark,
 
Thanks for your comments. See in-line. 
 

Regards,

Dan

-----Original Message-----
From: [email protected] [mailto:[email protected]]On Behalf Of Mark Ellison
Sent: 21 December, 2004 3:18 AM
To: [email protected]
Cc: [email protected]; Mark Ellison
Subject: Re: [RMONMIB] I-D ACTION:draft-ietf-rmonmib-raqmon-pdu-08.txt


Hi,

In looking at the RAQMON-RDS-MIB, some issues arise, as follows:

1)  raqmonDs MODULE-IDENTITY

	module identity name should end with Mib or MIB
[Romascanu, Dan (Dan)] I have no objection, although I cannot find a reference for your SHOULD.  Do you have one? 
RFC 2578 seems to require the name to be just a unique ASN.1 identifier. The MIB guidelines are also mute on this issue. 
RFC 3729 which is the last RFC defining a MIB module issued by this WG  defines just apm and not apmMIB or something similar. 



2)  raqmonDsNotificationEntry

	objects used in index clause [raqmonDSRC, raqmonRCN, 

	raqmonPeerAddrType, raqmonPeerAddr] according to 

	SMIv2 (2578 sxn 7.7) should have a MAX-ACCESS of 

	not-accessible.



	The two defined notifications, raqmonDsNotification and 

	raqmonDsByeNotification require only index objects be sent.

	Since the value part of the object instance is included

	in the index portion of the varbind name, there is a

	unnecessary duplication of information.



	This suggests one of two alternative approaches- either

	a) change the OBJECTS clause for the NOTIFICATION-TYPEs

	   to specify an accessible-for-notify object that is not

	   mentioned in the INDEX clause of raqmonDsNotificationEntry

	   and replace the current OBJECTs list with this object.

	b) change the raqmonDsNotificationEntry into a group of

	   scalars, leaving the index objects with a MAX-ACCESS of

	   accessible-for-notify, and, leaving the two defined

	   NOTIFICATION-TYPEs as is.
[Romascanu, Dan (Dan)] I will go with your proposal a. 
There are reasons to keep the table structure, so that the information is correlated if the table is extended in the future.
 
        Since 2578 Sxn 7.7 appears specifies that at least one 
        object in an entry must have a MAX-ACCESS of at least read-only, 
        it might be a good idea to address this point in the description 
        clause of the entry, given the design choice to stick with the
        current organization, or, make an object read-only, and then
        restrict its MAX-ACCESS to accessible-for-notify in a compliance
        clause.
[Romascanu, Dan (Dan)] Actually I believe that this is OK and we do not need a 'read-only' object. What RFC 2578 says is:


 a conceptual row must contain at least one columnar object which is
     not an auxiliary object.  In the event that all of a conceptual
     row's columnar objects are also specified in its INDEX clause, then
     one of them must be accessible, i.e., have a MAX-ACCESS clause of
     "read-only". 
 
"read-only" is an example. The objects in raqmonDsNotificationEntry
  are accessible-for-notify. 
This MIB module defines a mapping of the RAQMON PDU into SNMP notifications and this level of accessibility is sufficient.


Regards,

Mark

[email protected] wrote:


A New Internet-Draft is available from the on-line Internet-Drafts directories.

This draft is a work item of the Remote Network Monitoring Working Group of the IETF.



	Title		: Transport Mappings for Real-time Application Quality 

			  of Service Monitoring (RAQMON) Protocol Data Unit (PDU)

	Author(s)	: A. Siddiqui, et al.

	Filename	: draft-ietf-rmonmib-raqmon-pdu-08.txt

	Pages		: 37

	Date		: 2004-12-17

	

This memo specifies two transport mappings of the Real-time

   Application Quality of Service Monitoring (RAQMON) information model

   defined in [RAQMON-FRAMEWORK] using TCP as a native transport and the

   Simple Network Management Protocol (SNMP) to carry the RAQMON

   information from a RAQMON Data Source (RDS) to a RAQMON Report

   Collector (RRC).



A URL for this Internet-Draft is:

http://www.ietf.org/internet-drafts/draft-ietf-rmonmib-raqmon-pdu-08.txt



To remove yourself from the I-D Announcement list, send a message to 

[email protected] with the word unsubscribe in the body of the message.  

You can also visit  https://www1.ietf.org/mailman/listinfo/I-D-announce 

to change your subscription settings.





Internet-Drafts are also available by anonymous FTP. Login with the username

"anonymous" and a password of your e-mail address. After logging in,

type "cd internet-drafts" and then

	"get draft-ietf-rmonmib-raqmon-pdu-08.txt".



A list of Internet-Drafts directories can be found in

http://www.ietf.org/shadow.html 

or  ftp://ftp.ietf.org/ietf/1shadow-sites.txt





Internet-Drafts can also be obtained by e-mail.



Send a message to:

	 [email protected].

In the body type:

	"FILE /internet-drafts/draft-ietf-rmonmib-raqmon-pdu-08.txt".

	

NOTE:	The mail server at ietf.org can return the document in

	MIME-encoded form by using the "mpack" utility.  To use this

	feature, insert the command "ENCODING mime" before the "FILE"

	command.  To decode the response(s), you will need "munpack" or

	a MIME-compliant mail reader.  Different MIME-compliant mail readers

	exhibit different behavior, especially when dealing with

	"multipart" MIME messages (i.e. documents which have been split

	up into multiple messages), so check your local documentation on

	how to manipulate these messages.

		

		

Below is the data which will enable a MIME compliant mail reader

implementation to automatically retrieve the ASCII version of the

Internet-Draft.

  


  _____  


_______________________________________________

RMONMIB mailing list

[email protected]

https://www1.ietf.org/mailman/listinfo/rmonmib

_______________________________________________
RMONMIB mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/rmonmib