Subject: [IETFMIBS] MIB draft review request

From: "Hamid Mukhtar" <[email-masked]>
Date: Fri, 16 Feb 2007 19:40:38 +0900

Hi all,

Its really nice to see some reviewers around for MIBs.
I want to request a review of the attached IETF 6lowpan MIB draft and
answers to some queries.

the queries are as follows

1- Is row-status object required when the table objects are all readonly

2- Can we exclude the following security boilerplate paragraph from
the draft because SNMPv3 is too heavy for small packet sizes of 6lowpan and
instead can we propose to use SNMPv3 proxy mib for translation from SNMPv3
to prior versions when the packet enters 6lowpan networks.

"     Further, deployment of SNMP versions prior to SNMPv3 is NOT
      RECOMMENDED. Instead, it is RECOMMENDED to deploy SNMPv3 and to enable
      cryptographic security. It is then a customer/operator responsibility
to
      ensure that the SNMP entity giving access to an instance of this MIB
      module is properly configured to give access to the objects only to
      those principals (users) that have legitimate rights to indeed GET or
      SET (change/create/delete) them."

3- Can the MIB be named '6lowpan MIB' i.e. having a numeral at the start is
okay for an MIB name ?

we are looking forward to a review of this initial MIB draft

thanks and best regards,
Hamid
_______________________________________________
IETFMIBS mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ietfmibs

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 16 Feb 2007 12:01:34 +0100

> 1- Is row-status object required when the table objects are all readonly

The question is whether a manager can create/delete rows.
 
>      SET (change/create/delete) them."

I believe this requires a much longer explanation and discussion. Note
that only SNMPv3 exists as a standards-track protocol these days. Note
also that the IETF once look closely into compression mechanisms for
SNMP that might actually be application in 6lowpan environments.
 
> 3- Can the MIB be named '6lowpan MIB' i.e. having a numeral at the start is

Why not ipv6lowpan - you already call the module this way...
 
> we are looking forward to a review of this initial MIB draft

I am currently traveling; but I am volunteering as a MIB doctor contact 
for 6lowpan since I have some interest in 6lowpan for some other reasons.
Dan, you can put me down as a MIB doctor for 6lowpan if you want.

/js

-- 
Juergen Schoenwaelder		 Jacobs University Bremen
<http://www.eecs.iu-bremen.de/>	 P.O. Box 750 561, 28725 Bremen, Germany

---

From: "Romascanu, Dan \(Dan\)" <[email-masked]>
Date: Fri, 16 Feb 2007 13:16:00 +0200

> -----Original Message-----
> From: Juergen Schoenwaelder [mailto:[email-masked]] 
> I am currently traveling; but I am volunteering as a MIB 
> doctor contact for 6lowpan since I have some interest in 
> 6lowpan for some other reasons.

You got it :-)

Dan

---

From: "Ki-Hyung Kim" <[email-masked]>
Date: Fri, 16 Feb 2007 21:29:44 +0900

Thanks a lot for your help.
We are delighted to have you as a MIB doctor for 6lowpan MIB.
Because we are supposed to submit this draft to WG in a week, please give us
your input on the draft.

> The question is whether a manager can create/delete rows.

We believe that a manager could not create/delete rows. So we are not using
rowstatus object.

-- 
Ki-Hyung Kim (김기형, 金起亨)
Associate Professor
Division of Information and Computer Eng., Ajou University, Suwon, Korea
442-749
Tel: +82-31-219-2433, Cel: +82-17-760-2551,  Fax: +82-31-219-2433
http://www.6lowpan.org
_______________________________________________
IETFMIBS mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ietfmibs

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Sat, 17 Feb 2007 22:36:19 +0100

On Fri, Feb 16, 2007 at 09:29:44PM +0900, Ki-Hyung Kim wrote:

> Because we are supposed to submit this draft to WG in a week, 
> please give us your input on the draft.

Here are some more comments to consider. I assume the draft will require
some discussion anyway - so not all issues have to be resolved before
the -00 deadline.

- The TC module must have a full module-identity statement
  following the MIB guidelines. The guidelines document also
  suggests to call TC modules <PREFIX>-TC-MIB.

- The LowpanIEEEEUI64Address definition likely has a broader scope
  and perhaps this should be moved into a module which does not make
  it 6lowpan specific. (This may require discussion with Dan and the
  MIB doctors in general.)

- Please check the module using smilint; there are a number of
  syntactic issues that should be changed.

- Do not use values such as { mib-2 150 } - use XXX

- Please run the ID through idnits - there are several issues,
  like too long lines and unused references.

- In the section "Structure of the MIB Module", one usually expects a
  textual overview and not the definition themself; move the TC module
  to section 7. See also Dave Harrington's
  draft-harrington-text-mib-doc-template-02.txt. It is also useful to
  explain any relationships to other MIB modules.

- Perhaps you want to use other(0) for lowpanDeviceRole and renumber
  the enumeration. Spell out what and RFD is.

- It is pointless to state that a subfield in a BITS is a bit long.
  They always are by the vary definition of a BITS construct.

- Is the forwarding table (note that I write forwarding and not
  routing) load specific? If yes, you may want to name the table as
  such. If not, then the reference in the Table node should be
  removed.

- Is there any other information that should be kept for a forwarding
  table entry?

- Is there anything here that is really IPv6 specific?

- Spell out what a PanID is the first time it shows up.

- Make sure you have full sentences in all the DESCRIPTION clauses.

- What does lowpanMaxChildren contain if I do not use tree based
  routing? Some question for lowpanMaxDepth.

- What is the purpose of lowpanBroadcastSequenceNumber? Is this the
  next sequence number of the last one used?

- What are the units for lowpanAckTimeout? Spell out and add a UNITS
  clause.

- Should some objects not be designed to be writable, e.g. the timeout
  and retries? Note that you can define a module compliance statement
  which makes read-only implementations compliant.

- Since you have two MIB modules, you need to tell IANA to allocate
  two OIDs.

- You refer to IEEE specs in several places and I think these should
  appear as normative references. The same is true for some of the
  IDs that are references in REFERENCE clauses.

/js

---

From: "Hamid Mukhtar" <[email-masked]>
Date: Mon, 19 Feb 2007 07:55:03 +0900

Dear Juergen,

Thanks for your comments.

For packet SNMP compression IETF already defined aggregation MIB (rfc
4498). I think we can recommend the use of aggregation MIB for 6lowpan in
the draft.

> suggests to call TC modules <PREFIX>-TC-MIB.

would it be better to define a TC-MIB because we can also move the TCs
inside the existing module-identity.
but anyhow the draft now includes the module-identity statement for the
LOWPAN-TC-MIB.

> syntactic issues that should be changed.

done

done

> like too long lines and unused references.

done

> explain any relationships to other MIB modules.

changes made.

> the enumeration. Spell out what and RFD is.

done

> They always are by the vary definition of a BITS construct.

done

> such. If not, then the reference in the Table node should be

the reference is removed since the routing table is a generic entity. and
the routing protocol which was an object is moved inside the routing table
since a 6lowpan entity can support multiple routing protocols

> - Is there any other information that should be kept for a forwarding

except for the next hop and the destination address other elements are more
protocol specific so we can include them in the specific MIBs for those
protocols.

done

changes made.

> routing? Some question for lowpanMaxDepth.

both of them are removed since they are hierarchical routing specific and
can be included in the protocol specific MIBs and instead a new object
lowpanUseHierarchicalRouting is introduced which indicates that entity uses
tree based routing or not.

> next sequence number of the last one used?

the value is the current(last one used) value of the sequence number. the
decription clause is edited accordingly.

> clause.

UNITS added.

> which makes read-only implementations compliant.

yes thats a nice idea to make them writable and introduce a read-only
complience
lowpanBroadcastRetries and lowpanAckTimeout now are read-write and read-only
complience defined.

> two OIDs.

done

> IDs that are references in REFERENCE clauses.

the specs moved to references.

/js

Hamid

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 19 Feb 2007 09:48:37 +0100

On Mon, Feb 19, 2007 at 07:55:03AM +0900, Hamid Mukhtar wrote:
 
> For packet SNMP compression IETF already defined aggregation MIB
> (rfc 4498). I think we can recommend the use of aggregation MIB for
> 6lowpan in the draft.

Aggregation is not the same as compression.

/js