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

On 17 Aug 2016, at 12:04, Elwyn Davies wrote:

> Hi, Ben.
>
> Having read Barry's proposed update for RFC 3967,  I would be happy 
> for that to become the status quo.  However, I would distinguish 
> between truly foundational documents that are produced in tandem with 
> the protocol standards or subsequently (as mentioned in Barry's draft) 
> and what one might call WG process documents such as requirements 
> documents and problem statements. I was going to use the word 
> 'ephemera' to describe these latter types, but that is doing them a 
> disservice:  Such documents, along with mailing list archives, can 
> provide insight into the thought processes that went into the 
> generation of the WG output for future reference.  Both the software 
> industry and the standards industry is incredibly bad at remembering 
> how decisions were reached - the concept of a 'design diary' never 
> seems to have taken hold - with the result that we spend an awful lot 
> of time reopening topics that were shown to be blind alleys and such 
> like especially after the original participants have moved on.
>
> That being said, I think that the 'design diary' category of documents 
> probably ought to be archived elsewhere than the RFC series; 
> additionally, it is unclear whether applying the RFC review processes 
> and resources to an essentially random subset of WG's design thoughts 
> is appropriate (that is a random set of WGs rather than a random set 
> of thoughts from any one WG - I hope :-) ).  As mentioned below, it is 
> not generally known in advance that parts of such documents might end 
> up being key references in later standards which can affect both the 
> way in which the documents are written (applicable in this case to 
> some extent) and the rigour of review  (the WG seems to have done a 
> good job in this case).
>
> Up until last month, I think that the foundational documents extension 
> would have covered the situation - RFC 6707 broke the mould, and I do 
> not consider that foundational covers it.

Without prejudice to your points (many of which I agree with), can I 
safely assume that the discussion above this point is more around 
Barry's draft, that we don't need to hold draft-ietf-insipid-session-id 
hostage to the completion of that discussion?

>
> Back to the current document:  I have reread s3 of RFC 7206 and there 
> are some points that need to be sorted out:
>
> - The term 'end-to-end' is given a slightly specialized meaning in RFC 
> 7206.  This is presumably carried through to the draft under review, 
> but the need to refer to the end-to-end definition is not mentioned in 
> the draft.
>
> - The use of 'session' as a shorthand for the specific meaning of 
> 'communication session' defined in RFC 7206 ought to be emphasized 
> within the draft since the shorthand in RFC 7206 is technically 
> limited to the RFC (ok, this is somewhat nitpicking but easy to 
> misinterpret.)

I agree with both of the above points. Authors?

>
> - The last para of s3.1 of RFC 7206 states:
>
>> This definition, along with the constraints imposed by the
>>     requirements in this document,....
> There is no explicit statement that this standard meets all the 
> requirements, so this is difficult to verify and might be 
> problematical in future.

I think that text, taken in context, is about the ability to use the 
session-id across protocols, not the definition of session-id in 
general. That is, even if the protocol fails to meet some of the 
requirements, the definition does not change.

>
> Overall, I am of the opinion that in this sort of situation, I'd do a 
> copy and paste exercise and tweak the text just a little to fit the 
> context more accurately.

Noted, and I hope to discuss that point with the rest of the IESG, 
either via mail or on the telechat. (I note, however, that there were 
multiple comments suggesting a different draft on tomorrow's telechat 
should not have copied definitions forward. Now, that was a requirements 
draft referencing terms from other requirements/architecture/problem 
statement drafts, so the situation may be a bit different.

>
> Cheers,
>
> Elwyn
>
> On 15/08/2016 21:48, Ben Campbell 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