Feedback on CU MIB

Hi Edward,
	I had a look on the MIB. Here is ome feedback on that

Section 3.1, foruth line	it says'The stack management in done via
...' I guess you mean 'is' done ..

Section 3.1.1 This section is tough and I believe that is the key
section. Knowing the technical background I know what your're talking
about (see attached drawing, which contains an example). If all my
assumptions are correct I would suggest the following:
1. Add a schematic drawing and show the values of the different tables
(or is this not the intention of the RFC)
2. Add that after reset and no PAF discovery both ifstacktable and
infinvstacktable are empty

Section 3.1.3. Chapter 'Adding a PME to the ifstacktable...' There
you're saying that a successful discovery automatically puts it to the
PME aggregate -> is this really the intention? Section 3.1.4 seems to be
written in the same way, if links can be aggregated, they will be
aggregated

Section 3.4 different objects for -O and -R devices - Clause 45 has a
respective mechanism to distinct both types. From an application point
of view, especially for SHDSL it doesn't seem to make sense, but the DMT
people should decide on this (so based on thi statement, I guess it is
good to have it, where I would expect that it will only be used by VDSL

Table 2 contains 2 times aPAFID in the elxt column (and the same mapping
in the right column) 

I'm still working on all the different variables, but I also wanted to
share my ideas with you and the community.

Regards

Mathias
 <<object_mapping.pdf>>

_______________________________________________
Hubmib mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/hubmib