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
_______________________________________________
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art
