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

From: [email-masked]
Date: Fri, 12 Oct 2007 10:50:09 +0200

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 <[email-masked]> 
21/08/2007 15:14
Please respond to
[email-masked]

To
[email-masked], "[email-masked]" <[email-masked]>
cc
[email-masked], [email-masked]
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.
---

---

From: Gorry Fairhurst <[email-masked]>
Date: Tue, 16 Oct 2007 03:52:12 +0100

Please see comments in-line

[email-masked] wrote:
> 
> Dear Gorry,
> 
> I've finally managed to go again through the MIB and I-D. Many thanks 
> for your very precise and useful review !
> 
> A) I added a "Abbreviations" section under 2.1. Is it correct or should 
> it really be under section 3 ?
> 
Perfect. I think it should be in section 2. My understanding is that the 
complete contents of section 3 should be a parse-able MIB module.

> B) I added your suggested diagram (+NCC) together with some explanatory 
OK
> C) No, we do not intend to support IPv6 at this point.
Aha.

> I thought that the name assigned under the transmission branch should be 
> an ifType name. Now I realise that, in IANA's SMI registry, transmission 
> 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...
> 
We should try to remember to ask the MIB reviewer for help on this.

> that these definitions should be added to the I-D (in section 3 before 
> the MIB definition itself) ?
> 

It may be good to add a little more text to the descriptive portion in 
these cases. Especially if correct interpretation of the MIB entry will 
depend upon understanding this.

Definitions could be added to a subsection of section 2 (or a new 
section - if you think this is needed), but my understanding is that 
there should not be background text in the section before the MIB Module 
definition. RFC4036, for example provides some up-front definitions in a 
section before the MIB.

There is also a REFERENCE clause that can be used to link the MIB 
entities to the related specification, this could be helpful:
e.g. REFERENCE "RFC 3828, section 3.1"

Best wishes,

Gorry