Re: Technical comments on draft-ietf-adslmib-vdsl-ext-mcm-02. txt
"Randy Presuhn" <[email protected]>
| Newsgroups | gmane.ietf.adslmib |
|---|---|
| Message-ID | <005b01c415d6$7a7e51e0$7f1afea9@oemcomputer> |
Hi - > From: <[email protected]> > To: <[email protected]> > Cc: <[email protected]> > Sent: Monday, March 29, 2004 6:24 AM > Subject: FW: [Adslmib] Technical comments on draft-ietf-adslmib-vdsl-ext-mcm-02. txt ... > vdslLineMCMConfProfileTable: "The entries in this table MUST NOT be used > for single carrier (SCM) VDSL lines." What enforces this constraint? > > >>>>> > > Menachem: I will remove this sentence. This doesn't address the underlyng issue. What happens when the profile for an SCM line uses a name that has MCM entries? My proposal, as someone who knows nothing about this technology, would be to use words something like this: "If an entry in this table is referenced by a line which is does not use MCM, it has no effect on the operation of that line." ... > vdslLineMCMConfProfileEntry: "A default profile with an > index of 'DEFVAL', will always exist" begs the question: > when there is a vdslLineConfProfileEntry with an index of "DEFVAL", will > it apply to *both* the MCM and the SCM "DEFVAL" entries? > > > >>>>>> > > Menachem: I will remove this sentence. As these are optional a > default value is not necessary. Disagree. The "DEFVAL" row is not a default value; it is a default profile, which is required to exist in implementations of this MIB module. The underlying question is whether it is possible / meaningful to have default profiles for both SCM and MCM lines, and if it is, whether there would be any problem from them both having the index of "DEFVAL", since there would be attributes required to have the same values for both as a consequence of any "shared" profile configuration tables. ... > Additional Editorial comments: > RFC 3667 section 5.1 requires an "IPR Disclosure Acknowledgement" > > >>>>>> > > Menachem: I'll add this section before the Full Copyright ... I'm checking with Scott Bradner to find out whether this is the right place for it, since it will be removed at RFC time. Randy