Subject: [Adslmib] WG Last Call: draft-ietf-adslmib-vdsl-09.txt

From: Flemisch Felix <[email-masked]>
Date: Fri, 30 May 2003 12:11:33 +0200

Hi all,

on 16th May I requested additional time to review draft-ietf-adslmib-vdsl-09 personally and to collect comments by Siemens.  This is completed now, and I will send out the details with the next email.  As a matter of fact, to ease the consideration of integration of the comments [mechanical, editorial, clarifying, substantial] into the RFC (or, maybe only into draft-ietf-adslmib-vdsl-10) I have prepared a detailed WORD update of draft-ietf-adslmib-vdsl-09.txt with change tracking.

This email provides a high-level summary of our position and proposals how to proceed.  The result is that I vote YES WITH COMMENTS but request willingness for utmost acceleration of line-code specific (LCS) VDSL framework and MIB standardization in both DSLF and IETF to avoid a longer period where urgently needed LCS parameters have to be specified on a proprietary base.  The LCS MIB(s), for SCM and MCM, MUST then be used together with the core VDSL-LINE-MIB.

VDSL MIB standardization seems to be in a sort of unhappy state at the moment but I'm much confident that this can be improved considerably on the short term.  The standardization work on VDSL line management is ongoing for quite some time now in both DSLF and IETF, and a couple of months ago it seemed to turn out to be a never-ending story.  A major reason for this paralysis is, of course, the religious battle for the true line code:  SCM/QAM/Coalition or MCM/DMT/Alliance, that's the question.

But then the DSLF found the philosophers' stone, and split off all LCS issues in order to be able to specify a core protocol-independent management framework for VDSL lines.  This pioneering task resulted in the publication of TR-057 in February 2003.

Though it was realized in the meantime that TR-057 has some flaws (which are already addressed by DSLF's OpNM WG with a new WT for an addendum to TR-057 that will be fast tracked through straw ballot), IETF's ADSLMIB WG agreed to adopt DSLF's strategy and created a VDSL MIB that consists of a core set of essential parameters for managing VDSL lines in a line-code independent manner and is fully aligned with TR-057, and even includes first flaw resolutions (configuration of slow burst protection and fast FEC overhead).  This equally pioneering work should not be held up unnecessarily.

It turned out, however, that the agreed core set covers completely the PMS-TC sublayer but not completely enough the PMD sublayer.  As a consequence no agreement was reached, not even within the SCM fraction, that basic (whatever this means) configuration of VDSL lines will be possible using the core VDSL MIB of draft-ietf-adslmib-vdsl-09 without additional LCS parameters.  Therefore the development of an LCS-specific framework for both SCM and MCM by the DSLF and the development of one (or two) corresponding LCS VDSL MIB(s) are a MUST since otherwise vendor-specific MIBs need to be implemented at the disadvantage of customers (who regularly require multi-vendor capability).  Also, the important, line-code independent question of how to configure the read-only channelization mode "vdslLineType" at start-up could not be settled.

For the latter I'm proposing a new read-create parameter "vdslLineConfLineType" while for the LCS defects I'm proposing to add a note to the description of the VDSL-LINE-MIB module stating that a standardized LCS VDSL Line Extension MIB (VDSL-LINE-EXT-MIB) module is seen as a MANDATORY supplement to VDSL-LINE-MIB.  All other comments are clarifications or based on my earlier comments of 13th March.

For details see my next email.

Best Regards,

Felix Flemisch
Siemens AG
_______________________________________________
Adslmib mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/adslmib

---

From: "Michael Sneed" <[email-masked]>
Date: Fri, 30 May 2003 12:07:40 -0400

Thanks for the thorough contribution Felix, but Randy is right.  If anyone 
is interested in the Word document, I have in the past been able to make 
that available on the ftp server, but we need plain text for general 
distribution.

Regards,

Mike

>From: "Randy Presuhn" <[email-masked]>
>To: <[email-masked]>
>Subject: [Adslmib] Re: WG Last Call: draft-ietf-adslmib-vdsl-09.txt
>Date: Fri, 30 May 2003 08:49:19 -0700
>
>Hi -
>
> > From: "Flemisch Felix" <[email-masked]>
> > To: <[email-masked]>
> > Cc: <[email-masked]>; <[email-masked]>; 
><[email-masked]>; <[email-masked]>;
><[email-masked]>; <[email-masked]'>; "Kopetzky Walter" 
><[email-masked]>; "Muhn Harald"
><[email-masked]>
> > Sent: Friday, May 30, 2003 5:06 AM
> > Subject: RE: WG Last Call: draft-ietf-adslmib-vdsl-09.txt
> >
>
> >
> > Hi all,
> >
> > I sent the mentioned Word document to Mike, Bob, and Rajesh.  I will not 
>send it to the Adslmib mailing list (which accepts only
>plain text attachments) but see the summary of my comments below.
>...
>
>I object.  Particularly at this late stage in the process (WG last call!),
>I believe it is important that any changes that are not purely editorial
>or mechanical should be posted to the WG mailing list, in plain text.
>
>Randy
>
>

_________________________________________________________________
Help STOP SPAM with the new MSN 8 and get 2 months FREE*  
http://join.msn.com/?page=features/junkmail

---

From: Flemisch Felix <[email-masked]>
Date: Sat, 31 May 2003 15:09:38 +0200

1         2         3         4         5         6         7 |       8
12345678901234567890123456789012345678901234567890123456789012345678901234567890

Hi all,

Randy Presuhn wrote

> I did a diff of the -09- and "09a" documents, and have
> a few comments on the proposed changes.

Thanks Randy for so quickly producing diffs and commenting them!
You identified a number of obscurities indeed.
Here are my answers.

 1. 269c280
    I leave it to the co-editors whether they stick to US English
    or British English but only request that either is used
    uniformly.  I prefer British English but am aware that you e.g.
    recommend to replace existing "behaviour"s by "behavior"s.

 2. 348,349c361,366
    The non-ASCII thing is a dash inserted by Word that needs to
    be replaced by a hyphen (though semantically it's a dash).

 3. 494,496c513,515
    I'm now proposing the following new text:
    All objects defined in this MIB module that may be set (read-write
    or read-create) SHOULD be stored persistently.  Following is
    an exhaustive list of these persistent objects:
    <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<

 4. 614c638
    When the country is put on a separate line this should also be
    done with Bob's and Rajesh's addresses (twice for each).

 5. 711c753,759
    I will send out a separate email on "VDSL Line Type
    Configuration and VDSL Line Extension MIB", since these are
    the substantial changes that I'm proposing for vdsl-09.
    <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<

 6. 723c771,779
    I was so naive to take the IANAifType for the VDSL line.
    I now think it's better to leave IANA issues to the RFC editor.
    The REVISIONS section would be of interest only if the WG
    should decide to produce "draft-ietf-adslmib-vdsl-10.txt"!

 7. 805,808c863,869
    Refer to the upcoming email on "VDSL Line Type Configuration
    and VDSL Line Extension MIB".

 8. 815c876; 819c880
    It is strange!  Forget that spelling!  One also writes e.g.
    "channelization".  Probably I was assuming that there
    might be a similar US/British difference as between e.g.
    "modeling" and "modelling" but this does not apply here.

 9. 830c893
    Refer to the upcoming email on "VDSL Line Type Configuration
    and VDSL Line Extension MIB".

10. 839c902
    I agree, and let's do the same for the Alarm Configuration
    Profile Table.

11. 948c1015; 960c1027; 2322c2436; 233c2447
    I agree, and so let's replace WITHIN COMMENTS the interval
    specification ".." by " to " here, and all over the document.

12. 1007,1008c1076,1077
    I regret to have to agree.

13. 2205c2314, 2278c2390, 2926c3112 ("`" vs. "'")
    I agree but "`" is already used in vdsl-09 as a quote character
    (old lines 426 and 430).  I therefore propose to change the "`"
    in these lines to a "'", too.

14. 2732c2877,2879; 2744c2891,2893 (PSD templates)
    Randy, in your email of 14th May you stated the following:
    >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
    > vdslLineConfUpstreamPsdTemplate and
    > vdslLineConfDownstreamPsdTemplate need much clearer
    > DESCRIPTIONs.  I have no idea what they DO, even if I
    > make the leap of faith that "PSD" and "Psd" are the
    > same thing in the document.
    <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
    The proposed text that "templateMask1(1)" and
    "templateMask2(2)" depend on vdslLineConfApplicableStandard
    is a first, yet incomplete answer to this comment.
    I'm now proposing the following new text fragments.
    DESCRIPTION of vdslLineConfUpstreamPsdTemplate:
            "The upstream PSD template to be used for the line.
            Here templateMask1(1) refers to a notched mask that
            limits the transmitted PSD within the internationally
            standardized HAM radio bands while templateMask2(2)
            refers to an unnotched mask.  The masks depend on
            vdslLineConfApplicableStandard and in case of etsi(2)
            also on vdslLineConfAdslPresence.  They are specified
            in the applicable T1E1/ANSI, ETSI, ITU-T standards
            documents or in proprietary documentation."
    <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
    DESCRIPTION of vdslLineConfDownstreamPsdTemplate:
            "The downstream PSD template to be used for the line.
            Refer to vdslLineConfUpstreamPsdTemplate for the semantics.
    <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<

15. 2776a2930,2934
    I appreciate your corrections.  HAM is a widespread equivalent,
    also used by TR-057, for Handheld Amateur Radio. In the past
    this acronym was also written out differently, however
    (see, for example, http://earlyradiohistory.us/sec012.htm
    and and http://earlyradiohistory.us/1902slng.htm). 

16. 2797c2957; 2806c2966; 2815c2975; 2824c2984 ("kHz" vs. "Hz")
    These changes are indeed intentional since they are specified
    in this way in TR-057 (section 2.6.1).  They allow for a much
    finer grained definition of custom notches.

17. 2879a3042,3063
    Refer to the upcoming email on "VDSL Line Type Configuration
    and VDSL Line Extension MIB".

18. "interleave(124)" vs. "interleaved(124)" (see 183c191 etc.)
    While "interleave" is the verb "interleaved" is the adjective.
    Since the adjective seems to be appropriate in all places
    I agree with your proposal.  However, the enumeration is IANA
    defined and used e.g. by ADSL.  So I doubt whether it will be
    possible to change it as one should.  But we should ask the
    RFC editor what can reasonably be achieved.

I finally take the opportunity to point out three typos in
"draft-ietf-adslmib-vdsl-09a.txt":

(new) line 148 should read
"   lines specified by DSLF is taken into consideration [DSLFTR057]."
(new) line 3079 should read
"            A profile is activated by setting this object to `active'."
(new) lines 3083/3084 should read
"            service, by setting this object to `destroy' or"
"            `outOfService', it must be first unreferenced"

The announced email on "VDSL Line Type Configuration and
VDSL Line Extension MIB" will be sent out next Monday.

Regards,

Felix

-----Original Message-----
From: Flemisch Felix 
Sent: Friday, May 30, 2003 10:42 PM
To: [email-masked]'
Cc: [email-masked]'; [email-masked]'; [email-masked]';
[email-masked]'
Subject: RE: WG Last Call: draft-ietf-adslmib-vdsl-09.txt

Hi all,

please find attached a plain ASCII text version of the updated "draft-ietf-adslmib-vdsl-09.txt" that I previously distributed as a Word document with continuous line numbering where I have added my comments using change tracking.  I have named this updated document "draft-ietf-adslmib-vdsl-09a.txt".

...

Best Regards,

Felix Flemisch
Siemens AG