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

From: Gorry Fairhurst <[email-masked]>
Date: Tue, 21 Aug 2007 14:14:20 +0100

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, 21 Aug 2007 14:14:22 +0100

I suggest that once you have answered any questions raised by the group, 
that you should prepare a new revision of the I-D. This email lists 
editorial comments to assist in preparation of this next version of the 
I-D.

Best wishes,

Gorry

---

General:

In some cases descriptions supplied, provide informatioon about the 
format of the objects, but about their intended use.

For instance in "systemLocation":

"The string shall have 31 characters in the following
    format: ..."

Whereas a description often also provides a description of the object 
and hints to what the object may be used for and examples of when it is 
set, as in:

This MIB Module provides information to identify the position of a 
DVB-RCS equipment. It may be used by the YYY module to ZZZ. The string 
shall have 31 characters in the following
    format: ..."

Examples of objects were this applies are:

systemLocation
systemOduRxLO
systemOduTxLO
installAntennaAlignmentState
installCwPower (does not first say what this is)
Co-Pol
Cross-Pol
installCoPolTarget
installXPolTarget
fwdStartEntry (description seems terse)
fwdStartIndex (description seems terse)

---

NiTs:

---
Abstract:
/defines a set of new MIB entities/
                   ^^^
to
/defines a set of MIB entities/
---
Page 3, Introduction:
/Program which provides/
to
/Program that provides/
          ^^^^
---
Page 3, Introduction:
/physical and MAC layers/
                        ^
to
/physical and MAC layer/
---
Page 4, Conventions:
/RFC 2119. [RFC2119]./
          ^
to
/RFC 2119 [RFC2119]./
---
Page 9, systemOduSspa
Please define SSPA in desciption (and possibly ODU)
dBio
---
Page 9, systemOduSspa
- The flexibility text seems odd, consider:
/tenth of Watt for more flexibility,/
to:
/tenths of a Watt,/
---
Page 10, systemOduRxType
- Illegal character for an RFC:
/quad,Ö)/
      ^^^
---
Page 11, systemOduTxLO
- Define BUC
---
Page 12: installCwFrequency
- English?
/frequency at which the carrier is put up/
to:
/frequency of the transmitted carrier/
----
Page 12: installCoPolReading
- Please expand "Co-Pol" and extend explanation.
---
Page 12: installCrossPolReading
- Please expand "Cross-Pol" and extend explanation.
---
Page 14:
/This object used with both ip and
        interfaces MIB-II subgroups determines uniquely the interface
        through which OAM traffic is passing through. /
to:
/This object used with both ip and
        interfaces MIB-II subgroups. It uniquely determines the interface
        through which the OAM traffic passes. /
---
Page 15:
/networkConfigFileDownloadUrl/
/networkInstallLogFileDownloadUrl/
/networkLogFileUploadUrl/
/networkInstallLogFileUploadUrl/
- Please cite a reference for the format of this information. Is there 
an RFC that could be cited, e.g. defined as a URI or URL?
---
Page 20: fwdStartFrequency
/ts value shall be/
- What is ts (transport stream centre frequency?), please expand?
---
Page 21: fwdStartPolar
/applied for the start transport stream/
- Please clarify what is meant by "start transport stream"?
---
Page 21: fwdStartPolar
/according to the claimed SatLabs profile support./
- Not sure what "claimed" means in this context.
---
Page 21: fwdStartRolloff
- Is this the *receive filter roll-off*?
/Specifies the roll-off applied on/
---
Page 22: fwdStartInnerFec
- Please expand NIT in description.
---
Page 24: fwdStatusNetId
/"Interactive network identifier of the forward
        link (from RMT)"/
- Please expand RMT in description.
---
Page 24: fwdStatusFormat
- Please expand RMT in description.
---
Page 31: pktClassDscpHigh
/DSCP/
to
/DiffServ Code Point (DSCP)/
---
Page 34: phbMappingTable
- Please define PHB in description.
---
Page 35: requestClassIndex
/A total of 16 entries is supported./
to
/A total of 16 entries are supported./
                        ^^^
---
Page 37: requestClassName, and following objects
Please change all:
/Request class/
to
/Request Class/
---
Page 38: requestClassCra
- Please expand CRA in description.
- Also for RBDC, VBDC, AVBDC, etc.
---
Page 39: pidPoolTable
- The concept of PID pools is not well explained, consider adding some 
more description to this object.
- PID should probably be expanded in the table object description.
---
Page 40: PidPoolEntry
- No descriptive text supplied.
---
Page 40: pidValue
/Define one of the PIDs to be used in a PID pool of
    pidPoolIndex./
- /Define/ to /Defines/
- Description should be longer.
---
Page 42: rcstMode
/Allows to identify in which mode the RCST is and to return it/
to
/Identifies the current mode of the RCST and allow it to return/
---
Page 48: ctrlActivateConfigFileCommand
/Some RCST implementation may/
to
/Some RCST implementations may/
                          ^
---
Page 59: rtnStatusGroup
DESCRIPTION    "A collection of objects allowing access to RTN
    link status."
- Please replace RTN with "return (RTN)".
---
Change all:
/doesn't provide/
to
/does not provide/

---

From: [email-masked]
Date: Tue, 21 Aug 2007 16:01:11 +0200

Dear Gorry,

many thanks for the review ! We will prepare an updated I-D as soon as 
possible.

cheers,

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.

Best wishes,

Gorry Fairhurst

---

General comments:

A) Definitions of terms

---

+------------+
|  IP        |
|  End Host  |
+-----+------+
|

FIGURE XX

---

---

---

---

From: Gorry Fairhurst <[email-masked]>
Date: Tue, 21 Aug 2007 16:51:35 +0100

Great - anything I can do, let me know. It would be good to know if 
there are any issues or responses to the questions.

Gorry

> Keplerlaan.1,P.O.Box 299, NL 2201 AZ Noordwijk ZH

<snip>