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

From: Flemisch Felix <[email-masked]>
Date: Fri, 30 May 2003 22:41:45 +0200

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".

In the following I summarize the proposed changes.

Please note that the line numbers refer to the reviewed "draft-ietf-adslmib-vdsl-09.txt" and not to the updated, attached "draft-ietf-adslmib-vdsl-09a.txt"!  Also, the page formatting is unchanged from vdsl-09.  When required, you may use an appropriate file comparison tool to keep track of the changes (most editorial or mechanical) between the two .txt files.

Mechanical and editorial changes were made to the following (old) lines:

1-4, 128, 133, 146, 165, 183/184, 204, 255/256, 260-263, 269, 313, 348/349, 378-380, 384-387, 389, 391, 396, 400, 420, 427, 431/432, 454, 459/460, 477/478, 482, 487, 494-496, 505-510, 521/522, 607, 609, 614, 637, 644, 653, 663, 669/670, 678, 683, 696, 700, 715, 719, 721, 722ff, 723, 815, 819, 839, 849/850, 948, 960, 1007/1008, 1134, 1620, 1760/1761, 2078, 2141/2142, 2203, 2205, 2253/2254, 2276, 2278, 2322, 2333, 2689-2691, 2986, 3215, 3228, 3246, 3487, 3534, 3576, 3594, 3600, 3602, 3605, 3621, 3701, 3709.

Clarifications were made to, or between, the following (old) lines:

142ff, 259f, 663ff, 673f, 2445ff, 2455ff, 2490ff, 2500ff, 2732ff, 2744ff, 2760ff, 2762/2763, 2775ff, 2792f, 2797, 2801, 2806, 2810, 2815, 2819, 2824, 2833. 

Changes according to my email of 13th March (Adslmib digest #77) were made to, or between, the following (old) lines:

805-808f, 830, 2252, 2704, 2719-2720f.

Substantial changes were made between the following (old) lines:

548f, 678ff, 711ff, 2267f, 2879ff, 2900, 3424f, 3556ff.

The originally distributed Word file was meant to provide a major simplification for quick reviewing and discussing my comments since both the large and the tiny updates can easily be checked there.  It would also be very easy to accept or reject step-by-step individual change proposals in Word.

Best Regards,

Felix Flemisch
Siemens AG

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

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 management 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

---

From: "Randy Presuhn" <[email-masked]>
Date: Fri, 30 May 2003 22:17:54 -0700

Hi -

> From: "Flemisch Felix" <[email-masked]>
> To: <[email-masked]>
> Cc: <[email-masked]>; <[email-masked]>; <[email-masked]>; <[email-masked]>
> Sent: Friday, May 30, 2003 1:41 PM
> Subject: RE: WG Last Call: draft-ietf-adslmib-vdsl-09.txt
...
> please find attached a plain ASCII text version of the
> updated "draft-ietf-adslmib-vdsl-09.txt" that I previously
...

Thanks.

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

In the following commented "diff" output, "<" is -09-
and ">" is -09a-, with each group preceded by the line
numbers affected, and followed by my comment on the change.
I trimmed the diffs I considered harmless.
I assume the deletion of the formfeeds between pages
was an oversight.

269c280
<    and to define the behavior of the statistics to be maintained
---
>    and to define the behaviour of the statistics to be maintained

Since the rest of the document uses US English spelling,
"behavior" would be better than the British "behaviour"  (which only
looks right if one has been reading too much GDMO.  :-)

348,349c361,366
<    A VDSL Line consists of a two units - Vtuc (the central termination
<    unit) and a Vtur (the remote termination unit).
---
>    A VDSL Line consists of two units - a Vtuc (the central transceiver
>    unit) and a Vtur (the remote transceiver unit).

The "-" should not be replaced with the non-ASCII thing that
is in that position in the 09a document.

494,496c513,515
<    All objects defined in this MIB which may be set (read-write or
<    read-create), should be stored persistently.  Following is an
<    exhaustive list of these persistent objects:
---
>    All objects defined in this MIB module, which may be set (read-write
>    or read-create), SHOULD be stored persistently.  Following is
>    an exhaustive list of these persistent objects:

Rather than adding a comma, I'd remove one, resulting in a
comma-free sentence.  It'd be better if the relative pronoun
were closer to its antecedent.  Something like:

  All read-write and read-create objects defined in this MIB module
  SHOULD be stored persistently.

614c638
<                              Raleigh NC 27627-7324
---
>                              Raleigh, NC 27627-7324 USA

Suggest putting the country on a separate line,
as one would do when addressing mail.

711c753,759
<     DESCRIPTION "Brought into conformance with DSLF TR-057."
---
>     DESCRIPTION "Brought into conformance with DSLF TR-057.
>                 This means in particular that all line-code-specific
>                 (LCS) elements have been removed for both, MCM lines
>                 and SCM lines.  However, a standardized LCS VDSL Line
>                 Extension MIB module is seen as a MANDATORY supplement
>                 to the VDSL-LINE-MIB since otherwise neither MCM lines
>                 nor SCM lines can be fully configured."

This is NOT the place for putting conformance material,
so the second sentence should be removed, in my opinion.
The phrase "MANDATORY supplement" strikes me as oxymoronic
at best.  Even if the WG agrees with this addition, the
punctuation needs to be fixed: delete the first comma, and
add a comma before "since."

723c771,779
<     ::= { transmission xxxx }
---
>
>     REVISION "200305290000Z" -- May 29, 2003
>     DESCRIPTION "Added vdslLineConfLineType,
>                 added note to DESCRIPTION of MODULE-IDENTITY
>                 regarding necessity of LCS MIB extensions,
>                 corrected mechanical and editorial flaws,
>                 added various clarifications."
>
>     ::= { transmission 97 }

Uh..... Did IANA make this assignment?
In any case, the REVISIONS should be chopped down to
the "initial version" one.

805,808c863,869
<             fastOnly(2),          -- fast channel only
<             slowOnly(3),          -- slow channel only
<             either(4),            -- either fast or slow channel exist
<             both(5)               -- both fast and slow channels exist
---
>             fastOnly(2),          -- fast channel exists only
>             interleavedOnly(3),   -- interleaved channel exists only
>             fastOrInterleaved(4), -- either fast or interleaved
>                                   -- channels can exist, but
>                                   -- only one at any time
>             fastAndInterleaved(5) -- both fast and interleaved
>                                   -- channels exist

phrases of the form "NP exists only " should be
"only NP exists", since "only" is functioning as
a quantifier for the noun phrase rather than
as an adverb.

815c876
<             the line is channelized.  If the line is channelized,
---
>             the line is channellized.  If the line is channellized,

This looks really strange to me.  Is it a British spelling?

819c880
<             In the case that the line is channelized, the manager
---
>             In the case that the line is channellized, the manager

Ditto.

830c893
<         REFERENCE    "T1E1.4/2000-009R3"    -- Part 1, common spec
---

Why do you think the reference should be deleted?

839c902
<             in the VDSL Line Configuration Profile Table,
---
>             in the VDSL Line Configuration Profile Table

Since the parenthesized word in the following line is
really an appositive, just moving the comma isn't quite right.
Suggest removing the parens, so that the appositive can be
punctuated normally (preceded and followed by commas).

948c1015
<             -31.75 to +31.75dB."
---
>             -31.75..+31.75 dB."

This is much harder to read than the original.
I don't see any value to be gained from changing "to" to ".."
I do, however, like the added space before "dB".

960c1027
<             The effective range is 0 to +63.75dB."
---
>             The effective range is 0..+63.75 dB."

This is much harder to read than the original.
I don't see any value to be gained from changing "to" to ".."
I do, however, like the added space before "dB".

1007,1008c1076,1077
<                                      the transceiver is in the 'Warm
<                                      Start' state.
---
>                                      the transceiver is in the "Warm
>                                      Start" state.

NO!  This is a syntax violation.

2205c2314
<             A default profile with an index of 'DEFVAL', will
---
>             A default profile with an index of `DEFVAL', will

Talk to any typographer for a sermon on why "`" is not
appropriate for use as a quote character in English.  :-)

2278c2390
<             A default profile with an index of 'DEFVAL', will
---
>             A default profile with an index of `DEFVAL', will

See previous comment.

2322c2436
<             level in the range 0..14.5dBm."
---
>             level in the range 0..14.5 dBm."
2333c2447
<             level in the range 0..14.5dBm."
---
>             level in the range 0..14.5 dBm."

Based on reaction to previous, suggest replacing
".." with " to "

2732c2877,2879
<             "The upstream PSD template to be used for the line."
---
>             "The upstream PSD template to be used for the line.
>             It depends on vdslLineConfApplicableStandard."
>         REFERENCE    "DSLF TR-057"            -- section 2.4

What does "depends" mean here?

2744c2891,2893
<             "The downstream PSD template to be used for the line."
---
>             "The downstream PSD template to be used for the line.
>             It depends on vdslLineConfApplicableStandard."
>         REFERENCE    "DSLF TR-057"            -- section 2.4

What does "depends" mean here?

2776a2930,2934
>             ANSI T1.424-1 [T1E1311] and ETSI TS 101 270-1 [ETSI2701]
>             extend the VDSL spectrum up to 30 MHz and therefore define
>             additional five HAM bands (see normative Annex 1 of T1.424-1
>             and Section 9.3.3.6.1 of TS 101 270-1), not considered here.

typos:
     "additional five" -> "five additional"
     ")," -> ")"

Also, if you're going to use the acronym "HAM", you should
provide an expansion.

2797c2957
<         UNITS        "kHz"
---
>         UNITS        "Hz"

Is this change intentional?

2806c2966
<         UNITS        "kHz"
---
>         UNITS        "Hz"

Is this change intentional?

2815c2975
<         UNITS        "kHz"
---
>         UNITS        "Hz"

Is this change intentional?

2824c2984
<         UNITS        "kHz"
---
>         UNITS        "Hz"

Is this change intentional?

2879a3042,3063
>     vdslLineConfLineType OBJECT-TYPE
>         SYNTAX       INTEGER
>             {
>             noChannel(1),         -- no channels exist
>             fastOnly(2),          -- fast channel exists only
>             interleavedOnly(3),   -- interleaved channel exists only
>             fastOrInterleaved(4), -- either fast or interleaved
>                                   -- channels can exist, but
>                                   -- only one at any time
>             fastAndInterleaved(5) -- both fast and interleaved
>                                   -- channels exist
>             }
>         MAX-ACCESS   read-create
>         STATUS       current
>         DESCRIPTION
>             "This parameter provisions the type of VDSL physical line
>             entity that shall exist, by defining whether and how
>             the line shall be channellized.  If the line is to be
>             channellized, the value will be other than noChannel(1).
>             This object defines which channel type(s) are supported."
>         ::= { vdslLineConfProfileEntry 45 }

No DEFVAL?

2926c3112
<             A default profile with an index of 'DEFVAL', will
---
>             A default profile with an index of `DEFVAL', will

Please, "'" instead of "`"!

Finally, one "blanket" item regarding the enumeration "interleave":
would it make sense to change it to "interleaved"?  This would result
in a smaller number of changes, and would read better.

Randy

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