The draft needs to identify the problem clearly, then design the approach to solve such problem as informational work or as best practice work (it is better to make it an informational). The problem is not only in the user side or the implementor side but also includes the IETF specification author, the problem domain includes IETF process that should consider expectations of both sides.
More comments below, and I hope the author to consider my suggestions and comments in this input.
On Saturday, May 10, 2014, Brian E Carpenter wrote:
On Saturday, May 10, 2014, Brian E Carpenter wrote:
Hi Adrian,
On 11/05/2014 06:34, Adrian Farrel wrote:
> While I appreciate the effort the author put in to resolve previous
> discussions, I do not support the publication of this document.
Agree, because more work is needed.
>
> The thrust of my previous comments were to say "It is all platitude,
> but probably harmless" and "at whom is this document aimed". This
> review is in a little more detail. I still find the whole document to
> be one big platitude that does not need to be published,
I think the requirement was to enhance the relationship between IETF specification author and IETF user, their both expectations are not matching, so the draft needs to fix both sides not only one, while the source of problem may be the IETF or the IETF expectations.
I can certainly see how you could reach that view, but I think you're
looking at it from the viewpoint of somebody who's been around the
IETF for a long time and knows what we do here and why we do it.
You Brain are the same as Adrian, both been around for long time. However, the relationship with diversified users and their expectations is still needed in IETF.
I like to think of somebody else: a young programmer working far,
far away, who will probably never attend an IETF meeting or join
an IETF mailing list. For this person, we need to state things that
are obvious to us.
I agree, but also we need to see if our IETF process and its expectations are involving such small firm diverse users.
For example:
"It is not sufficient to do an initial implementation of the protocol.
Maintenance is needed to apply changes as the come out in the future,
especially to fix security issues that are found after the initial
publication of a protocol specification."
That isn't a trivial statement. It says that a protocol design may have
zero-day vulnerabilities and if you implement it, it's your job to
watch out for future updates and apply them. Is that going to be obvious
to someone starting a garage company in Africa?
I agree, but does IETF have relationships with African users. We cannot make our expectations of others if we don't know them or we don't involve them in this draft process. I recommend many diverse users to review this draft and we get their feedback and document it to the acknowledgement section.
I think the document is valuable.
Valuable only for IETF and for who were around for long, but not much for the diverse implementers. The draft title should state expectation of the relationship between IETF and users/implementers.
One specific comment: I think it should be mentioned that implementers
should always read the references cited in a specification, especially
but not only the normative references, and apply them as relevant.
So that is good suggest, because you are fixing the author side or the IETF side, so any author/IESG-member needs to consider this draft while the IETF processes.
I also suggest mentioning implementation of extensions. Faulty extensions
are harmful to interoperability and security. We have a couple of RFCs
about that too (4775 and 6709).
That is important for both sides authors and users. Does WGs consider all RFCs within IETF or does IETF WGs just look into their published work? We need more cross Area within IETF process, that confuses the users very very much. Users are expecting that IETF is one body and not separated by Areas or WGs, this statement needs to be added to the draft as well.
AB