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

"Ben Campbell" <> Wed, 17 August 2016 22:26 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id E3DA812D7A2; Wed, 17 Aug 2016 15:26:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.147
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id IS4_z1fSLMyl; Wed, 17 Aug 2016 15:26:04 -0700 (PDT)
Received: from ( [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id C7A3012D19F; Wed, 17 Aug 2016 15:26:04 -0700 (PDT)
Received: from [] ( []) (authenticated bits=0) by (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
X-Authentication-Warning: Host [] claimed to be []
From: Ben Campbell <>
To: Elwyn Davies <>
Date: Wed, 17 Aug 2016 17:26:01 -0500
Message-ID: <>
In-Reply-To: <>
References: <> <> <>
MIME-Version: 1.0
Content-Type: text/plain; format="flowed"
X-Mailer: MailMate (1.9.4r5234)
Archived-At: <>
Cc: General area reviewing team <>,
Subject: Re: [Gen-art] Gen-art LC2/Telechat review of draft-ietf-insipid-session-id-24
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "GEN-ART: General Area Review Team" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-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