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

From: Erik Nordmark <[email-masked]>
Date: Fri, 7 Feb 2003 17:28:10 +0100 (CET)

>----------------Begin Forwarded Message----------------<

Date: Wed, 5 Feb 2003 08:58:23 +0000
From: "Malcolm Jones" <[email-masked]>
Subject: Comments on new draft-ietf-atomib-rfc2558bis-01.txt
To: [email-masked]

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

---

From: "C. M. Heard" <[email-masked]>
Date: Fri, 7 Feb 2003 10:47:33 -0800 (PST)

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

---

From: Kaj Tesink <[email-masked]>
Date: Fri, 07 Feb 2003 18:41:36 -0500

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

> > I hope that this draft may be revised to include these few comments.

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

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

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