[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Questions about draft-combes-ipdvb-mib-rcs-01.doc.
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.
---