Subject: [ipcdn] Docsis subscriber management mib -13, submit to IESG?

From: Wilson Sawyer <[email-masked]>
Date: Sun, 18 Jan 2004 17:13:07 -0500

Since the publication of the -13 draft of the docsis subscriber
management mib, I have received only one comment (from Eduardo, which
doesn't appear to require a change in the document). As this i-d has
been through working group last call and several rounds of mib doctor
review, I would like to submit it to the IESG.

Harrie - I think you had indicated that you wished to review the -13
draft. Could you let me know when you expect to complete your review?

If anyone else has comments, please send them to me or the working
group.

Thank you
Wilson Sawyer

_______________________________________________
IPCDN mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ipcdn

---

From: Harrie Hazewinkel <[email-masked]>
Date: Mon, 19 Jan 2004 14:35:55 +0100

Hi Wilson,

Below I have 5 points as the review.

> draft. Could you let me know when you expect to complete your review?

Some things, I found.

1) Abstract.

'The Differentiated Services MIB (RFC3289) is extended to ....'

Not sure if it is tthe correct wording. It would sound it
provides new DIFFSERV functionality.

2)  Section 2.3

Last sentence. I beleive it could be wise to add what may happen if the 
other
elements of the DIFFSERV-MIB are part of the implementation. 
Especially, they may
bge 'linked in' from the 'expected' DIFFSERV-MIB tables.

3) object docsSubMgtCpeControltable.

The DESCRIPTION clause says, 'adding four WRITEable objects', but the 
table has
5 objects. Just a nit, but maybe better to be corrected that the fifth 
is
a read-only.

4) object docsSubMgtCpeControlReset.

What happens to the entries used to index in the docsSubMgtCmFilterTable
where they are associted by docsIfCmtsCmStatusEntry if the 'reset' is 
done.
I guess they are 'garbage-collected; if not used anymore. Although, it 
is an
implementation detail it could be wise to add words for this.

5) object docsSubMgtSubFilterDownStream, docsSubMgtSubFilterUpStream,
docsSubMgtCmFilterDownStream, docsSubMgtCmFilterUpStream and
docsSubMgtFilterGroup.

Is it correct that there are only 255 filters possible? On what
is the limit based? If there is no real limit, except for implementation
detail the Integer (0..255) subset is not needed.

Harrie

---

From: Harrie Hazewinkel <[email-masked]>
Date: Mon, 19 Jan 2004 08:52:10 +0100

> draft. Could you let me know when you expect to complete your review?

I will finalise it at most the end of the week. I mainly looked at the
connection to the DIFFSERV-MIB as Bert asked me some time ago.
Sorry for the delay.

Harrie

---

From: Wilson Sawyer <[email-masked]>
Date: Tue, 20 Jan 2004 18:39:22 -0500

Harrie - thank you.

w.r.t. your first and third points, I'll add to or revise the wording.

Do you have suggested text for your second point? I had chosen to err on the
side of reticence but am willing to expand on it if you have something in
mind.

As to your point (4), the short answer is "nothing". The cmFilterTable is
unaffected, as are address entries other than "learned". Is there text which
led you to believe otherwise? If you're referring to
docsSubMgtCpeControlActive=false, then the answer is similarly "nothing" -
the docsSubMgtCmFilterEntry augments docsIfCmtsCmStatusEntry, and thus is
bound to its existence. The FilterGroupTable applies to groups of modems,
and is thus unaffected by the status of any particular modem.

As to point (5), DOCSIS signaling constrains this to a one-byte value. I can
add a comment to this effect.

- Wilson