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.
************************************************************************************