Re: [STDS-802-16] Maintenance Task Group (was: Re: Corrigenda gro up)
The Corrigenda PAR is quite clear
"This corrigendum contains substantive corrections to IEEE Standard 802.16-2004. It corrects errors, inconsistencies, and ambiguities in that standard. It does not contain new material."
Gordon
-----Original Message-----
From: Itzik Kitroser [mailto:itzikk@RUNCOM.CO.IL]
Sent: August 4, 2004 9:00 AM
To: STDS-802-16@LISTSERV.IEEE.ORG
Subject: Re: [STDS-802-16] Maintenance Task Group (was: Re: Corrigenda
gro up)
Vladimir,
I would like also to provide my perspective on this issue.
I agree with you that a well defined criteria is necessary to make our
work efficient.
I also agree with Carl, that a proposal which will not pass the defined
criteria should be rejected.
But,
Since we are dealing with an errata project, then, by definition the
scope is limited.
Since past history teaches us that relaying on people to submit only
proposals that matches the defined criteria is not realistic, then a
mechanism to save our time, and avoid endless discussion is required.
I trust the chair to be objective and to be able to decide, based on his
judgment as a chair, what passes the defined criteria and what does not.
My view is that the technical discussion should focus on the
technical/editorial proposals that pass such criteria, and avoid other
proposals.
Taking you text, "... any comment must be considered technically
including question whether it is in or out of the scope of the project
and resolved as Accepted/Accepted-Modified/Rejected/Superceded" means
that we basically vote on everything, and based on the current
membership situation of the group, can lead us into extreme situations,
in which, at best case we will be out of scope of the defined project.
Here, the procedural tool should be used to make sure that the group
will fulfill its mandate, nothing more and nothing less. Even if the
group thinks (by voting) that out of scope issues should be inserted.
Regards,
Itzik.
-----Original Message-----
From: owner-stds-802-16@listserv.ieee.org
[mailto:owner-stds-802-16@listserv.ieee.org] On Behalf Of Vladimir
Yanover
Sent: Wednesday, August 04, 2004 2:57 PM
To: STDS-802-16@listserv.ieee.org
Subject: Re: [STDS-802-16] Maintenance Task Group (was: Re: Corrigenda
gro up)
Carl,
Thanks for your letter. Basically I agree with many your statements.
Particularly, you say "Chairman of the Maintenance Task Group indicated
that
he would make a procedural decision".
For me "make a procedural decision" is the same as "to rule out". Ruling
out
is a procedural decision and the whole
point of my letter was that I am against making procedural decisions
here.
For this specific project in 99% cases to distinguish between things in
/
out of the scope we have to conduct some technical analysis.
In such situation ruling out [procedurally] certain comments is not a
productive action.
I think, category "Improvement" was misused at that meeting in Portland
to
"rule out" certain changes.
Right before the final closure of REVd there was a wide discussion and
many
people have withdrawn their
binding comments in belief that "corrigenda" activity will provide some
space [though limited] for fixes
and reasonable improvements of REVd standard.
Vladimir
> -----Original Message-----
> From: carl.eklund@NOKIA.COM [mailto:carl.eklund@NOKIA.COM]
> Sent: Wednesday, August 04, 2004 3:18 PM
> To: STDS-802-16@listserv.ieee.org
> Subject: Re: [STDS-802-16] Maintenance Task Group (was: Re:
> Corrigenda gro up)
>
>
> Vladimir,
>
> although your mail was primarily adressed to Roger I take the
> liberty of expressing my opinion.
> No comments were ruled out in Portland. In some cases the
> chairman of the Maintenance Task Group indicated that he
> would make a procedural decision that the proposed fixes were
> actually enhancements (since the task group wasn't chartered
> at the time), after consulting the group (consisting of the
> persons present at the time in the room) by means of a strawpoll.
>
> I fully agree with you that there should be published
> guidelines for what constitutes an error and what is to be
> considered an enhancement.
> I don't foresee big problems identifying contradictions or
> ambiguities. What people claim to be omissions are more
> problematic. To judge these, there should be a couple of test
> cases defined.
>
> Test cases for judging MAC related omissions could be:
> TC 1.
> Assume error free communications between the BS and the SS(s).
> Then ask the following questions:
> Is the supposedly omitted functionality essential for the
> operation in a fixed isolated single sector deployment?
> Is it impossible to achieve the supposedly omitted
> functionality by using protocols and parameters already
> defined in the spec?
>
> TC2.
> Assume a imperfect link between BS and SS(s)
> With the presently defined messages, parameters, timers and
> triggering events, related to the alleged omission, will a
> failure to receive any of the messages involved cause
> disruptive behavior, race conditions or hang ups?
> Does the proposed fix primarily address fixing the above problems?
>
>
> If the answer to any question under a testcase is No that
> particular test fails. If all (in this case both) testcases
> fail we are dealing with an enhancement and not a correction.
>
> It should be relaitively straightforward to derive similar
> criteria for any PHY enhancement. What comes to security
> where the above criteria proposed for the MAC would fail
> there is a consensus to fix things in TGe in PKMv2.
>
> BR Carl
>
>
>
>
>
>
>
>
> > -----Original Message-----
> > From: owner-stds-802-16@LISTSERV.IEEE.ORG
> > [mailto:owner-stds-802-16@LISTSERV.IEEE.ORG]On Behalf Of
> ext Vladimir
> > Yanover
> > Sent: 04 August, 2004 13:40
> > To: STDS-802-16@LISTSERV.IEEE.ORG
> > Subject: Re: [STDS-802-16] Maintenance Task Group (was: Re:
> Corrigenda
> > gro up)
> >
> >
> > Roger,
> >
> > Regarding Maintenance Ad Hoc, I would like to say that I
> > respect willing to
> > do a job in the
> > direction before formal establishment of Maintenance project.
> > But the group
> > decided to concentrate on "ruling out" certain comments.
> > I cannot really accept operations in this procedurally "grey"
> > region. I
> > believe that clear guidance must be
> > developed/published/approved before such work starts. This
> > concerns also
> > procedural part: a comment was [or was not] "ruled out", what next?
> >
> > My understanding of the WG procedure is that there is no "ruled out"
> > resolution for a comment; any comment must be considered technically
> > including question whether it is in or out of the scope of
> > the project and
> > resolved as Accepted/Accepted-Modified/Rejected/Superceded.
> > Your clarification would be appreciated.
> >
> > Such resolution may be not simple as it probably looks. If
> > there are parts X
> > and Y in REVd that contradict each other,
> > so fixing comment might be formally "ruled out" as it
> > contradicts at least
> > one of them and thus "breaks backward compatibility".
> >
> > If a comment fixes catastrophic performance failure is it in
> > or out? I don't
> > want to argue here, but it must be decided before the work starts.
> >
> > Vladimir
> >
> > > -----Original Message-----
> > > From: Lalit Kotecha [mailto:lkotecha@SBCGLOBAL.NET]
> > > Sent: Wednesday, August 04, 2004 4:19 AM
> > > To: STDS-802-16@listserv.ieee.org
> > > Subject: Re: [STDS-802-16] Maintenance Task Group (was: Re:
> > > Corrigenda group)
> > >
> > >
> > > Roger,
> > >
> > > I have 2 questins in the similar line.
> > >
> > > 1. Sometimes in June 2004, you had requested for comments for
> > > Maintenance Task group and many commentary were submitted
> located at
> > >
> > > maint folder of upload.wirelessman.org. Do we need to
> resubmit these
> > > comments or they get carried forward.
> > >
> > > 2. In last session 802.16e WG deffered many comments and
> > > Reply comments
> > > to Maitenance Task Group with reasoning that these comments
> > > were out of
> > > scope of 802.16e activities. Is there some mechanism in place that
> > > those comments will be forwarded to 802.16 maint Task group or an
> > > individual comment submitter has to look into status and
> re-submit?
> > >
> > > Best Regards
> > > Lalit Kotecha
> > >
> > >
> > >
> > > --- "Roger B. Marks" <r.b.marks@IEEE.ORG> wrote:
> > >
> > > > Ran,
> > > >
> > > > Our Corrigenda PAR will be on the agenda for approval by
> > the IEEE-SA
> > > > Standards Board on September 23. The PAR was renumbered
> > by IEEE-SA,
> > > > in accordance with their numbering policy, as:
> > > > P802.16-2004/Cor 1
> > > > http://ieee802.org/16/docs/04/80216-04_41r1.pdf
> > > >
> > > > We have set up a Maintenance Task Group
> > > > http://ieee802.org/16/maint
> > > > to handle the project. Even though the project will not
> > be chartered
> > > > until after Session #33, the Maintenance TG will be
> issuing a Call
> > > > for Contributions. The deadline will be August 20 or a
> > little later.
> > > > The format will be comments, in Commentary format,
> regarding IEEE
> > > > Standard 802.16-2004.
> > > >
> > > > Roger
> > > >
> > > >
> > > > >Hi Roger, all,
> > > > >
> > > > >I'd like to query about the status of the Corrigenda
> > group 802.16h.
> > > > >What is the form of submitting comments to the group?
> > Will there be
> > > > >a call for contributions?
> > > > >
> > > > >Thank you,
> > > > >Ran
> > > > >
> > > > >===========================================================
> > > > >Ran Yaniv
> > > > >Alvarion Ltd.
> > > > >21a Habarzel St., Tel Aviv, 67910, Israel
> > > > >tel. +972-3-7674583
> > > >
> > >
> > >
> > > This mail passed through mail.alvarion.com
> > >
> > > **************************************************************
> > > **********************
> > > This footnote confirms that this email message has been scanned by
> > > PineApp Mail-SeCure for the presence of malicious code,
> > > vandals & computer viruses.
> > > **************************************************************
> > > **********************
> > >
> > This mail was sent via mail.alvarion.com
> >
> > **************************************************************
> > **********************
> > This footnote confirms that this email message has been scanned by
> > PineApp Mail-SeCure for the presence of malicious code,
> > vandals & computer viruses.
> > **************************************************************
> > **********************
> >
>
>
> This mail passed through mail.alvarion.com
>
> **************************************************************
**********************
> This footnote confirms that this email message has been scanned by
> PineApp Mail-SeCure for the presence of malicious code,
> vandals & computer viruses.
> **************************************************************
**********************
>
This mail was sent via mail.alvarion.com
************************************************************************
************
This footnote confirms that this email message has been scanned by
PineApp Mail-SeCure for the presence of malicious code, vandals &
computer viruses.
************************************************************************
************