Hi - I agree with Ben on all points. One inline point that bears reinforcement:
> I believe the working group intent was that the definitions stated in RFC > 7206 are the ones used in the protocol. This is exactly right. In fact, this was a very tedious and drawn out process where we had to solicit Robert Sparks to mediate and edit the specific text defining a ‘session’ in this context and in turn determining very precisely the scope of the work. Cheers, Gonzalo > On Aug 15, 2016, at 4:48 PM, Ben Campbell <b...@nostrum.com> wrote: > > Hi Elwyn: > > Responsible AD Hat on: > > I'm going to enter a DISCUSS position, to make sure this point gets > discussion among the IESG before this progresses. The whole point of the > repeated last call was to get feedback on the downref, and this certainly > counts :-) > > > All hats off: > > As an individual, I still disagree. Specifics inline: > > On 12 Aug 2016, at 18:14, Elwyn Davies wrote: > >> Hi, Ben. >> AFAICS there is only one really similar case (downref to RFC 6707) which was >> approved just last month (based on a problem statement). > > I'm pretty sure there are more than that; the idea that terminology > references may need to be normative has come up repeatedly during IESG > reviews over the past year or so. > >> My concern here is that the other framework and requirements documents are >> documents that continue to have a relevance (such as telling a network >> operator what is necessary to allow deployment of some IETF-defined >> technology) rather than being something that defines what a WG is intending >> to work on (RFC 6707 and RFC 7206 are respectively a problem statement and a >> protocol requirements statement). As we know, there has been some >> considerable discussion of whether we should really be publishing these >> documents as RFCs given that they are snapshots of a discussion position at >> a point in time and are only really of academic interest once the working >> group has done its work. > > I agree that we should cut down on publication of "requirements", "use case", > etc documents that do not have long term archival value. But I don't think > there should be as hard of a line as you describe. In particular, sometimes > they are valuable for nailing down especially hard-won consensus about > requirements. I think that is true for RFC 7206. > > But in any case, I think this is a red herring. RFC 7206 has been published. > This discussion isn't going to change that. > >> Allowing them to be used as normative references further embeds them into >> the system. > > I don't see why. Not every action creates a precedent. I do not propose that > we add RFC to the downref registry. > >> I would also caution that terminology and such like as defined in (protocol) >> requirements and problem statements are generally written and approved prior >> to the standards documents in which the are referenced. Further, I am not >> totally convinced that the same degree of rigour is applied to the review of >> this type of document. Thus it is vitally important to ensure that the >> definitions are still correct, complete and reflect what is needed for the >> standard(s): The protocols don't always exactly match the requirements - >> and there may have been some subtle bending of the meaning of terms over >> time! >> If the downref is to be accepted, then I (and other reviewers) need to go >> back and have a harder read of the definitions, unless they think they >> already did. > > I believe the working group intent was that the definitions stated in RFC > 7206 are the ones used in the protocol. > >> One consequential question: Is it time for either an update or some >> commentary on RFC 3967 as there seems to be a relaxation of the statements >> in Section 2? > > RFC 3967 section 2 makes no attempt to be exhaustive. It basically says > "there are some reasons to make exceptions. Here are some examples." > > (There actually is an ongoing discussion about relaxing bits of RFC 3967. See > draft-leiba-3967upd-downref-00, especially the third paragraph of section 1.) >> >> However >> My view is just that... if the authors, WG, you as AD and the IESG are happy >> with the downref and I am in a minority of one (or a very small number) of >> the IETF, then there is rough concensus and I'll be fine with the outcome. >> It is only a gen-art revew... > > It's a gen-art review on an IETF last call done _specifically_ for the > downref, so I think the outcome is relevant :-) > >> Cheers,Elwyn >> PSI note that it wouldn't be too late to undo the relaxation.. the draft >> referencing RFC 6707 is still with the RFC Editor ;-) >> /E > > [...] > > Thanks! > > Ben. _______________________________________________ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
