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

[Tim Frost <[e-mail]>]

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.   |   [phone]   |   www.calnexsol.com<http://www.calnexsol.com/>

From: vinays [mailto:[e-mail]]
Sent: 14 July 2016 15:26
To: Suresh Krishnan <[e-mail]>om>; Romascanu, Dan (Dan) <[e-mail]>om>; Tim Frost <[e-mail]>om>; Greg Dowd <[e-mail]>
Cc: MIB Doctors (E-mail) <[e-mail]>rg>; Benoit Claise <[e-mail]>om>; [e-mail]; Laurent Montini <[e-mail]>om>; Karen O'Donoghue <[e-mail]>rg>; Vinay Shankarkumar <[e-mail]>
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.

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 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:

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:[e-mail]]
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-
[e-mail]<mailto:[e-mail]>; 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:[e-mail]]
Sent: Tuesday, June 28, 2016 4:38 PM
To: Romascanu, Dan (Dan)
Cc: Tim Frost; MIB Doctors (E-mail); Benoit Claise;
[e-mail]<mailto:[e-mail]>; 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;
[e-mail]<mailto:[e-mail]>; 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:[e-mail]]
Sent: Sunday, June 26, 2016 4:54 PM
To: Romascanu, Dan (Dan)
Cc: Tim Frost; MIB Doctors (E-mail); Benoit Claise;
[e-mail]<mailto:[e-mail]>; 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:[e-mail]]
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-
[e-mail]<mailto:[e-mail]>; 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