Re: [Gen-art] Gen-art LC2/Telechat review of draft-ietf-insipid-session-id-24

["Gonzalo Salgueiro (gsalguei)" <[e-mail]>]

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 <[e-mail]> 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.