Re: Last Call: <draft-housley-implementer-obligations-01.txt> (Expectations of Implementers of IETF Protocols) to Informational RFC

[Abdussalam Baryun <[e-mail]>]

I agree with most of Adrian comments.  However, Brian's opinion is
reasonable and the author's intentions are understood, but the draft should
change its approach in solving the problem and its sources. I think more
work needs to be done in the title, Abstract, and body. The draft has a
narrow viewpoint and does not consider the problems in users' expectations
of IETF.

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:

> 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