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

Elwyn Davies <> Fri, 12 August 2016 23:14 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A1E9312D92F; Fri, 12 Aug 2016 16:14:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.619
X-Spam-Status: No, score=-2.619 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id xPsy--iH1xfd; Fri, 12 Aug 2016 16:14:06 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id B7D2B12D929; Fri, 12 Aug 2016 16:14:05 -0700 (PDT)
Received: from ([] helo=[]) by with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.77) (envelope-from <>) id 1bYLeM-0002m6-Lz; Sat, 13 Aug 2016 00:14:02 +0100
Date: Sat, 13 Aug 2016 00:14:01 +0100
Message-ID: <>
Importance: normal
From: Elwyn Davies <>
To: Ben Campbell <>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary=""
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: Fri, 12 Aug 2016 23:14:13 -0000

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).  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.  Allowing them to be used as normative references further embeds them into the system.
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.  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?    
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...
PSI note that it wouldn't be too late to undo the relaxation.. the draft referencing RFC 6707 is still with the RFC Editor ;-)

Sent from Samsung tablet.
-------- Original message --------From: Ben Campbell <> Date: 12/08/2016  19:58  (GMT+00:00) To: Elwyn Davies <> Cc: General area reviewing team <>, Subject: Re: Gen-art LC2/Telechat review of draft-ietf-insipid-session-id-24 
On 12 Aug 2016, at 10:40, Elwyn Davies wrote:

> I am the assigned Gen-ART reviewer for this draft. The General Area
> Review Team (Gen-ART) reviews all IETF documents being processed
> by the IESG for the IETF Chair. Please wait for direction from your
> document shepherd or AD before posting a new version of the draft.
> For more information, please see the FAQ at
> <>.
> Document: draft-ietf-insipid-session-id-26.txt
> Reviewer: Elwyn Davies
> Review Date: 2016/08/12
> IETF LC End Date: 2016/08/04
> IESG Telechat date: 2016/08/18
> Summary: (2nd Last Call and Telechat) Almost ready. The points from my 
> review of -24 in the first Last Call have all been addressed - thanks 
> - with the exception of the location of the key definitions of 
> "session id" and "communication session".  The latest version (-26) 
> refers the reader to RFC 7206 which needs to be a normative reference 
> but is an Informational RFC, creating a downref.    I cannot see that 
> a requirements document meets the criteria for an allowable downref as 
> described in Section 2 of RFC 3967. Reproducing the two definitions in 
> the new draft (and ensuring that they are accurate for the standards 
> document) seems to be a better solution IMO.

Hi Elwyn,

Thanks for all of your reviews on this so far. I agree with the original 
issue, but I disagree with what I understand to be your preferred 

I agree the definitions are needed to understand this draft. And if 
these were simple definitions, I would agree that this draft should 
simply copy them. But they are not, they are nuanced definitions with 
quite a bit of discussion text. Copying them into this draft would 
require the wholesale copying of 2 sections from RFC 7206, which contain 
about 20 paragraphs and one diagram. That's roughly 20% of the body of 
7206 (not counting front material or references.)

I disagree that this is not an allowable downref. The list in section 2 
of RFC 3967 is a list of examples, not an exhaustive list. We have lots 
of examples of approved RFCs with downrefs to informational RFCs because 
the referenced RFC defined terminology needed to understand the 
dependent document.



> Major issues:
> None
> Minor issues:
> Downref to RFC 7206 - see above.
> Editorial/Nits:
> Missing definitions of "session id" and "communication session" - see 
> above.