Hi Vinay,
These all look good. I will note that you should make the
LAST-UPDATED match the day you submit the draft.Regards, Brian On 9/10/15 10:54 AM, vinays wrote: > > > Hello Brian, > Thanks for the review. Here are the responses to your comments. Please > let us know if you are okay > with this, so we can submit a newer revision. > > comment #1. > >>> * I ran the extracted MIB through a couple of on-line MIB compilers and >>> got some unexpected errors. Please let me know if these are not fixable >>> (and why). >>> >>> - 647 1 syntax error, unexpected NUMBER, expecting LOWERCASE_IDENTIFIER >>> - 1202 2 unknown type `ClockQualityAccuracyType' >>> - 1343 2 type `ClockQualityAccuracyType' of node >>> `ptpbaseClockParentDSGMClockQualityAccuracy' does not resolve to a known >>> base type >>> - 1484 2 type `ClockQualityAccuracyType' of node >>> `ptpbaseClockDefaultDSQualityAccuracy' does not resolve to a known >>> base type >>> > > responses for this comment: > 1. The error in 647 is due to the double comment in the same line. > -- reserved00(0:31), -- 0x00 to 0x1F^M > > > We should be able to address this by fix this line as: > > -- reserved00(0:31), for 0x00 to 0x1F^M > > 2. All the other errors in 1202, 1343, 1484 should be resolved by the > above fix. > > > > comment #2. > >>> * The LAST-UPDATED field is out of date. >>> > > response for this comment: > will change the line > LAST-UPDATED "201508260000Z" > > as below to address this: > > LAST-UPDATED "201207230000Z" > REVISION "201508260000Z" -- 26 Aug 2015 > DESCRIPTION > "Draft revision #8, for last call." > > > > comment #3. >>> * I like the level of detail in the main DESCRIPTION clause. This made >>> me a little disappointed with many of the object DESCRIPTION clauses >>> that did not provide a useful level of detail on the object. In >>> particular, I would like to see a greater level of clarity in the >>> DESCRIPTION clauses for the Tables. For example, I have no way of >>> knowing what "count information" means in the ptpbaseSystemTable. >>> > > response for this comment: > We will address this comment by adding some more clarifications in the > DESCRIPTION clauses. > > > comment #4. > >>> * The ptpbaseSystemDomainEntry uses "router" in its description and then >>> ptpbaseSystemDomainTotals uses "node". I would have expected them to be >>> the same. I think "nodes" is more appropriate. >>> > response for this comment: > We will use the generic term 'node' replacing the term 'router' > through the draft. > > > comment #5. > * Some of the REFERENCE clauses may not have a sufficient level of > detail to stand on their own (e.g., ptpbaseClockCurrentDSMeanPathDelay). > Please review all REFERENCE clauses and ensure they can stand on their > own when the reference sections are not available (i.e., after > extraction and installation in a network manager). > > response for this comment: > We will make the reference clauses consisent so they can stand on > their own. > ##-- > > > Thanks, > -Vinay. > > > > On 8/26/15 9:32 PM, vinays wrote: >> >> Thanks Brian for the review comments and apologies for the delayed >> response. >> >> We will work on the comments and respond back as soon as possible. Its >> been a while for us since we worked on this draft, and hence the delay, >> >> Regards, >> -Vinay. >> >> >> On 8/24/15 12:47 PM, Brian Haberman wrote: >>> All, >>> I have completed my AD Evaluation of the PTP MIB. I have a few >>> comments and once they are resolved, this draft can move to IETF Last >>> Call. Let me know if you have any questions/concerns on these... >>> >>> * I ran the extracted MIB through a couple of on-line MIB compilers and >>> got some unexpected errors. Please let me know if these are not fixable >>> (and why). >>> >>> - 647 1 syntax error, unexpected NUMBER, expecting LOWERCASE_IDENTIFIER >>> - 1202 2 unknown type `ClockQualityAccuracyType' >>> - 1343 2 type `ClockQualityAccuracyType' of node >>> `ptpbaseClockParentDSGMClockQualityAccuracy' does not resolve to a known >>> base type >>> - 1484 2 type `ClockQualityAccuracyType' of node >>> `ptpbaseClockDefaultDSQualityAccuracy' does not resolve to a known >>> base type >>> >>> * The LAST-UPDATED field is out of date. >>> >>> * I like the level of detail in the main DESCRIPTION clause. This made >>> me a little disappointed with many of the object DESCRIPTION clauses >>> that did not provide a useful level of detail on the object. In >>> particular, I would like to see a greater level of clarity in the >>> DESCRIPTION clauses for the Tables. For example, I have no way of >>> knowing what "count information" means in the ptpbaseSystemTable. >>> >>> * The ptpbaseSystemDomainEntry uses "router" in its description and then >>> ptpbaseSystemDomainTotals uses "node". I would have expected them to be >>> the same. I think "nodes" is more appropriate. >>> >>> * Some of the REFERENCE clauses may not have a sufficient level of >>> detail to stand on their own (e.g., ptpbaseClockCurrentDSMeanPathDelay). >>> Please review all REFERENCE clauses and ensure they can stand on their >>> own when the reference sections are not available (i.e., after >>> extraction and installation in a network manager). >>> >>> Regards, >>> Brian >>> >>
signature.asc
Description: OpenPGP digital signature
_______________________________________________ TICTOC mailing list [email protected] https://www.ietf.org/mailman/listinfo/tictoc
