I looked through the mailing list archives and the meeting minutes from the meetings around the time when the registration policy was added to the document (the -01). I did not see any discussion of the registration policy.
I fully agree with Haibin’s analysis, though, which is that the potential for introducing sensitive diagnostic types (e.g., location) is sufficient to make Standards Action or IETF Review a good choice. These should get IETF-wide security review before being added to the registries. Alissa > On Jan 28, 2016, at 1:47 PM, Barry Leiba <[email protected]> wrote: > >> Does Haibin’s answer clear up your concern? > > Sorry, it must have gotten lost in the end-of-year mess. > > No, it doesn't: Haibin gives his thoughts on the question, but I asked > about what discussion the working group had in coming to the decision. > Further comment: > >>> For Sections 9.1 and 9.2, I would like to see some evidence of discussion >>> that >>> resulted in the decision to make the registry policies Standards Action. >>> Did >>> the working group actually discuss this and make a decision that Standards >>> Action is right? What's the reasoning for not using some softer policy, >>> such as >>> "IETF Review" (which might allow for registrations from Experimental >>> documents) or Specification Required (which would allow review by a >>> designated expert of a non-RFC specification)? Why is Standards Action the >>> right thing? >>> >> The thought was that if a new value would be used for experimental >> purpose, then there are reserved values accordingly for overlay local >> use (0xF000-0xFFFE). And then if people want that value can be used >> across different RELOAD overlays, then they'd better need a standard >> track document to define it (that's why we assume it would be standard >> track). "Specification Required" allows non-RFC specifications, not >> sure that would reflect the IETF consensus (certain concerns might >> exist about certain kinds of diagnostic information). > > Yes, "Specification Required" allows non-RFC specifications, with a > designated expert to review the request and sanity-check it. Why does > the working group think this registry needs only Standards Track RFCs > to make registrations? Why can't IETF consensus approve a > non-Standards-Track RFC (as with "IETF Review")? Why couldn't a > designated expert handle the review, consulting with whatever > appropriate working group(s) exist at the time (as with "Specification > Required")? > > I'm honest OK with Standards Action if that's really what the working > group wants, and they have a reasonable explanation for why that's > necessary here. I'm asking because I can't see any evidence that it > was actually discussed, and I'm concerned that we consistently use > too-strict registration policies because we think they're necessary, > and that often bites us later on, when we wish we hadn't been so > strict. > > Can you point me at any messages or minutes that show the working > group discussion about the registration policy? Can the working group > explain what harm could be caused if registrations were allowed to be > made without Standards Track RFCs? > > Barry _______________________________________________ P2PSIP mailing list [email protected] https://www.ietf.org/mailman/listinfo/p2psip
