Subject: [Adslmib] I-D ACTION:draft-ietf-adslmib-gshdslbis-10.txt

From: [email-masked]
Date: Mon, 18 Apr 2005 15:46:17 -0400

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the ADSL MIB Working Group of the IETF.

	Title		: Definitions of Managed Objects for High Bit-Rate 
			  DSL - 2nd generation (HDSL2) and Single-Pair 
			  High-Speed Digital Subscriber Line (SHDSL) Lines
	Author(s)	: C. Sikes, et al.
	Filename	: draft-ietf-adslmib-gshdslbis-10.txt
	Pages		: 76
	Date		: 2005-4-18
	
This document defines a Management Information Base (MIB) module for
   use with network management protocols in the Internet community.  In
   particular, it describes objects used for managing High Bit-Rate
   Digital Subscriber Line (DSL) - 2nd generation (HDSL2) and Single-
   Pair High-Speed Digital Subscriber Line (SHDSL) interfaces.  This
   document introduces extensions to several objects and textual
   conventions defined in HDSL2-SHDSL-Line MIB (RFC 3276).  This
   document obsoletes RFC 3276.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-adslmib-gshdslbis-10.txt

To remove yourself from the I-D Announcement list, send a message to 
[email-masked] with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-adslmib-gshdslbis-10.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-adslmib-gshdslbis-10.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
_______________________________________________
Adslmib mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/adslmib

---

From: "Clay Sikes" <[email-masked]>
Date: Mon, 18 Apr 2005 17:19:29 -0400

All,

Version -10 has been submitted and is available on the IETF ADSL MIB
page.   This version addresses the issues Bert raised on 4/7/2005. In
particular, the following changes were made:

The title was changed from ...G.shdsl.bis Lines back to what it
was in RFC3276.

The Heading on the body pages was changed back to
HDSL2-SHDSL-LINE MIB.

Reorganized the sections so the TOC has a better look.

The new version of xml2rfc updated the IPR boilerplate, but also
accounts for some white-space changes. Some lines now end with a hyphen.

"The Internet-Standard Management Framework"  section was moved
such that it is the first section.

The two "Introduction" sections, which existed in RFC3276 were
combined and changed to "Overview."

The term "module" was added after "MIB" in places where it was
needed.

The "Conformance and Compliance" section was removed.

The module dates were updated

The agent compliance statements were reworked in the module.

The new version of xml2rfc add a comma when there are 3 or more
authors in references.

Imported  RFC 2578 and RFC2579 references from xml.resource.org
since the duplicate authors in the list was corrected.

Best Regards,

Clay Sikes

On 4/7/2005 12:15 PM, Wijnen, Bert (Bert) wrote:

Summary: I am not sure what to expect in
rev 10. Can Clay send me a

prelimenary version before I complete my
checking?

I have these serious concerns:

- why do we have a section 5?

The authoritative compliance and
conformance is specified in the MODULE-COMPLIANCE

and it turns out that section 5 is not in
sync with that MODULE-COMPLIANCE. So people

may get confused, no? I would remove
section 5.

- I see (PAGE 58/59):

hdsl2ShdslLineMibCompliance
MODULE-COMPLIANCE

STATUS  current

DESCRIPTION

"The section outlines compliance
requirements for this MIB."

Mmmm ... this
is not a "section" is it? But I see it was also in RFC3276.

Better wording might be:

DESCRIPTION

"The compliance statement for SNMP
entities which implement this

MIB module."

But more important, you seem to have
changed the MODULE-COMPLIANCE of RFC3276.

Normally we keep the old
MODULE-COMPLIANCE statement (maybe adapted to make

sure that old implementations can keep
their compliance with that statement) and then

we add a new one that defines the new
MODULE-COMPLIANCE for new/updated

implementations that also support the new
objects and new options of the new MIB

Module. The old MODULE-COMPLIANCE is then
often changed to a deprecated state.

Was that not discussed? Or is that what
you have in rev 10?

I will send separately a smidiff output
with annotations.

And I will await an answer to what you
have in rev 10. Maybe Clay can send me

prelimenary rev 10 before I continue to
do more checking.

If you do a rev 10, then I also have some
additional nits you may want to address.

- you may want to think about the title of
the document.

The RFC-Editor will probably not be happy
with the abbreviation/acronym

in the title:

Definitions of Managed Objects for
G.shdsl.bis Lines

It was in fact spelled out in RFC3276. So
do we have an issue with that?

- There are 2 sections titled:
"Introduction". Namely sect 1 and sect 3

Can one of the title be changed?

- In the document, I see various occurences
of the word "MIB" as a noun".

In general, we prefer to use "MIB module"
in such cases. There is one

MIB, which is composed of many MIB
modules. This MIB module is just

one of them. When you use "MIB objects",
or "MIB groups" or such,

then that is fine.

Bert

-- Paradyne Mail --