Hi Kevin,
Thank you for taking the time to go through this MIB. We did consider your
comments, and they were addressed in -05 (the latest version, and the subject
of the last call). I've gone through each of your comments below; it looks
like we missed one, and decided against another, but the remainder have been
done.
The change history from the -05 draft reads:
-05 Feb 13 Several changes in response to comments from Alun Luchuk
and Kevin Gross:
- Modified the use of wellKnownTransportTypes and
wellKnownEncapsulationTypes
- changed ptpbaseClockPortSyncOneStep to
ptpbaseClockPortSyncTwoStep to match IEEE1588
semantics
- Re-ordered textual conventions to be alphabetic
- Changed some types from Integer32 to use defined
textual conventions
- various minor descriptive text changes
In detail:
Abstract: Add a bracketed reference to IEEE 1588-2008 - DONE
Section 1: s/defined to monitor, measure the performance/defined to monitor and
measure the performance - DONE
Section 1.1 What in this MIB is profile dependent? I did not identify anything
in my review. It would be desirable. if possible, to have a
profile-independent MIB.
- TF: Removed erroneous text about Telecom Profile - there is nothing in
this MIB that is particular to that profile.
TEXTUAL-CONVENTION general issues - Consider alphabetizing - DONE
ClockInstanceType TEXTUAL-CONVENTION definition - Description requires
elucidation or a reference.
- TF: not done, looks like this one slipped through.
ClockProfileType TEXTUAL-CONVENTION definition
Consider using and OUI instead of an enumeration. IEEE 1588-1588 requires an
OUI be associated with each profile.
- TF: OUI would be specific to the organization, not the profile. If the ITU
(for instance) developed more than one profile, then they would have the same
OUI. Therefore it is best (in the authors' opinion) to stick to using an
enumeration
OBJECT-TYPE general issues
Consider being consistent about repeating TEXTUAL-CONVENTION descriptions,
explicitly referencing them or assuming readers will track down the reference
without reminder.
- TF: We've tried to be as consistent as we can. Of 17 TEXTUAL-CONVENTIONS,
13 are directly referenced to IEEE1588 sections. The remainder don't directly
map onto IEEE1588 quantities, but onto associated concepts, and we have tried
to explain these in the description. Certainly one could do with a better
description, as you note above.
ptpDomainClockPortsTotal OBJECT-TYPE
I assume this is the number of ports for the managed PTP-capable system (i.e. a
router or switch). Suggest adding "in the system" to the description to clarify
scope of count. - DONE
ptpbaseClockTimePropertiesDSTable OBJECT-TYPE
s/clock Timeproperties Datasets for/clock time properties datasets for - DONE
PtpbaseClockTransDefaultDSEntry SEQUENCE
Use ClockDomainType textual convention instead of Integer32 for
ptpbaseClockTransDefaultDSPrimaryDomain - DONE
PtpbaseClockPortEntry SEQUENCE
Change ptpbaseClockPortSyncOneStep to ptpbaseClockPortSyncTwoStep to match 1588
semantics for this Boolean - DONE
ptpbaseClockPortRunningEncapsulationType OBJECT-TYPE
Needs a textual convention or description of allowed values and their meanings
- TF: Now uses an autonomous type instead of Integer32
ptpbaseClockPortTransDSlogMinPdelayReqInt OBJECT-TYPE
Change to ClockIntervalBase2 type DONE
Section 5: Copy-paste error: "creation and/or manipulation of tunnels"
- TF: Section changed since -03, no longer has this phrase.
Section 6: To be added - DONE
Best regards,
Tim Frost
From: [email protected] [mailto:[email protected]] On Behalf Of
Kevin Gross
Sent: 16 May 2013 18:09
To: Karen ODonoghue
Cc: [email protected]
Subject: Re: [TICTOC] WGLC on draft-ietf-tictoc-ptp-mib-05.txt
I submitted comments on v03 11 January
(http://www.ietf.org/mail-archive/web/tictoc/current/msg01331.html). Vinay
indicated in a short message on 23 January the comments would be addressed in
the next version
(http://www.ietf.org/mail-archive/web/tictoc/current/msg01333.html). v04 was
published 31 January. I did not see any notes from the authors associated with
that revision. A quick check of the v03-v04 diff shows evidence that not all my
comments were directly addressed. Can I get a summary of how my comments were
addressed? I'm fine if some of these were rejected but I would like to verify
that they were given consideration.
Kevin Gross
+1-303-447-0517
Media Network Consultant
AVA Networks - www.AVAnw.com<http://www.avanw.com/>,
www.X192.org<http://www.X192.org>
On Thu, May 16, 2013 at 9:41 AM, Karen O'Donoghue
<[email protected]<mailto:[email protected]>> wrote:
This message initiates a two week TICTOC Working Group Last Call on advancing:
Title : Precision Time Protocol Version 2 (PTPv2) Management Information Base
Author(s) : Vinay Shankarkumar, Laurent Montini, Tim Frost, Greg Dowd
Filename : draft-ietf-tictoc-ptp-mib-05.txt
Pages : 77
Date : 2013-02-25
http://datatracker.ietf.org/doc/draft-ietf-tictoc-ptp-mib/?include_text=1
as a Standards Track RFC. Substantive comments and statements of support for
advancing this document should be directed to the mailing list. Editorial
suggestions can be sent directly to the authors. This last call will end on 31
May 2013.
_______________________________________________
TICTOC mailing list
[email protected]<mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/tictoc
_______________________________________________
TICTOC mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/tictoc
