> On Apr 19, 2016, at 1:23 PM, joel jaeggli <[email protected]> wrote: > > On 4/19/16 10:12 AM, Alissa Cooper wrote: >> 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. > > I don't see a whole lot wrong with using a mac address as an identifier > in a management system. 1588 speakers are frequently adjecent to each > other and almost always within the same management domain,
Are you saying you don’t see a problem with not reflecting the mechanisms from 7.5.2.2.3 here? Or just generally that you don’t see a problem with using a MAC address as an identifier in this case? Alissa > >> (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
