Thread Links Date Links
Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

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

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.