Re: [TICTOC] Alissa Cooper's No Objection on draft-ietf-tictoc-ptp-mib-08: (with COMMENT)

[Stephen Farrell <[e-mail]>]

Good catch wrt the EUI. I missed that.

S.

On 19/04/16 18:12, 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.
> 
> (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.
> 
>