Subject: Re: [MIB-DOCTORS] MIB Doctor Review for draft-ietf-tictoc-ptp-mib-08.txt

From: vinays <[email-masked]>
Date: Thu, 14 Jul 2016 10:25:35 -0400

Resending..

Hello Tim, Greg,
will you be able to handle these final RFC edits/submission?.. The final 
MIB is ready. These are the
4 pending text edits below.

The MIB itself was attached in the previous email.

Thanks,
-Vinay.

On 6/30/16 1:54 PM, vinays wrote:
>
>
> Have addressed Alissa's coments. Here is the latest MIB if needed.
>
> The pending comments are modifications in the RFC text. Greg, Tim, 
> would it be possible to pick this up from here?
>
>
> Pending :
>
> #1. Add the bulk of DESCRIPTION section into section 3 of the RFC text.
>
> #2. Alissa's comments:
>
> (1) The ClockIdentity is described as being generated based on an EUI-64 address as described in IEEE 1588-2008 Section 7.5.2.2.2. But in IEEE 1588-2008, there are two different ways the clock identifier can be generated, the other being a non-EUI-64 address defined in 7.5.2.2.3. Why is that option left out of the ClockIdentity description?
>
> In general I was dismayed to see the re-use of EUI-64 for clock identity for the security and privacy drawbacks, since it's not particularly clear that re-using those identifiers is necessary here. But if such a fix is warranted this MIB is not the place to do it in any event.
>
> (2) Looking athttps://trac.tools.ietf.org/area/ops/trac/wiki/mib-security  I recall that other MIB documents we've reviewed recently have listed out the specific tables/objects that may be considered vulnerable or sensitive, even if those objects are read-only. Why doesn't this document do that? I would think all of the clock identity objects would belong in that bucket at a minimum.
>
> Have added the description to include 'non-EUI-64' address in the MIB 
> itself.
>
>
> #3. Ben's comments:
>
> Is the lack of 2119 usage intentional? There is some text, especially in the security considerations, that reads as if  2119 keywords were intended, even though there is no 2119 reference and most of these are in lower case (although there is an instance of "NOT recommended" in the last paragraph of section 5.)
>
> I'm surprised at the single normative reference, especially that there are no normative references related to SNMP or SMI.
>
> #3. Deborah's comments:
>
> As Alissa commented, the ops wiki has recommended MIB-security section text. Specific tables/objects need to be listed for MAX-ACCESS which may be considered sensitive. Also I prefer the stronger wording (extra capitals) on use of SNMPv3. A MIB RFC in CCAMP, RFC 6825, has examples of both.
>
> Thanks,
> -Vinay.
>
>
>
>
>
> On 6/30/16 1:00 PM, vinays wrote:
>>
>> Hi Suresh,
>>
>> ok, will see how we can address them and keep posted,
>>
>> Thanks,
>>
>> -Vinay.
>>
>>
>> On 6/30/16 12:20 PM, Suresh Krishnan wrote:
>>> Hi Vinay,
>>>     While you are at it, can you also address the COMMENTs from 
>>> Deborah, Ben
>>> and Alissa.
>>>
>>> Thanks
>>> Suresh
>>>
>>> On 06/30/2016 11:49 AM, vinays wrote:
>>>> Hello Dan,
>>>>
>>>> I have made all the changes, except for the fourth one:
>>>>
>>>> 4.  For ClockTimeInterval, put quotes around the string for " 0000 
>>>> 0000 0002
>>>> 8000".
>>>>
>>>>
>>>> Since that description is already within quotes, I cannot put the 
>>>> quotes
>>>> around this particular sub-string.
>>>> what is your suggestion?
>>>>
>>>>
>>>>      DESCRIPTION^M
>>>>           "This textual convention corresponds to the TimeInterval^M
>>>>           structure indicated in section 5.3.2 of [IEEE 1588-2008].^M
>>>>           It will be presented in the form of a character array.^M
>>>>    ...
>>>>
>>>> ^M
>>>>           For example, 2.5 ns is expressed as 0000 0000 0002 8000 in^M
>>>>           Base16."^M
>>>>
>>>>
>>>> Am attaching the latest MIB for your reference. Please let me know,
>>>>
>>>> Thanks,
>>>> -Vinay.
>>>>
>>>> On 6/29/16 11:04 AM, vinays wrote:
>>>>>
>>>>> Hello Dan, all,
>>>>> These are the changes needed in the new draft, apart from how we 
>>>>> are going
>>>>> to address the IEEE - IETF copyright issue. Please let me know.
>>>>>
>>>>> 1. Move all the content of the DESCRIPTION clause from the MIB 
>>>>> into the
>>>>> section 3 of the RFC. Will
>>>>> leave a small portion in the MIB itself to be brief.
>>>>>
>>>>> 2. Mention in the ClockPortTransportTypeAddress and
>>>>> ptpbaseClockPortAssociateAddressType textual
>>>>> context as:
>>>>>      "The OCTET STRING representation of the OID of
>>>>> ptpbaseWellKnownTransportTypes will be used in the values 
>>>>> contained in the
>>>>> OCTET STRING."
>>>>>
>>>>> 3. Make  ClockQualityClassType  as an enumeration:
>>>>>
>>>>> SYNTAX          INTEGER  {
>>>>>                           -- reserved(0),     -- 0x00
>>>>>                           -- reserved(1:5),   0x01 to 0x05
>>>>>                           clockclass6(6),     -- 0x06
>>>>>                           clockclass7(7),     -- 0x07
>>>>>                           -- reserved(8),     -- 0x08
>>>>>                           -- reserved(9:10),  0x09 to 0x0A
>>>>>                           -- reserved(11:12), 0x0B, 0x0C
>>>>>                           clockclass13(13),   -- 0x0D
>>>>>                           clockclass14(14),   -- 0x0E
>>>>>                           -- reserved(15:51), 0x0F, 0x33
>>>>>                           clockclass52(52),   -- 0x34
>>>>>                           -- reserved(53:57), 0x35, 0x39
>>>>>                           clockclass58(58),   -- 0x3A
>>>>>                           -- reserved(59:67), 0x3B to 0x43
>>>>>                           -- OtherProfiles(68:122),  0x44 to 0x7A
>>>>>                           -- reserved(123:127),  0x7B to 0x4F
>>>>>                           -- reserved(128:132),  0x80 to 0x84
>>>>>
>>>>>    }
>>>>>
>>>>> 4.  For ClockTimeInterval, put quotes around the string for " 0000 
>>>>> 0000
>>>>> 0002 8000".
>>>>>
>>>>> 5.  Mention where ever counters are used as being 'discontinuous'. 
>>>>> This
>>>>> applies to :
>>>>>
>>>>> ptpbaseClockRunningPacketsSent
>>>>> ptpbaseClockRunningPacketsReceived
>>>>> ptpbaseClockTransDefaultDSNumOfPorts
>>>>> ptpbaseClockPortRunningPacketsReceived
>>>>> ptpbaseClockPortRunningPacketsSent
>>>>> ptpbaseClockPortAssociatePacketsSent
>>>>> ptpbaseClockPortAssociatePacketsReceived
>>>>> ptpbaseClockPortAssociateInErrors
>>>>> ptpbaseClockPortAssociateOutErrors
>>>>>
>>>>>
>>>>> Please let me know if there are any comments/feedback,
>>>>>
>>>>> Thanks,
>>>>> -Vinay.
>>>>>
>>>>> On 6/28/16 11:42 AM, Romascanu, Dan (Dan) wrote:
>>>>>> Hi Vinay,
>>>>>>
>>>>>> Thanks - I believe that we converged.
>>>>>>
>>>>>> I also understand the example now at item #12. You may want to 
>>>>>> put the string between quotes, so that it's clear that the object 
>>>>>> is the string representation of the value and not the value itself .
>>>>>>
>>>>>> Thank you for the patience and explanations. I also learned a few 
>>>>>> things.
>>>>>>
>>>>>> Regards,
>>>>>>
>>>>>> Dan
>>>>>>
>>>>>>
>>>>>>> -----Original Message-----
>>>>>>> From: vinays [mailto:[email-masked]]
>>>>>>> Sent: Tuesday, June 28, 2016 6:22 PM
>>>>>>> To: Romascanu, Dan (Dan)
>>>>>>> Cc: Tim Frost; MIB Doctors (E-mail); Benoit Claise; 
>>>>>>> draft-ietf-tictoc-ptp-
>>>>>>> [email-masked]; Laurent Montini; Greg Dowd; Karen 
>>>>>>> O'Donoghue;
>>>>>>> Suresh Krishnan
>>>>>>> Subject: Re: MIB Doctor Review for draft-ietf-tictoc-ptp-mib-08.txt
>>>>>>>
>>>>>>>
>>>>>>> Hi Dan,
>>>>>>>
>>>>>>> thanks for the response. Please see inline at [VC2]
>>>>>>>
>>>>>>>
>>>>>>> On 6/28/16 9:41 AM, Romascanu, Dan (Dan) wrote:
>>>>>>>>> -----Original Message-----
>>>>>>>>> From: vinays [mailto:[email-masked]]
>>>>>>>>> Sent: Tuesday, June 28, 2016 4:38 PM
>>>>>>>>> To: Romascanu, Dan (Dan)
>>>>>>>>> Cc: Tim Frost; MIB Doctors (E-mail); Benoit Claise;
>>>>>>>>> [email-masked]; Laurent Montini; 
>>>>>>>>> Greg
>>>>>>>>> Dowd; Karen O'Donoghue; Suresh Krishnan
>>>>>>>>> Subject: Re: MIB Doctor Review for 
>>>>>>>>> draft-ietf-tictoc-ptp-mib-08.txt
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Hi Dan,
>>>>>>>>>
>>>>>>>>> Thanks for the response, for some reason I cannot see your full
>>>>>>>>> email, could you please resend?..
>>>>>>>>>
>>>>>>>>> Thanks,
>>>>>>>>>
>>>>>>>>> -Vinay.
>>>>>>>>>
>>>>>>>> Here is the full content of the message.
>>>>>>>>
>>>>>>>> Please let me know if this makes it through.
>>>>>>>>
>>>>>>>> Regards,
>>>>>>>>
>>>>>>>> Dan
>>>>>>>>
>>>>>>>>
>>>>>>>> ----------
>>>>>>>>
>>>>>>>>
>>>>>>>> -----Original Message-----
>>>>>>>> From: Romascanu, Dan (Dan)
>>>>>>>> Sent: Tuesday, June 28, 2016 2:25 PM
>>>>>>>> To: 'vinays'
>>>>>>>> Cc: Tim Frost; MIB Doctors (E-mail); Benoit Claise;
>>>>>>>> [email-masked]; Laurent Montini; 
>>>>>>>> Greg
>>>>>>>> Dowd; Karen O'Donoghue; Suresh Krishnan
>>>>>>>> Subject: RE: MIB Doctor Review for 
>>>>>>>> draft-ietf-tictoc-ptp-mib-08.txt
>>>>>>>>
>>>>>>>> Hi Vinay,
>>>>>>>>
>>>>>>>> Thank you for the response and for addressing my comments.
>>>>>>>>
>>>>>>>> Please see in-line.
>>>>>>>>
>>>>>>>> Regards,
>>>>>>>>
>>>>>>>> Dan
>>>>>>>>
>>>>>>>>
>>>>>>>>> -----Original Message-----
>>>>>>>>> From: vinays [mailto:[email-masked]]
>>>>>>>>> Sent: Sunday, June 26, 2016 4:54 PM
>>>>>>>>> To: Romascanu, Dan (Dan)
>>>>>>>>> Cc: Tim Frost; MIB Doctors (E-mail); Benoit Claise;
>>>>>>>>> [email-masked]; Laurent Montini; 
>>>>>>>>> Greg
>>>>>>>>> Dowd; Karen O'Donoghue; Suresh Krishnan; Vinay Shankarkumar
>>>>>>>>> Subject: Re: MIB Doctor Review for 
>>>>>>>>> draft-ietf-tictoc-ptp-mib-08.txt
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Hi Dan,
>>>>>>>>>
>>>>>>>>> apologies for the delayed response. sending here.
>>>>>>>>>
>>>>>>>>> The comments of # 8, # 9,  # 10, # 11, # 12,  # 15 and # 18 
>>>>>>>>> were open.
>>>>>>>>> Have your comment pasted
>>>>>>>>>
>>>>>>>>> here below and then my response under the tag [VC1].
>>>>>>>>>
>>>>>>>>> Please let us know, we can revise and send out a new version 
>>>>>>>>> of the draft.
>>>>>>>>>
>>>>>>>>> ---
>>>>>>>>>
>>>>>>>>> your comment:
>>>>>>>>> 8.       I do not believe that Section 3 includes any useful 
>>>>>>>>> information.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> [VC1]
>>>>>>>>>
>>>>>>>>> ok. will move the content from the DESCRIPTION clause here. is 
>>>>>>>>> that
>>>>>>>>> ok with you?
>>>>>>>>> will need a revision for the draft to address this.
>>>>>>>>>
>>>>>>>>> your comment:
>>>>>>>>>
>>>>>>>>> 9.       The DESCRIPTION clause is unusually long and includes 
>>>>>>>>> a lot of
>>>>>>>>> abbreviations, terminology, architectural details and other 
>>>>>>>>> pieces of
>>>>>>>>> information which is not clear why they need to be hardcoded 
>>>>>>>>> in the
>>>>>>>>> MIB module. Maybe the place for all these is in the currently
>>>>>>>>> empty-content section 3?
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> [VC1] ok. will move. will need a revision for the draft to 
>>>>>>>>> address this.
>>>>>>>>>
>>>>>>>>>
>>>>>>>> Yes - this move is one of the ways to solve issues #8 and #9.
>>>>>>>>
>>>>>>>>> your comment:
>>>>>>>>>
>>>>>>>>> 10.   I do not understand how the 
>>>>>>>>> ClockPortTransportTypeAddress TC
>>>>>>>>> works. If this TC defines an address type why is it not an 
>>>>>>>>> enumeration?
>>>>>>>>> What is the string that for example indicates IPv6? Is it 
>>>>>>>>> 'IPv6'? who
>>>>>>>>> guarantees that a manager and an agent spell the same? Or is the
>>>>>>>>> intention to use the list of identifiers for 'Well Known 
>>>>>>>>> transport
>>>>>>>>> types for PTP communication'at page 64? If yes, how is this 
>>>>>>>>> extended?
>>>>>>>>> Probably an IANA maintained enumerated TC would be a better 
>>>>>>>>> solution.
>>>>>>>>>
>>>>>>>>> [VC1] The enumerations are defined here as
>>>>>>>>> ptpbaseWellKnownTransportTypes. So there is no need for IANA to
>>>>>>>>> maintain it.. hope thats ok with you.
>>>>>>>>>
>>>>>>>>>
>>>>>>>> Do you mean that the OCTET STRING value carried here is the OCTET
>>>>>>> STRING representation of the OID of one of the nodes under
>>>>>>> ptpbaseWellKnownTransportTypes? If this is the case you should 
>>>>>>> say this
>>>>>>> explicitly in the DESCRIPTION clause. Note that you will still 
>>>>>>> need to revise
>>>>>>> this RFC to add new transports in the future, but maybe this 
>>>>>>> never will
>>>>>>> happen (or happens very seldom).
>>>>>>> [VC2] ok, we will explicitly state that.
>>>>>>> And that is correct, a new revision or addendum would be needed 
>>>>>>> if new
>>>>>>> transports are added (which may never happen or very seldom).
>>>>>>>
>>>>>>>>> your comment:
>>>>>>>>>
>>>>>>>>> 11.   Why is not the SYNTAX of ClockQualityClassType an 
>>>>>>>>> enumeration,
>>>>>>>>> when the DESCRIPTION indicates clearly that this is an 
>>>>>>>>> enumeration.
>>>>>>>>>
>>>>>>>>> [VC1] ok will make it an enumeration. will need a revision for 
>>>>>>>>> the
>>>>>>>>> draft to address this.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> your comment:
>>>>>>>>>
>>>>>>>>> 12.   I do not understand how ClockTimeInterval works. The 
>>>>>>>>> example does
>>>>>>>>> not help either. It says 'For example, 2.5 ns is expressed as 
>>>>>>>>> 0000
>>>>>>>>> 0000
>>>>>>>>> 0002 8000 in Base16.' and than the SYNTAX is
>>>>>>>>> SYNTAX          OCTET STRING (SIZE (1..255))
>>>>>>>>> What is the STRING for the object in this example?
>>>>>>>>>
>>>>>>>>> [VC1] This is defined in the standard and we are just using it 
>>>>>>>>> here.
>>>>>>>>> The value expressed as base16 is populated as a string.
>>>>>>>>>
>>>>>>>> OK - but an example would be useful
>>>>>>> [VC2]  this was the example in the standards and I had copied it 
>>>>>>> over here.
>>>>>>>
>>>>>>>>> your comment:
>>>>>>>>>
>>>>>>>>> 15.   There is no indication of behavior for counter 
>>>>>>>>> discontinuity, or
>>>>>>>>> object for counter discontinuity - see section 4.6.1.2 in RFC 
>>>>>>>>> 4181
>>>>>>>>>
>>>>>>>>> [VC1] we will add a clause that the counters can be 
>>>>>>>>> discontinuous. is
>>>>>>>>> the ok? will need a revision for the draft to address this.
>>>>>>>>>
>>>>>>>>>
>>>>>>>> OK - but please follow the recommendations in RFC 4181 about 
>>>>>>>> how you
>>>>>>> say this.
>>>>>>>
>>>>>>> [VC2] ok, Thanks.
>>>>>>>
>>>>>>>>> your comment:
>>>>>>>>>
>>>>>>>>> 18.   How does ptpbaseClockPortAssociateAddressType work? What
>>>>>>> would
>>>>>>>>> be
>>>>>>>>> included under the AutonomousType SYNTAX to make possible
>>>>>>>>> interoperability?
>>>>>>>>>
>>>>>>>>> [VC1] The enumerations are defined here as
>>>>>>>>> ptpbaseWellKnownTransportTypes ... hope thats ok with you.
>>>>>>>>>
>>>>>>>>>
>>>>>>>> Same as at item #10 - some explanation would help
>>>>>>> [VC2]  ok, Thanks.
>>>>>>>
>>>>>>> We will include you in the new revision of the draft, so that 
>>>>>>> you can approve.
>>>>>>> Hope thats ok,
>>>>>>>
>>>>>>> Thanks,
>>>>>>> -Vinay.
>>>>>>>
>>>>>>>
>>>>>>>>> Thanks,
>>>>>>>>>
>>>>>>>>> -Vinay,
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On 5/18/16 4:20 AM, Romascanu, Dan (Dan) wrote:
>>>>>>>>>> Hi Vinay,
>>>>>>>>>>
>>>>>>>>>> Sorry - I did not see any answer that addresses my comments from
>>>>>>>>>> 5/12
>>>>>>>>> (see attached) - which refers to items #8, 9, 10, 11, 12, 15, 18
>>>>>>>>> which are still open. Did I miss any response?
>>>>>>>>>> Regards,
>>>>>>>>>>
>>>>>>>>>> Dan
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> -----Original Message-----
>>>>>>>>>> From: vinays [mailto:[email-masked]]
>>>>>>>>>> Sent: Tuesday, May 17, 2016 8:11 PM
>>>>>>>>>> To: Romascanu, Dan (Dan)
>>>>>>>>>> Cc: Tim Frost; MIB Doctors (E-mail); Benoit Claise;
>>>>>>>>>> draft-ietf-tictoc-ptp-
>>>>>>>>> [email-masked]; Laurent Montini; Greg Dowd; Karen 
>>>>>>>>> O'Donoghue;
>>>>>>>>> Suresh Krishnan
>>>>>>>>>> Subject: Re: MIB Doctor Review for 
>>>>>>>>>> draft-ietf-tictoc-ptp-mib-08.txt
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Hi Dan,
>>>>>>>>>> are you ok with how the comments have been addressed? Please 
>>>>>>>>>> let us
>>>>>>>>> know,
>>>>>>>>>> Thanks,
>>>>>>>>>> -Vinay.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On 5/12/16 5:12 AM, Romascanu, Dan (Dan) wrote:
>>>>>>>>>>> Hi Vinay,
>>>>>>>>>>>
>>>>>>>>>>> I apologize for the delay. Vacation and post-vacation 
>>>>>>>>>>> congestion
>>>>>>>>> intervened
>>
>

---

From: Tim Frost <[email-masked]>
Date: Mon, 18 Jul 2016 07:42:55 +0000

Hi Vinay,
Sorry for the delay, I have been travelling most of the last month, and then on vacation.

Yes I can pick it up from here and get it submitted. Where are we with the copyright saga? I think that is probably the last gotcha.

Also I think we’re probably in lockout now until after the meeting this week?  I’m assuming I probably can’t submit until next Monday now.

Best regards,
Tim

Tim Frost   |   Calnex Solutions Ltd.   |   +44 (0) 7825 706 952   |   www.calnexsol.com<http://www.calnexsol.com/>

From: vinays [mailto:[email-masked]]
Sent: 14 July 2016 15:26
To: Suresh Krishnan <[email-masked]>; Romascanu, Dan (Dan) <[email-masked]>; Tim Frost <[email-masked]>; Greg Dowd <[email-masked]>
Cc: MIB Doctors (E-mail) <[email-masked]>; Benoit Claise <[email-masked]>; [email-masked]; Laurent Montini <[email-masked]>; Karen O'Donoghue <[email-masked]>; Vinay Shankarkumar <[email-masked]>
Subject: Re: MIB Doctor Review for draft-ietf-tictoc-ptp-mib-08.txt

Resending..
Hello Tim, Greg,
will you be able to handle these final RFC edits/submission?.. The final MIB is ready. These are the
4 pending text edits below.

Thanks,
-Vinay.

The pending comments are modifications in the RFC text. Greg, Tim, would it be possible to pick this up from here?

Pending :

#2. Alissa's comments:

(2) Looking at https://trac.tools.ietf.org/area/ops/trac/wiki/mib-security I recall that other MIB documents we've reviewed recently have listed out the specific tables/objects that may be considered vulnerable or sensitive, even if those objects are read-only. Why doesn't this document do that? I would think all of the clock identity objects would belong in that bucket at a minimum.

Have added the description to include 'non-EUI-64' address in the MIB itself.

#3. Ben's comments:

#3. Deborah's comments:

Thanks,
-Vinay.

Hi Suresh,

Thanks,

-Vinay.

Hi Vinay,
    While you are at it, can you also address the COMMENTs from Deborah, Ben
and Alissa.

Thanks
Suresh

Hello Dan,

4.  For ClockTimeInterval, put quotes around the string for " 0000 0000 0002
8000".

Since that description is already within quotes, I cannot put the quotes
around this particular sub-string.
what is your suggestion?

     DESCRIPTION^M

^M

Thanks,
-Vinay.

Hello Dan, all,
These are the changes needed in the new draft, apart from how we are going
to address the IEEE - IETF copyright issue. Please let me know.

1. Move all the content of the DESCRIPTION clause from the MIB into the
section 3 of the RFC. Will
leave a small portion in the MIB itself to be brief.

2. Mention in the ClockPortTransportTypeAddress and
ptpbaseClockPortAssociateAddressType textual
context as:
     "The OCTET STRING representation of the OID of
ptpbaseWellKnownTransportTypes will be used in the values contained in the
OCTET STRING."

SYNTAX          INTEGER  {
                          -- reserved(0),     -- 0x00

   }

4.  For ClockTimeInterval, put quotes around the string for " 0000 0000
0002 8000".

5.  Mention where ever counters are used as being 'discontinuous'. This
applies to :

Thanks,
-Vinay.

Hi Vinay,

I also understand the example now at item #12. You may want to put the string between quotes, so that it's clear that the object is the string representation of the value and not the value itself .

Thank you for the patience and explanations. I also learned a few things.

Regards,

Dan

-----Original Message-----
From: vinays [mailto:[email-masked]]
Sent: Tuesday, June 28, 2016 6:22 PM
To: Romascanu, Dan (Dan)
Cc: Tim Frost; MIB Doctors (E-mail); Benoit Claise; draft-ietf-tictoc-ptp-
[email-masked]<mailto:[email-masked]>; Laurent Montini; Greg Dowd; Karen O'Donoghue;
Suresh Krishnan
Subject: Re: MIB Doctor Review for draft-ietf-tictoc-ptp-mib-08.txt

Hi Dan,

-----Original Message-----
From: vinays [mailto:[email-masked]]
Sent: Tuesday, June 28, 2016 4:38 PM
To: Romascanu, Dan (Dan)
Cc: Tim Frost; MIB Doctors (E-mail); Benoit Claise;
[email-masked]<mailto:[email-masked]>; Laurent Montini; Greg
Dowd; Karen O'Donoghue; Suresh Krishnan
Subject: Re: MIB Doctor Review for draft-ietf-tictoc-ptp-mib-08.txt

Hi Dan,

Thanks,

-Vinay.

Regards,

Dan

----------

-----Original Message-----
From: Romascanu, Dan (Dan)
Sent: Tuesday, June 28, 2016 2:25 PM
To: 'vinays'
Cc: Tim Frost; MIB Doctors (E-mail); Benoit Claise;
[email-masked]<mailto:[email-masked]>; Laurent Montini; Greg
Dowd; Karen O'Donoghue; Suresh Krishnan
Subject: RE: MIB Doctor Review for draft-ietf-tictoc-ptp-mib-08.txt

Hi Vinay,

Please see in-line.

Regards,

Dan

-----Original Message-----
From: vinays [mailto:[email-masked]]
Sent: Sunday, June 26, 2016 4:54 PM
To: Romascanu, Dan (Dan)
Cc: Tim Frost; MIB Doctors (E-mail); Benoit Claise;
[email-masked]<mailto:[email-masked]>; Laurent Montini; Greg
Dowd; Karen O'Donoghue; Suresh Krishnan; Vinay Shankarkumar
Subject: Re: MIB Doctor Review for draft-ietf-tictoc-ptp-mib-08.txt

Hi Dan,

The comments of # 8, # 9,  # 10, # 11, # 12,  # 15 and # 18 were open.
Have your comment pasted

Please let us know, we can revise and send out a new version of the draft.

---

your comment:
8.       I do not believe that Section 3 includes any useful information.

[VC1]

ok. will move the content from the DESCRIPTION clause here. is that
ok with you?
will need a revision for the draft to address this.

your comment:

9.       The DESCRIPTION clause is unusually long and includes a lot of
abbreviations, terminology, architectural details and other pieces of
information which is not clear why they need to be hardcoded in the
MIB module. Maybe the place for all these is in the currently
empty-content section 3?

[VC1] ok. will move. will need a revision for the draft to address this.

your comment:

10.   I do not understand how the ClockPortTransportTypeAddress TC
works. If this TC defines an address type why is it not an enumeration?
What is the string that for example indicates IPv6? Is it 'IPv6'? who
guarantees that a manager and an agent spell the same? Or is the
intention to use the list of identifiers for 'Well Known transport
types for PTP communication'at page 64? If yes, how is this extended?
Probably an IANA maintained enumerated TC would be a better solution.

Do you mean that the OCTET STRING value carried here is the OCTET
STRING representation of the OID of one of the nodes under
ptpbaseWellKnownTransportTypes? If this is the case you should say this
explicitly in the DESCRIPTION clause. Note that you will still need to revise
this RFC to add new transports in the future, but maybe this never will
happen (or happens very seldom).
[VC2] ok, we will explicitly state that.
And that is correct, a new revision or addendum would be needed if new
transports are added (which may never happen or very seldom).

your comment:

11.   Why is not the SYNTAX of ClockQualityClassType an enumeration,
when the DESCRIPTION indicates clearly that this is an enumeration.

[VC1] ok will make it an enumeration. will need a revision for the
draft to address this.

your comment:

12.   I do not understand how ClockTimeInterval works. The example does
not help either. It says 'For example, 2.5 ns is expressed as 0000
0000
0002 8000 in Base16.' and than the SYNTAX is
SYNTAX          OCTET STRING (SIZE (1..255))
What is the STRING for the object in this example?

[VC1] This is defined in the standard and we are just using it here.
The value expressed as base16 is populated as a string.
OK - but an example would be useful
[VC2]  this was the example in the standards and I had copied it over here.

your comment:

15.   There is no indication of behavior for counter discontinuity, or
object for counter discontinuity - see section 4.6.1.2 in RFC 4181

[VC1] we will add a clause that the counters can be discontinuous. is
the ok? will need a revision for the draft to address this.

OK - but please follow the recommendations in RFC 4181 about how you
say this.

[VC2] ok, Thanks.

your comment:

be

We will include you in the new revision of the draft, so that you can approve.
Hope thats ok,

Thanks,
-Vinay.

Thanks,

-Vinay,

Hi Vinay,

Regards,

Dan

-----Original Message-----
From: vinays [mailto:[email-masked]]
Sent: Tuesday, May 17, 2016 8:11 PM
To: Romascanu, Dan (Dan)
Cc: Tim Frost; MIB Doctors (E-mail); Benoit Claise;
draft-ietf-tictoc-ptp-
[email-masked]<mailto:[email-masked]>; Laurent Montini; Greg Dowd; Karen O'Donoghue;
Suresh Krishnan

Hi Dan,
are you ok with how the comments have been addressed? Please let us
know,

Thanks,
-Vinay.

Hi Vinay,

I apologize for the delay. Vacation and post-vacation congestion
intervened

---

From: Suresh Krishnan <[email-masked]>
Date: Mon, 18 Jul 2016 07:47:39 +0000

Hi Tim,

On 07/18/2016 03:43 AM, Tim Frost wrote:
> Yes I can pick it up from here and get it submitted. Where are we with the
> copyright saga? I think that is probably the last gotcha.

Don't worry about this for the moment. I will be talking to the IEEE-IETF 
co-ordination team tomorrow AM and if we get an adverse response I will get 
back to you right away.

>
> Also I think we’re probably in lockout now until after the meeting this
> week?  I’m assuming I probably can’t submit until next Monday now.

You can submit right away. The lockout was last week.

Thanks
Suresh

---

From: Tim Frost <[email-masked]>
Date: Mon, 18 Jul 2016 08:06:51 +0000

OK, thanks Suresh.
Tim

Tim Frost   |   Calnex Solutions Ltd.   |   +44 (0) 7825 706 952   |   www.calnexsol.com

-----Original Message-----
From: Suresh Krishnan [mailto:[email-masked]] 
Sent: 18 July 2016 08:48
To: Tim Frost <[email-masked]>; vinays <[email-masked]>; Romascanu, Dan (Dan) <[email-masked]>; Greg Dowd <[email-masked]>
Cc: MIB Doctors (E-mail) <[email-masked]>; Benoit Claise <[email-masked]>; [email-masked]; Laurent Montini <[email-masked]>; Karen O'Donoghue <[email-masked]>
Subject: Re: MIB Doctor Review for draft-ietf-tictoc-ptp-mib-08.txt

Hi Tim,

On 07/18/2016 03:43 AM, Tim Frost wrote:
> Yes I can pick it up from here and get it submitted. Where are we with 
> the copyright saga? I think that is probably the last gotcha.

Don't worry about this for the moment. I will be talking to the IEEE-IETF co-ordination team tomorrow AM and if we get an adverse response I will get back to you right away.

>
> Also I think we're probably in lockout now until after the meeting this
> week?  I'm assuming I probably can't submit until next Monday now.

Thanks
Suresh