Subject: FW: Evaluation: draft-ietf-atommib-rfc2558bis - Definitions of Ma naged Objects for the SONET/SDH Interface Type to Draft Standard

From: "Wijnen, Bert (Bert)" <[email-masked]>
Date: Wed, 2 Apr 2003 12:35:27 +0200

During IESG review, we got this comment, and I responded as
shown. Can the authors (or anyone else) come up with a possibly
better wording? If so, we need it today (or at the very latest
tomorrow by say 9am US Eastern).

Thanks,
Bert 

-----Original Message-----
From: Wijnen, Bert (Bert) 
Sent: woensdag 2 april 2003 12:33
To: 'Steven M. Bellovin'; IESG Secretary
Cc: Internet Engineering Steering Group
Subject: RE: Evaluation: draft-ietf-atommib-rfc2558bis - Definitions of
Managed Objects for the SONET/SDH Interface Type to Draft Standard 

Steve writes:
> This is probably due to my ignorance of MIB construction, but...
> 
> Some items say "Supports read-only access" or "just read-only access
> may be supported," which I assume means "this variable may be 
> implemented as read-only if you wish".  I'm not thrilled with the 
> wording; I'm even more concerned that it's only specified for a few 
> items.  Why, for example, isn't that true of 
> ifConnectorPresent, which is described as "Set to true(1)"?
> 
Well, the above is all in the section
   3.2.  Use of ifTable for SONET/SDH Medium/Section/Line Layer
Such a section is mandatory for all MIB documents that build
in the IF-MIB (RFC2863). They have to explain how various
entries in the ifTable show up for the specific technology.

W.r.t. details:
- If you look at RFC2863, page 51/52, then you will see that it is OK
  (according to the compliance) if the object ifAdminStatus is
  implemented in read-only mode. I think the text in sect 3.2 is
  repeating that (machine readable) compliance statement.
- Same for ifLinkUpDownTrapEnable, see RFC2863 page 51
- For ifConnectorPresent, this object in fact is a read-only object
  see RFC2863 page 43. What sect 3.2 states here is that this is in
  fact representing a "physical" interface as opposed to a "logical"
  interface.

I am checking with the authors if they can think of better wording
that we can put out as RFC-Editor note.

Hope this helps/explains,
Bert

---

From: "C. M. Heard" <[email-masked]>
Date: Wed, 2 Apr 2003 08:11:50 -0800 (PST)

Bert, Steve, and WG --

I'm not the document author, but please allow me to jump in anyway
with the following suggestions in an attempt to satisfy the IESG
review comments quoted below.

In the description of ifAdminStatus in Sections 3.2, 3.3., and 3.4,
please change:
                        Supports read-only access.
to:
                        May be implemented with read-only access.

In the description of ifLinkUpDownTrapEnable in Sections 3.2, 3.3.,
and 3.4, please change:
                        Just read-only access may be supported.
to:
                        May be implemented with read-only access.

These changes are intended just to improve the wording (which was left
unchanged from RFC 2558) while leaving the meaning unchanged.

As Bert has pointed out, these words are simply re-iterating the
machine-readable information in the IF-MIB compliance statements.
These objects were singled out for special mention because they are
the only writeable control objects (with potentially traffic
disrupting effects) in the IF-MIB that apply to this type of
interface;  the rest of the stuff in the IF-MIB is either read-only
(like ifType) or not traffic affecting (like ifAlias).  In any case,
all that Sections 3.2, 3.3, and 3.4 of this document are required to
do is to specify certain information that is deliberately left open
by the IF-MIB document RFC 2863 and required to be specified by
media-specific MIB documents such as this one.  We shouldn't try to
repeat all of the stuff in RFC 2863.

Would everyone be OK for the document to go forward with just the
wording changes proposed above?

Thanks,

Mike Heard

---

From: "Steven M. Bellovin" <[email-masked]>
Date: Wed, 02 Apr 2003 11:16:41 -0500

In message <[email-masked]>, "C. 
>wording changes proposed above?

Works for me.  Thanks.

		--Steve Bellovin, http://www.research.att.com/~smb (me)
		http://www.wilyhacker.com (2nd edition of "Firewalls" book)