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

From: vinays <[email-masked]>
Date: Sun, 26 Jun 2016 09:54:22 -0400

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.

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.

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.

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.

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.

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; [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: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Tue, 28 Jun 2016 11:25:07 +0000

Hi Vinay, 

Thank you for the response and for addressing my comments. 

Please see in-line. 

Regards,

Dan

> Sent: Sunday, June 26, 2016 4:54 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; Vinay Shankarkumar
> ok. will move the content from the DESCRIPTION clause here. is that ok with
> you?

Yes - this move is one of the ways to solve issues #8 and #9. 

> 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). 

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

> not help either. It says 'For example, 2.5 ns is expressed as 0000 0000
> 0002 8000 in Base16.' and than the SYNTAX is

OK - but an example would be useful

> object for counter discontinuity - see section 4.6.1.2 in RFC 4181
> 

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

> ptpbaseWellKnownTransportTypes ... hope thats ok with you.

Same as at item #10 - some explanation would help

> > 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
> >
> >
> > Cc: Tim Frost; MIB Doctors (E-mail); Benoit Claise; draft-ietf-tictoc-ptp-
> [email-masked]; Laurent Montini; Greg Dowd; Karen O'Donoghue;
> Suresh Krishnan

---

From: vinays <[email-masked]>
Date: Tue, 28 Jun 2016 09:37:58 -0400

Hi Dan,

Thanks for the response, for some reason I cannot see your full email, 
could you please resend?..

Thanks,

-Vinay.

On 6/28/16 7:25 AM, Romascanu, Dan (Dan) wrote:
>> Please let us know, we can revise and send out a new version of the draft

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Tue, 28 Jun 2016 13:41:26 +0000

> Sent: Tuesday, June 28, 2016 4:38 PM
> To: Romascanu, Dan (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, 

Please see in-line. 

Regards,

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; Vinay Shankarkumar
> 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?
> 
> 

> 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.
> 
> ptpbaseWellKnownTransportTypes. So there is no need for IANA to 
> maintain it.. hope thats ok with you.
> 
> 

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

> [VC1] This is defined in the standard and we are just using it here. 
> The value expressed as base16 is populated as a string.
> 

> (see attached) - which refers to items #8, 9, 10, 11, 12, 15, 18 which 
> are still open. Did I miss any response?
> >
> > Regards,
> >
> > Dan
> >
> >

---

From: vinays <[email-masked]>
Date: Tue, 28 Jun 2016 11:21:34 -0400

Hi Dan,

thanks for the response. Please see inline at [VC2]

> Please let me know if this makes it through.
[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).

> OK - but an example would be useful

[VC2]  this was the example in the standards and I had copied it over here.

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

[VC2] ok, Thanks.

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

>>> draft-ietf-tictoc-ptp-

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Tue, 28 Jun 2016 15:42:35 +0000

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

> Sent: Tuesday, June 28, 2016 6:22 PM
> To: Romascanu, Dan (Dan)
> >> Dowd; Karen O'Donoghue; Suresh Krishnan
> >> Thanks for the response, for some reason I cannot see your full
> >> email, could you please resend?..
> >>
> >> Thanks,
> >>
> >> -Vinay.
> >>
> >
> > [email-masked]; Laurent Montini; Greg
> > Dowd; Karen O'Donoghue; Suresh Krishnan
> >> ok. will move the content from the DESCRIPTION clause here. is that
> >> 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).
> >
> >> 18.   How does ptpbaseClockPortAssociateAddressType work? What
> would
> >> be
> We will include you in the new revision of the draft, so that you can approve.
> Hope thats ok,
> 
> Thanks,
> -Vinay.
> 
> 
> >> Thanks,
> >>
> >> -Vinay,
> >>
> >>
> >>
> >>
> >> (see attached) - which refers to items #8, 9, 10, 11, 12, 15, 18
> >> which are still open. Did I miss any response?
> >>> Regards,
> >>>
> >>> Dan
> >>>
> >>>

---

From: vinays <[email-masked]>
Date: Wed, 29 Jun 2016 11:04:01 -0400

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.

---

From: Greg Dowd <[email-masked]>
Date: Wed, 29 Jun 2016 15:29:29 +0000

Did we have a nit before when there was a double comment in a line?  I'm looking at the -reserved(0), -- 0x00

From: vinays [mailto:[email-masked]]
Sent: Wednesday, June 29, 2016 8:04 AM
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

EXTERNAL EMAIL

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

                        clockclass6(6),     -- 0x06

                        clockclass7(7),     -- 0x07

                        -- reserved(8),     -- 0x08

 }

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,

Regards,

Dan

-----Original Message-----

To: Romascanu, Dan (Dan)

[email-masked]<mailto:[email-masked]>; Laurent Montini; Greg Dowd; Karen O'Donoghue;

Suresh Krishnan

Hi Dan,

-----Original Message-----

To: Romascanu, Dan (Dan)

draft-ietf-tictoc-ptp- [email-masked]<mailto:[email-masked]>; Laurent Montini; Greg

Hi Dan,

Thanks,

-Vinay.

Regards,

Dan

----------

-----Original Message-----

To: 'vinays'

[email-masked]<mailto:[email-masked]>; Laurent Montini; Greg

Hi Vinay,

Please see in-line.

Regards,

Dan

-----Original Message-----

To: Romascanu, Dan (Dan)

draft-ietf-tictoc-ptp- [email-masked]<mailto:[email-masked]>; Laurent Montini; Greg

Hi Dan,

Have your comment pasted

---

your comment:

[VC1]

ok with you?

your comment:

empty-content section 3?

your comment:

your comment:

draft to address this.

your comment:

not help either. It says 'For example, 2.5 ns is expressed as 0000

0000

your comment:

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

say this.

[VC2] ok, Thanks.

your comment:

would

be

included under the AutonomousType SYNTAX to make possible

interoperability?

[VC2]  ok, Thanks.

Hope thats ok,

Thanks,

-Vinay.

Thanks,

-Vinay,

Hi Vinay,

Sorry - I did not see any answer that addresses my comments from

5/12

Regards,

Dan

-----Original Message-----

To: Romascanu, Dan (Dan)

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: vinays <[email-masked]>
Date: Wed, 29 Jun 2016 11:33:01 -0400

Thanks Greg, will take care of that,

-Vinay.

On 6/29/16 11:29 AM, Greg Dowd wrote:
>
> Did we have a nit before when there was a double comment in a line?  
> I’m looking at the –reserved(0), -- 0x00
>
> *From:*vinays [mailto:[email-masked]]
> *Sent:* Wednesday, June 29, 2016 8:04 AM
> *To:* Romascanu, Dan (Dan)
> *Cc:* Tim Frost; MIB Doctors (E-mail); Benoit Claise; 
> *Subject:* Re: MIB Doctor Review for draft-ietf-tictoc-ptp-mib-08.txt
>
> EXTERNAL EMAIL
>
> Hello Dan, all,
>         [email-masked] <mailto:[email-masked]>; Laurent Montini; Greg Dowd; Karen O'Donoghue;
>
>         Suresh Krishnan
>
>                 [email-masked] <mailto:[email-masked]>; Laurent Montini; Greg
>
>             [email-masked]
>             <mailto:[email-masked]>; Laurent Montini; Greg
>
>                 [email-masked] <mailto:[email-masked]>; Laurent Montini; Greg
>
>                 [email-masked] <mailto:[email-masked]>; Laurent Montini; Greg Dowd; Karen O'Donoghue;
>
>                 Suresh Krishnan
>

---

From: vinays <[email-masked]>
Date: Thu, 30 Jun 2016 11:49:21 -0400

Hello Dan,

I have made all the changes, except for the fourth one:

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.

---

From: Suresh Krishnan <[email-masked]>
Date: Thu, 30 Jun 2016 16:20:31 +0000

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:
>> 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.
>>
>> ptpbaseWellKnownTransportTypes will be used in the values contained in the
>> OCTET STRING."
>>

---

From: vinays <[email-masked]>
Date: Thu, 30 Jun 2016 13:00:57 -0400

Hi Suresh,

ok, will see how we can address them and keep posted,

Thanks,

-Vinay.

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Thu, 30 Jun 2016 17:28:46 +0000

You can possibly use simple quotes, or the signs <  > instead of double quotes.

This is not a blocking comment, though.

Regards,

Dan

From: vinays [mailto:[email-masked]]
Sent: Thursday, June 30, 2016 6:49 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

Hello Dan,

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,

SYNTAX          INTEGER  {

                        -- reserved(0),     -- 0x00

                        clockclass6(6),     -- 0x06

                        clockclass7(7),     -- 0x07

                        -- reserved(8),     -- 0x08

 }

Thanks,
-Vinay.

Hi Vinay,

Regards,

Dan

-----Original Message-----

To: Romascanu, Dan (Dan)

Suresh Krishnan

Hi Dan,

-----Original Message-----

To: Romascanu, Dan (Dan)

Hi Dan,

Thanks,

-Vinay.

Regards,

Dan

----------

-----Original Message-----

To: 'vinays'

Hi Vinay,

Please see in-line.

Regards,

Dan

-----Original Message-----

To: Romascanu, Dan (Dan)

Hi Dan,

Have your comment pasted

---

your comment:

[VC1]

ok with you?

your comment:

empty-content section 3?

your comment:

your comment:

draft to address this.

your comment:

0000

your comment:

say this.

[VC2] ok, Thanks.

your comment:

would

be

interoperability?

[VC2]  ok, Thanks.

Hope thats ok,

Thanks,

-Vinay.

Thanks,

-Vinay,

Hi Vinay,

5/12

Regards,

Dan

-----Original Message-----

To: Romascanu, Dan (Dan)

draft-ietf-tictoc-ptp-

Suresh Krishnan

Hi Dan,

know,

Thanks,

-Vinay.

Hi Vinay,

intervened

---

From: vinays <[email-masked]>
Date: Thu, 30 Jun 2016 13:35:57 -0400

Thanks Dan, have taken care with simple quotes; attached the latest MIB 
text.

Regards,

-Vinay.

On 6/30/16 1:28 PM, Romascanu, Dan (Dan) wrote:
> *Sent:* Thursday, June 30, 2016 6:49 PM
> Since that description is already within quotes, I cannot put the 
> quotes around this particular sub-string.
> what is your suggestion?
>
>
>    DESCRIPTION^M
>     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.
>
>     ptpbaseWellKnownTransportTypes will be used in the values
>     contained in the OCTET STRING."
>

---

From: vinays <[email-masked]>
Date: Thu, 30 Jun 2016 13:54:29 -0400

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:
>>> 4.  For ClockTimeInterval, put quotes around the string for " 0000 
>>> 0000 0002
>>> 8000".
>>>
>>>
>>>> are going
>>>>> 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 .
>>>>>