IETF58 and other issues

Hi,

While there has been a bit more traffic on the list and the work seems=20=

to be moving forward, I am still not sure whether there is enough=20
activity at the moment to warrant a WG meeting in Minneapolis.

I would like to hear, on the list,  from anyone who has an issue that=20
they feel should be discussed at the meeting.  I would also like to=20
hear from anyone who is submitting a draft and feels the need to=20
discuss it in the face to face forum.

I will be submitting an update to the base draft later today or=20
tomorrow that includes fixes to the issues that Jay brought up in his=20
message.  Basically I fixed the typos and added the extension block to=20=

the configuration message.   I also made some changes to the capability=20=

set block. QAs the addition of the general extension block there did=20
not seem to work as well as it should i made the extension more=20
specific to the capability set functionality.   I don't expect anyone=20
had tried to use it yet since they would have screamed, figuratively,=20
at me if they had.  As usual, i will be looking for comments and issues=20=

once it comes out.

Finally, Kenneth and I are working on a rework of our schedule.  We=20
have, obviously missed our remaining milestones by a long way.  One of=20=

the ideas we have had is to break the major milestone:

> Dec 02
> =A0=A0
> Submit GSMPv3 extensions to include control of switches  supporting=20
> optical, TDM and other CCAMP features and any  updates of the base=20
> spec for Proposed Standard

Into 3 milestones:

- submit rewritten base and packet specification  to the IESG for PS=20
consideration
- submit optical spec   to the IESG for PS consideration
- submit tdm spec   to the IESG for PS consideration

the reason for subdividing them are:

-the work of dividing up the spec as we have done was not planned when=20=

the milestone where first written, it was the result of looking at the=20=

effect of adding all of the TDM and Optical content to RFC 3292 and=20
realizing that it would be too cumbersome and insufficiently versatile.=20=

  It has also taken more effort then was originally thought as the=20
packet and base were so intimately intertwined in the original.
-the base and packet specs together essentially reproduce the=20
functionality of current RFC 3292 and are, in my estimation, the=20
closest to being done.  With a little bit of focus, they could be ready=20=

for WG last call before IETF59.   Additionally the current MIB,=20
RFC3295, covers this functionality and should need little or no=20
revision.
-the optical spec and the tdm spec are individual documents and each=20
requires a supporting MIB.  While the optical spec is in progress,=20
neither the TDM spec nor the MIBS are as of yet.  So reasonable=20
schedules for these need to be worked out.

Opinions?  discussion?

thanks

a.=