Re: [TICTOC] WGLC on draft-ietf-tictoc-ptp-mib-05.txt

[Kevin Gross <[e-mail]>]

My original proposal was incorrect. I think we're on the right track now.

Kevin Gross
[phone]
Media Network Consultant
AVA Networks - www.AVAnw.com <http://www.avanw.com/>, www.X192.org


On Mon, Jun 10, 2013 at 12:00 PM, Greg Dowd <[e-mail]> wrote:

>  I think the confusion was that your comment suggested using an OUI, not
> a profile OID (EUI-48).  The OUI would not have been sufficient to
> distinguish multiple profiles from an organization as Tim noted.  I’ll
> review your comments with the team.  Thanks!****
>
> ** **
>
> Greg Dowd | *Symmetricom®, Inc.*****
>
> *Staff Scientist *
> 2300 Orchard Parkway, San Jose, CA 95131
> Direct:  408.964.7643
> [e-mail]  |  www.symmetricom.com****
>
> *Symmetricom.  Leading the world in precise time solutions.*****
>
> ** **
>
> *From:* [e-mail] [mailto:[e-mail]] *On
> Behalf Of *Kevin Gross
> *Sent:* Monday, June 10, 2013 10:10 AM
> *To:* Tim Frost
> *Cc:* [e-mail]; Karen ODonoghue
>
> *Subject:* Re: [TICTOC] WGLC on draft-ietf-tictoc-ptp-mib-05.txt****
>
>  ** **
>
> 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****
>
> [phone]****
>
> 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 <[e-mail]> 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:* [e-mail] [mailto:[e-mail]] *On
> Behalf Of *Kevin Gross
> *Sent:* 16 May 2013 18:09****
>
>
> *To:* Karen ODonoghue
> *Cc:* [e-mail]
> *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****
>
> [phone]****
>
> 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 <[e-mail]>
> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tictoc****
>
>  ****
>
> ** **
>