Check out by yourself & take the softwares for cheapest rates ever seen.

By convention, the name assigned is:

      type OBJECT IDENTIFIER ::= { transmission number }

   where "type" is the symbolic value used for the media
in the ifType

   column of the ifTable object, and "number" is the actual
integer

   value corresponding to the symbol.
I have now read the above internet draft, and have
the following

questions/comments. In a separate email, I will also list editorial

comments to assist in preparation of the next version of this I-D.

I have NOT reviewed the MIB structure for this revision.
This would be

appropriate once any corrections are applied and  I  would like
to see

this done also before we forward this to our AD for processing.

Best wishes,

Gorry Fairhurst

---

General comments:

A) Definitions of terms

I think if this document is to be published for use
by the Internet

Community, it should include a section on "Naming Conventions"
used

within the MIB. While I am familiar with the under-lying technology, it

is probably a bad pre-requisite for readers, and certainly likely to

raise questions when submitted for a MIB Review by MIB-Experts.

One way to fix this is to add a subsection to section
3, that lists the

acconyms/abbreviations and their corresponding definitions within this

document.

Terms not currently defined at the start of this document
include:

ACM        Adaptive Coding
and Modulation

ATM        Asynchronous Transfer Mode (cell
framing)

BER        Bit Error Ratio

BUC        ?

CCM        Constant Coding and Modulation

CNR        Carrier to Noise Ratio

CSC        Common Signalling Channel

CW        Continuous Wave (carrier frequency)

dBi        deciBel (isotropic)

dBm        deciBel (with respect to 1 mW)

DSCP        DiffServ Code Point

IDU        InDoor Unit

IFL        Inter-Facility Link

LNB        Low Noise Block

LO        Local Oscillator

MIB        Management Information Base

MPEG        Motion Pictures Expert Group (TS
Packet framing)

NCC        Network Control Centre

OAM        Operations and Management

PHB        Per-Hop Behavior

ODU        OutDoor Unit

PID        Program ID (MPEG)

RCST        Return Channel via Satellite Terminal
(DVB)

Rx        Receive

SSPA        Solid State Power Amplifier

Tx        Transmit

VCI        Virtual Channel Indentifier (ATM)

VPI        Virtual Path Indentifier (ATM)

Vpp        Volts peak-to-peak

---

B) Architecture is not clear.

A diagram in the introduction that links the ODU and
IDU with an IFL

would be helpful, especially if it identified the location of the LAN

interface, Air Interface, etc. Is this a suitable starting point?

Please view in a fixed-width font such as Monaco or

Courier.
+------------+

|  IP        |

|  End Host  |

+-----+------+
|

- - - - - - - |- - - - - - - - - - - - - - - -
|              |
LAN interface                 |

|
|       +------+--------+    
                 |

|  Indo|r Unit  |
|       |  (IDU)    
   |                
     |

+------+--------+
|              |

        |

| Inter Facility Link (IFL)
|              |

        |

+------+--------+
|       | OutDoor Unit  |  
                   |

| (ODU)         |
|       +------+--------+    
                 |

|
|              |
Air Interface                 |

- - - - - - - |- - - - - - - - - - - - - - - -
RCST         |

+-------->
FIGURE XX

---

C) Is the intention to support IPv6 equally to IPv4, and how is this

refelected in the current MIB?

---

Comments on specific sections:

---

1) dvbrcsIfMib value 239.

Is the descriptor assigned in section 2.1 already assigned by IANA, or

to be assigned by IANA as a result of publishing this RFC?

I can see a current registry entry as:

http://www.iana.org/assignments/smi-numbers

239   dvbRcsMacLayer  DVB-RCS MAC Layer  [Combes, ETSI EN
301 790,

SatLabs]

This is not the same as declared in 2.1. This inconsistency
needs to be

corrected.

---

2) IANA Considerations (relating to note 1)

Section 5 is read by IANA during the publication process.
This should be

updated to tell IANA that this has already been assigned (and indicate

the registry used), or that this needs to be assigned. (see note 1), e.g.

"This document includes no request to IANA. The assignment described
in

Section 2.1 has already been assigned under the XXX registry."

---

3) dvbrcsMIB MODULE-IDENTITY

The contact information could include a postal address, in addition to

the electronic contact details, e.g.:

Postal: xxxx

---

4) dvbrcsMIB MODULE-IDENTITY

"DVB-RCS MIB subtree. Draft version B."

The description included in the MIB itself seems to lack sufficient

detail to describe what the MIB is about and the technology to which it

relates.

---

5) Possible normative reference to [SATLABS]

"systemSatlabsOptions"

Says:

"Indicates the options supported as defined in SatLabs system
recommendations version 2."

- This reference appears to be normative, in that correct interpretation

of the MIB will depend upon definitions external to this document. The

document cited is NOT a standards body specification (which is fine, but

not normal for a normative reference). My question is to whether the

descriptions are provided in the document (which could be informative),

or definitions (which sound normative). Could the authors please clarify?

---

6) systemLocation

"NMEA 0183 format: is cited, but no reference provided.

---

7) Page 58:

The values /rtnstatusEbN0/ etc

use the digit "0", rather than the letter "O", was
this intentional?

---

8) Page 45: ctrlRcstTxDisable

This states: "This variable shall force the RCST to stop transmission
(transmit disabled as defined in [1])/

- What is [1]?

- Cited references need to be formatted correctly.

---