Please keep in mind that this MIB is based on IEEE Std 1588-2008, and as such, the description of data set members like clockIdentity was copied from that standard.
There is ongoing work in the revision of IEEE 1588 to update clockIdentity to align with current IEEE RA rules. Although this project could certainly attempt to make similar updates, that runs the risk of contradicting the future IEEE 1588 revision. I recommend to stay with IEEE Std 1588-2008 text. Rodney Cummings Co-chair of Architecture subcommittee, IEEE 1588 Working Group > -----Original Message----- > From: TICTOC [mailto:[email protected]] On Behalf Of Alissa Cooper > Sent: Tuesday, April 19, 2016 12:12 PM > To: The IESG <[email protected]> > Cc: [email protected]; [email protected]; draft-ietf-tictoc-ptp- > [email protected]; [email protected] > Subject: [TICTOC] Alissa Cooper's No Objection on draft-ietf-tictoc-ptp- > mib-08: (with COMMENT) > > Alissa Cooper has entered the following ballot position for > draft-ietf-tictoc-ptp-mib-08: No Objection > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-tictoc-ptp-mib/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > (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. > > > _______________________________________________ > TICTOC mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/tictoc _______________________________________________ TICTOC mailing list [email protected] https://www.ietf.org/mailman/listinfo/tictoc
