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

From: Kevin Gross <[email-masked]>
Date: Mon, 10 Jun 2013 11:10:20 -0600

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-masked]> 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-masked] [mailto:[email-masked]] *On
> Behalf Of *Kevin Gross
> *Sent:* 16 May 2013 18:09
>
> *To:* Karen ODonoghue
> *Cc:* [email-masked]
> *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-masked]>
> 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-masked]
> https://www.ietf.org/mailman/listinfo/tictoc****
>
> ** **
>

---

From: Greg Dowd <[email-masked]>
Date: Mon, 10 Jun 2013 18:00:05 +0000

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(r), Inc.
Staff Scientist
2300 Orchard Parkway, San Jose, CA 95131
Direct:  408.964.7643
[email-masked]<mailto:[email-masked]>  |  www.symmetricom.com<http://www.symmetricom.com/>
Symmetricom.  Leading the world in precise time solutions.

From: [email-masked] [mailto:[email-masked]] On Behalf Of Kevin Gross
Sent: Monday, June 10, 2013 10:10 AM
To: Tim Frost
Cc: [email-masked]; Karen ODonoghue
Subject: Re: [TICTOC] WGLC on draft-ietf-tictoc-ptp-mib-05.txt

  1.  ClockInstanceType and
  2.  ClockProfileType

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<http://www.X192.org>

On Fri, May 17, 2013 at 2:33 AM, Tim Frost <[email-masked]<mailto:[email-masked]>> 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:

             - 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-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Kevin Gross
Sent: 16 May 2013 18:09

To: Karen ODonoghue
Cc: [email-masked]<mailto:[email-masked]>
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<tel:%2B1-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-masked]<mailto:[email-masked]>> 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

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-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/tictoc

---

From: Kevin Gross <[email-masked]>
Date: Mon, 10 Jun 2013 12:23:46 -0600

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

Kevin Gross
+1-303-447-0517
Media Network Consultant

On Mon, Jun 10, 2013 at 12:00 PM, Greg Dowd <[email-masked]> 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 *
> [email-masked]  |  www.symmetricom.com****
>
> *Symmetricom.  Leading the world in precise time solutions.*****
>
> ** **
>
> *Sent:* Monday, June 10, 2013 10:10 AM
> *To:* Tim Frost
> *Cc:* [email-masked]; Karen ODonoghue
>
>    1. ClockInstanceType and****
>    2. ClockProfileType****
>
>  It sounds like you intend to address (1) in a future revision.****
>
> ** **
>
> enumeration of profiles does not seem like a feasible undertaking.****
>
>
> ****
>
> Kevin Gross****
>
> +1-303-447-0517****
>
> In detail:****
> -    TF: Removed erroneous text about Telecom Profile – there is nothing
> in this MIB that is particular to that profile. ****
>
>  ****
>
> -    TF: not done, looks like this one slipped through.****
>
>  ****
>
> -    TF: OUI would be specific to the organization, not the profile. If
> the ITU (for instance) developed more than one profile, then they would
> -    TF: We’ve tried to be as consistent as we can. Of 17
> -    TF: Now uses an autonomous type instead of Integer32****
>
>  ****
>
> -    TF: Section changed since -03, no longer has this phrase.****
>
>  ****
>
> *Sent:* 16 May 2013 18:09****
>
>
> *To:* Karen ODonoghue
> *Cc:* [email-masked]