Thread Links | Date Links | ||||
---|---|---|---|---|---|
Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
Glen, I think, generally, we are on the same page. A difference for me, though, is that I don’t understand why it is necessary to force the stack to have only ONE instance of OAM. As I hope to point out in the slides, if we are not adding additional requirements or clarifications about other protocols in the MAC layer (below UMT), then we don’t need them in the diagrams… it just adds confusion and unnecessary complexity. There is ample precedent for this approach and I give examples in the slides (OAM and MAC Control are two). Also, don’t we need an instance of the OAM Sublayer above UMT, also? This is a topic I was going to bring up later or during the discussion tomorrow… if OAM is expected to work across a UMT, then it will need (at a minimum) the Control function in the OAM sublayer in addition to the OAM client. Your diagram also precludes MAC Control from being a user of UMT. While I can’t see a practical use-case for MAC Control over UMT, I think that explicitly excluding it is unnecessary. —kan—
To unsubscribe from the STDS-1904-WG list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-1904-WG&A=1 |