[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Comments on new draft-ietf-atomib-rfc2558bis-01.txt (Fwd)

i agree with all mike's points made below.
in addition i'd observe the following:
- technology keeps moving; our challenge is
  to define a spec that reflects rough consensus
  backed up by implementation experience.
  2558bis has met that criteria.
- the comment seems to come in two parts
  (a) new interpretations of SES parameters
  (b) updated and new references
- on (a) the question must be asked: does this
  deprecate current objects. the answer is no, because
  the specs that 2558bis is based on are widely implemented.
  it does raise a question on what to do in the future.
  additions to the current spec have been suggested in
  the past, and the consensus was to do any new work
  in a supplemental mib. no energy has been devoted
  to this yet.
- on (b) the question is: do the additional references
  add to currently defined objects. the answer
  is that they might; no analysis has been presented on that
  but it may fit in the supplemental mib work mentioned above.
  or the question is: do the additional references
  deprecate the semantics of currently defined objects.
  as in (a) the deployed base of equipment suggests
  that this is not a good idea.
  i noted also that the comment refers to *new* work (e.g., G.828)
  which usually corresponds with a much smaller installed base.

in summary, i dont think that this comment should be in the
critical path of progressing 2558bis.
however, solid proposals for elements of a supplemental
mib should be considered.

kaj





At 10:47 AM 2/7/2003 -0800, C. M. Heard wrote:

Erik,

Several times during the multi-year process that led to
draft-ietf-atomib-rfc2558bis-01.txt the WG got comments
from individuals who were not satisfied with the level
of support for current European standards.  At each point
the individuals making those comments were requested to
propose specific changes to the text of the draft.
No such proposals were received, consequently no such
changes were made.  That history is readily available
from the atommib mailing list archives;  if you, or
other IESG members, want some backup for these assertions
let me know and I will be glad to provide either pointers
by date and thread or actual copies of the messages.

The MIB module as written does seem to enjoy significant
deployment (witness the five implementations reported)
and has met the requirements for advancement to draft
standard.  There is an urgent need to get the document
published in order to make official the enumerated
values for to sonetPathCurrentWidth that support
STS-192c/STM-64 and STS-768c/STM-256 paths.

It is always frustrating to everyone to get requests
for changes late in the process.  It is particularly
frustrating to WG participants when they are of the
form "you need to support standard xyz" but without
specific proposals for changes to the text.  It is
doubly frustrating when the WG has received such
comments in the past, asked the proponents to propose
specific changes to the text, and got no proposals.
My opinion is that the time for considering change
requests such as the one below passed long ago.

Thank you.

Mike Heard


On Fri, 7 Feb 2003, Erik Nordmark wrote:

> >----------------Begin Forwarded Message----------------<
>
> Date: Wed, 5 Feb 2003 08:58:23 +0000
> From: "Malcolm Jones" <malcolm@mejones.demon.co.uk>
> Subject: Comments on new draft-ietf-atomib-rfc2558bis-01.txt
> To: iesg@ietf.org
>
> I note that there is no mention of the current performance ITU-T
> Recommendation G.828 which has replaced G.826 for new work.
> ITU-T G.828 calls for higher performance than G.826 and also introduces
> a recognition of short interrupt events that were not part of G.826.
>
> There is also a hidden assumption in the older recommendations that an
> SES is the same throughout the signal processing involved in terminating
> line systems. This assumption no longer holds as it has been recognised
> that there is so much processing in modern line systems that an SES will
> be declared at some layers but not at others. This only happens on the
> border line, of course, but in the modern commercial environment of
> telecomms it is important.
>
> The heavy reliance on American standards is non-optimum for
> international connections. Is this really necessary? There are several
> ITU-T recommendations for maintenance issues in the M series which have
> been agreed internationally.
>
> For Transport systems using satellites the relevant ITU-R
> recommendations are S.1521 for error performance, S.1522 for short
> interrupts and S.579 for availability (under extensive revision along
> with the corresponding ITU-T recommendation G.827). There is a similar
> set of ITU-R recommendations for the microwave radio relay transmission
> systems.
>
> I hope that this draft may be revised to include these few comments.
>
> Regards
>
> --
> Malcolm Jones
> >----------------End Forwarded Message----------------<
>


_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/

Kaj Tesink
Telcordia Technologies. In.
331 Newman Springs Road
Red Bank, NJ 07701
Email: kaj @research.telcordia.com
Tel: (732) 758-5254
Fax: (732) 758-4177

_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/