Thanks for addressing my comments. It looks like there are two outstanding.
1. ClockInstanceType and 2. ClockProfileType It sounds like you intend to address (1) in a future revision. With regards to (2), I think you misunderstand how the profileIdentifier works. Please have a look at Section 19.3.3 of IEEE 1588-2008. This is an EUI-48, not merely an OUI. Organizations can change the bottom 24 bits to indicate new profiles or revisions of existing ones. Maintaining our own enumeration of profiles does not seem like a feasible undertaking. Kevin Gross +1-303-447-0517 Media Network Consultant AVA Networks - www.AVAnw.com <http://www.avanw.com/>, www.X192.org On Fri, May 17, 2013 at 2:33 AM, Tim Frost <[email protected]> wrote: > 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**** > > ** ** > > On Thu, May 16, 2013 at 9:41 AM, Karen O'Donoghue <[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] > https://www.ietf.org/mailman/listinfo/tictoc**** > > ** ** >
_______________________________________________ TICTOC mailing list [email protected] https://www.ietf.org/mailman/listinfo/tictoc
