Skip to main content

Precision Time Protocol Version 2 (PTPv2) Management Information Base
draft-ietf-tictoc-ptp-mib-12

Yes

(Brian Haberman)
(Suresh Krishnan)

No Objection

(Alexey Melnikov)
(Alvaro Retana)
(Jari Arkko)
(Martin Stiemerling)
(Mirja Kühlewind)
(Spencer Dawkins)
(Terry Manderson)

Note: This ballot was opened for revision 08 and is now closed.

Brian Haberman Former IESG member
Yes
Yes (for -08) Unknown

                            
Suresh Krishnan Former IESG member
Yes
Yes (for -08) Unknown

                            
Alexey Melnikov Former IESG member
No Objection
No Objection (for -08) Unknown

                            
Alissa Cooper Former IESG member
No Objection
No Objection (2016-04-19 for -08) Unknown
(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.
Alvaro Retana Former IESG member
No Objection
No Objection (for -08) Unknown

                            
Ben Campbell Former IESG member
No Objection
No Objection (2016-03-14 for -08) Unknown
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.
Benoît Claise Former IESG member
(was Discuss) No Objection
No Objection (2016-08-30 for -11) Unknown
Thanks for resolution
Deborah Brungard Former IESG member
No Objection
No Objection (2016-04-19 for -08) Unknown
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.
Jari Arkko Former IESG member
(was Discuss) No Objection
No Objection () Unknown

                            
Joel Jaeggli Former IESG member
No Objection
No Objection (2016-03-13 for -08) Unknown
seems like the work from two years ago is there, so, baring an expert review it should be good to go.
Kathleen Moriarty Former IESG member
No Objection
No Objection (2016-04-18 for -08) Unknown
It looks like the SecDir review may not have gotten a response.  Here's the review:
https://www.ietf.org/mail-archive/web/secdir/current/msg06401.html

I'm fine with the mention of this being read only as it is in the introduction and also fine with the mention of SNMPv1 and v2 in the abstract as it provides context and background.
Martin Stiemerling Former IESG member
No Objection
No Objection (for -08) Unknown

                            
Mirja Kühlewind Former IESG member
No Objection
No Objection (for -08) Unknown

                            
Spencer Dawkins Former IESG member
No Objection
No Objection (for -08) Unknown

                            
Stephen Farrell Former IESG member
No Objection
No Objection (2016-04-19 for -08) Unknown
Sad to see chelliot ack'd for what'll likely be one of the
last times.
Terry Manderson Former IESG member
No Objection
No Objection (for -08) Unknown