Whoops, this one apparently got skipped over amid some other deluge in my inbox; sorry.
On Sun, Aug 18, 2019 at 04:09:50PM -0400, Michael Richardson wrote: > > Benjamin Kaduk <[email protected]> wrote: > > That specific construction would seem like an "optional feature" per > > > https://www.ietf.org/blog/iesg-statement-normative-and-informative-references/ > > ... > > I re-read this, and this as to do with References, and so anything optional > referenced in section 7 would still need to be a Normative Reference. > > The stickler I see right now is [I-D.ietf-netconf-keystore]. > I don't want to hang on MISREF on that document; it's just one of many that > could be used, and I do not want to tell manufacturers that they have > to use this specific protocol to update trust anchors. > There are many other protocols that they presently support which they could > use, in particular, a CLI interface would be fine. > > I think that this 7.4.3 section that creates a factory default which isn't > the default from the factory should be worry people who care about remote > attestation of software. > > Adam has been particularly vocal about the need to specify something > normative that manufacturers have to provide in order to resale and operation > with the availability of the MASA. > > It seems that we might need another round of discussion on this topic. > I feel that we are being pushed to describe the entire security lifetime of > the device; that we need to solve the entire management problem of devices in > our document. (i.e. the 25 years of SNMPv3, plus YANG...) Maybe I just don't > understand what would be a reasonable answer, if what I've written is not > enough. > > Maybe a virtual interim discussion! If so, please let me know. I think I'm going to have to leave this one to Adam et al. > ANIMA/Iot-Onboarding has some time booked already: > > https://datatracker.ietf.org/meeting/interim-2019-anima-01/materials/agenda-interim-2019-anima-01-anima-01 > > ps: (s/IPv6 NAT44/IPv4 NAT44/ for section 7.4.2, btw) > > > >> section 9: > >> In recognition of this, some mechanisms are presented in > >> Section 7.2. The manufacturer MUST provide at least one of the one- > >> touch mechanisms described that permit enrollment to be proceed > >> without availability of any manufacturer server (such as the MASA). > > > ... but this is a somewhat different construction. In isolation, it > looks > > more like "MUST do at least one of X, Y, Z" without condition on "wish > to > > do W", and if X, Y, and Z are all in the same place, that place seems > > normative to me. (I will confess I've rather lost track of exactly why > > we're debating if this is normative or not; I guess it's just the > > disclaimer in Section 7 about "considered non-normative in the > generality > > of the protocol".) > > Yes, it's MUST do one of X,Y,Z. > So that implies: MAY do X, MAY do Y, MAY do Z, but not the case of all being > false. If "ignore all of Section 7.2" is not an option, then at least some part of it is normative. "You just get to choose which part" :) -Ben _______________________________________________ Anima mailing list [email protected] https://www.ietf.org/mailman/listinfo/anima
