Re: [802SEC] IEEE 802 PARs under consideration in March
Tony,
I came across Richard's comments while searching the EC reflector for
references to PARs for consideration at the upcoming plenary. I was
doing that search so I could prepare a web page listing all of the
relevant materials for use by 802.16 in reviewing the PARs. I
compiled the page of PAR links and notified the EC reflector by
mistake; I meant to notify 802.16 only.
Now that my note's gone to the EC reflector, and noting your
objection, I've deleted the web link to Richard's comments. However,
those comments (and yours) may still be of interest to 802.16. I pass
your comments along to the WG.
Regards,
Roger
>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