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

"Ben Campbell" <ben@nostrum.com> Wed, 17 August 2016 22:26 UTC

Return-Path: <ben@nostrum.com>
X-Original-To: gen-art@ietfa.amsl.com
Delivered-To: gen-art@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E3DA812D7A2; Wed, 17 Aug 2016 15:26:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.147
X-Spam-Level:
X-Spam-Status: No, score=-3.147 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.247] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IS4_z1fSLMyl; Wed, 17 Aug 2016 15:26:04 -0700 (PDT)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C7A3012D19F; Wed, 17 Aug 2016 15:26:04 -0700 (PDT)
Received: from [10.0.1.4] (cpe-66-25-7-22.tx.res.rr.com [66.25.7.22]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id u7HMQ1tl083073 (version=TLSv1 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Wed, 17 Aug 2016 17:26:02 -0500 (CDT) (envelope-from ben@nostrum.com)
X-Authentication-Warning: raven.nostrum.com: Host cpe-66-25-7-22.tx.res.rr.com [66.25.7.22] claimed to be [10.0.1.4]
From: "Ben Campbell" <ben@nostrum.com>
To: "Elwyn Davies" <elwynd@folly.org.uk>
Date: Wed, 17 Aug 2016 17:26:01 -0500
Message-ID: <B9A67A12-B74D-47E6-B67A-6AEFE7BB1D74@nostrum.com>
In-Reply-To: <c2c91da2-41c9-0244-4214-cee853ef66d5@folly.org.uk>
References: <pe04eo7uwhsm1a1pyh3i0c7e.1471038202004@email.android.com> <B745A028-9B9B-4FA0-BA7B-8027A8BD349B@nostrum.com> <c2c91da2-41c9-0244-4214-cee853ef66d5@folly.org.uk>
MIME-Version: 1.0
Content-Type: text/plain; format=flowed
X-Mailer: MailMate (1.9.4r5234)
Archived-At: <https://mailarchive.ietf.org/arch/msg/gen-art/nYIuAYkueQQg5R8YXKre8j8XEXU>
Cc: General area reviewing team <gen-art@ietf.org>, draft-ietf-insipid-session-id.all@ietf.org
Subject: Re: [Gen-art] Gen-art LC2/Telechat review of draft-ietf-insipid-session-id-24
X-BeenThere: gen-art@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "GEN-ART: General Area Review Team" <gen-art.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/gen-art>, <mailto:gen-art-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/gen-art/>
List-Post: <mailto:gen-art@ietf.org>
List-Help: <mailto:gen-art-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/gen-art>, <mailto:gen-art-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 17 Aug 2016 22:26:07 -0000

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