Re: Questions about draft-combes-ipdvb-mib-rcs-01.doc.

[Stephane.Combes@esa.int]

Dear Gorry,


I've finally managed to go again through
the MIB and I-D. Many thanks for your very precise and useful review !


Before sending out a new version, I
wanted to check with you how your proposed corrections and suggestions
are implemented.

A) I added a "Abbreviations"
section under 2.1. Is it correct or should it really be under section 3
?

B) I added your suggested diagram (+NCC)
together with some explanatory text

C) No, we do not intend to support IPv6
at this point.

1) This is a mistake indeed.
It seems I wrongly interpreted RFC1213,
where it says

------------
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 thought that the name assigned under
the transmission branch shoud be an ifType name. Now I realise that, in
IANA's SMI registry, transmission names are often "xxxMIB" when
the ifType is "xxx".
I guess we should have asked IANA to
call this dvbRcsMIB.
Do we need to rename the MIB module
dvbRcsMacLayer or is it possible to have a different name for the MIB module
? I have seen a few instances in the SMI registry where the MIB module
name is slightly different from the transmission name, but it might not
be good practice...

2-3-4) Fixed

5) Some of the parameters in the MIB
indeed are indeed only defined in SatLabs System Recommendations document,
and not in DVB-RCS. Do you mean that these definitions should be added
to the I-D (in section 3 before the MIB definition itself) ?

6) Fixed

7) zero (0) indeed

8) Fixed


kind regards,

Stephane

Telecommunications Department (TEN-TP)
ESA/ESTEC
Keplerlaan.1,P.O.Box 299, NL 2201 AZ Noordwijk ZH
Tel:+31 (0)71 56 58 674
Fax:+31 (0)71 56 54 598

Gorry Fairhurst <gorry@erg.abdn.ac.uk>

21/08/2007 15:14

Please respond to
gorry@erg.abdn.ac.uk

To	Stephane.Combes@esa.int, "ipdvb@erg.abdn.ac.uk" <ipdvb@erg.abdn.ac.uk>
cc	micheline.lambert@advantechamt.com, pca@verisat.no
Subject	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.
---