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

From: Elwyn Davies <[email-masked]>
Date: Sat, 13 Aug 2016 00:14:01 +0100

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?    
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...
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

Sent from Samsung tablet.
-------- Original message --------From: Ben Campbell <[email-masked]> Date: 12/08/2016  19:58  (GMT+00:00) To: Elwyn Davies <[email-masked]> Cc: General area reviewing team <[email-masked]>, [email-masked] 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
>
> <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.
>
> 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 
solution.

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.

Thanks!

Ben.

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

---

From: "Ben Campbell" <[email-masked]>
Date: Mon, 15 Aug 2016 15:48:15 -0500

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.

---

From: "Gonzalo Salgueiro (gsalguei)" <[email-masked]>
Date: Mon, 15 Aug 2016 21:58:30 +0000

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 <[email-masked]> 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:
> 
>> 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.
> 
>> 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
> 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

---

From: Elwyn Davies <[email-masked]>
Date: Wed, 17 Aug 2016 18:04:23 +0100

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.

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.)

- 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.

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.

Cheers,

Elwyn

On 15/08/2016 21:48, Ben Campbell wrote:
> 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:
>
>> some IETF-defined technology) rather than being something that 
>> defines what a WG is intending to work on (RFC 6707 and RFC 7206 are 
> hard-won consensus about requirements. I think that is true for RFC 7206.
>
> I don't see why. Not every action creates a precedent. I do not 
> propose that we add RFC to the downref registry.
>
>> 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?
>
> RFC 3967 section 2 makes no attempt to be exhaustive. It basically 
> says "there are some reasons to make exceptions. Here are some examples."
>
> 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...
>

---

From: Jari Arkko <[email-masked]>
Date: Wed, 17 Aug 2016 21:04:01 +0200

Elwyn, Ben, others,

Thanks for the reviews, changes, and re-reviews.

I won’t raise a Discuss on this point now that Ben has already done it. However, I do care about the end result.

Jari

---

From: "Ben Campbell" <[email-masked]>
Date: Wed, 17 Aug 2016 17:26:01 -0500

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.
>
> 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).
>

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?

> 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.
>
> 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?

> 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.

> copy and paste exercise and tweak the text just a little to fit the 

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.

>> references may need to be normative has come up repeatedly during 
>> IESG reviews over the past year or so.
>>
>> 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.
>>
>>> of rigour is applied to the review of this type of document.  Thus 
>>> it is vitally important to ensure that the definitions are still 
>> 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
> _______________________________________________
> Gen-art mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/gen-art

---

From: Paul Giralt <[email-masked]>
Date: Wed, 17 Aug 2016 20:20:08 -0400

> On Aug 17, 2016, at 6:26 PM, Ben Campbell <[email-masked]> wrote:
> 
>> 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.)
> 

These are fair points and can easily be addressed with some additional verbiage in Section 3.

---

From: "Gonzalo Salgueiro (gsalguei)" <[email-masked]>
Date: Thu, 18 Aug 2016 01:47:21 +0000

> On Aug 17, 2016, at 8:20 PM, Paul Giralt (pgiralt) <[email-masked]> wrote:
> 
> 

I think it is nuanced but worth pointing out those subtleties, especially session->communication session.

Thanks,

Gonzalo