Re: [802SEC] IEEE 802 PARs under consideration in March
At 20:33 23/02/2004, Roger B. Marks wrote:
>Eleven PARs were submitted for consideration by the IEEE 802 LMSC
>Executive Committee at the March Plenary:
> http://ieee802.org/16/meetings/mtg30/lmsc/pars.html
>
>Comments to the proposing Working Group are due by 5 pm on Tuesday
>(16 March). Responses are due by 5 pm on Wednesday (17 March).
>
>I hope you will review not only the wireless PARs but also the 802.1 PAR
>and the associated response in the link.
>
>If you have comments, please let me know by 8 March in case we need to
>include a topic on the 802.16 Opening Plenary agenda.
Roger -
Since you have chosen to attach Richard Brand's comments on the draft 802.1
PAR to your web page detailing the PARs that are up for consideration in
March, I feel that some points deserve clarification relative to his
contribution on this subject.
Firstly, given Richard's assertion of his status as (one of the) liaison(s)
from 802.3 to 802.1, and the consequent possibility of an implied
association between his comments with an 802.3 position, I would point out
that there has been no formal 802.3 discussion on this subject, nor
direction from 802.3 to its liaisons as to what 802.3's position might be
following such a discussion. His comments can only therefore be taken to be
his own opinion as an expert; he should have clarified that in his email,
in line with existing P&P. Consequently, I must request that you do one of
two things. Either:
a) Remove the link to his message, thereby removing the implication that
somehow this one expert's opinion is more worthy of consideration than all
other opinions that have been expressed on this subject, within 802.1 and
elsewhere; or
b) Add to your website all comments that have been made by experts on *all*
the pars that are under consideration for March, in whatever fora those
comments have been made.
<<As an aside, the link you have used is to a copy of the message on the
SEC email archive; as Richard is not on the SEC exploder, and as the SEC
exploder is, if I remember rightly, closed, I believe that this message was
never actually forwarded by Majordomo to the SEC. Apparently, a quirk of
the archiving mechanism means that messages are archived prior to applying
any filters. So I believe this message should not appear in the SEC archive
at all, and Bob O'Hara should take the necessary steps to remove it from
the archive.>>
Secondly, the email implies that somehow, 802.1 is attempting to "...define
fault management for carriers", in the absence of input from those
carriers. If the author had been present during the presentations on this
subject at the January interim, which he might have felt to be appropriate
given his role as a liaison to 802.1, he would have understood that this
piece of work is actually the result of interaction between 802.1 and
relevant groups in ITU-T such as SG13 Q.3/13; the architecture that gives
rise to this requirement is theirs, not ours, and the initial encouragement
to do this work came from them. This interaction and cooperation is
ongoing; we will be taking a liaison contribution from ITU-T SG13 Q.3/13 on
this subject in March, given by Hiroshi Ohta, a rapporteur of ITU-T SG13
Q.3/13.
Thirdly, the email implies that somehow this PAR is of wide concern to all
the MAC groups in 802. The mechanism that we are considering here is
Bridge-centric, deliberately placed at layer 2 and above the MAC service
boundary, in line with the ITU-T layered approach to this kind of
fault detection, with the express intent that it will NOT be MAC-specific,
nor will it require special services to be provided by underlying MACs, nor
will it require special changes to be made in the standards for the
underlying MACs. I would concede that the *general* topic of fault
detection in heterogeneous networks is of wide and general interest (and
indeed, one that could occupy us far into the next millennium, never mind
the next couple of meetings); however, the specific topic of limited,
Bridge-centric, fault detection, using mechanisms above the MAC, is not.
Regards,
Tony