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

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

Please see comments in-line

Stephane.Combes@esa.int 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 !
>
> 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 ?
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 
> text
OK
> C) No, we do not intend to support IPv6 at this point.
Aha.

> 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 should 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...
We should try to remember to ask the MIB reviewer for help on this.

> 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) ?

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"

> 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

Best wishes,

Gorry