Re: [arch-d] Comments on draft-iab-protocol-maintenance-03

[Guntur Wiseno Putra <[e-mail]>]

Dear All,


Is there ones like these at either www.iab.org or  www.ietf.org...?

"A Cybermap on Protocols (Development):
It is supposedly helpful for newcomers to get toward such a knowledge on
how the Internet protocols collaborate currently --may it be better if
there are also cybermaps working on historical collaborations of
protocols...

To get into the concepts, please see:

www.cybergeography.org on "conceptual" or

https://personalpages.manchester.ac.uk/staff/m.dodge/cybergeography/atlas/conceptual.html

That supposedly concern with what of the previous message sent by S.
Moonesamy


I'll illustrate the point as follows: we are talking with each other as we
both know where to have the discussion and with whom.  That is not obvious
to a person who has not participated in the development of a protocol.  In
essence, the document would have to stand on its own if we are interested
in document clarity.  There is a thread about an erratum:
https://mailarchive.ietf.org/arch/msg/yam/MtuLDdVBbG4U2Schf-xDEwsXAt0 which
might illustrate that point.


Regard,
Guntur Wiseno Putra

Pada Kamis, 09 Mei 2019, S Moonesamy <[e-mail]> menulis:

> Hi Martin,
> At 11:32 PM 08-05-2019, Martin Thomson wrote:
>
>> I don't think there is any real science here.  People can try to talk to
>> each other.  As you say, you need feedback to identify those things.  Yes,
>> some things seem obvious to some and not others, but a conversation can go
>> a long way to understanding and reconciling these little miscommunications.
>>
>> See https://github.com/quicwg/base-drafts/issues/2671 for a recent
>> example of how obvious isn't always very obvious.
>>
>
> Thanks for pointing me to an example.
>
> I'll illustrate the point as follows: we are talking with each other as we
> both know where to have the discussion and with whom.  That is not obvious
> to a person who has not participated in the development of a protocol.  In
> essence, the document would have to stand on its own if we are interested
> in document clarity.  There is a thread about an erratum:
> https://mailarchive.ietf.org/arch/msg/yam/MtuLDdVBbG4U2Schf-xDEwsXAt0
> which might illustrate that point.
>
> Mostly because no one bothered for a long time.  There was no community
>> and no maintenance for many years.  When a group of people finally decided
>> to fix the rotten thing, the pile of work was massive and the deployed base
>> crufty.  We're talking HTTP/1.1 here, which is a big protocol with lots of
>> woolly bits.  It has more woolly bits thanks to that period of neglect, but
>> the community is slowly and carefully clawing away the worst of the rot and
>> I think that good progress has been made in the past 10 years.  It's slow
>> and deliberate, but I think that's the right approach.
>>
>
> The IETF used to be discourage efforts about protocol maintenance (please
> see the old discussions about maturity levels).  As you mentioned, it is
> only when there is a significant push that the specification goes through
> another review and that is far from easy when the specification is a decade
> old.
>
> Yes it is indeed simpler.  But that's what builds up the bad mojo and so I
>> would have us reject that notion as a first option.  FWIW, I've found it a
>> fairly pleasant experience dealing with people on the other end of
>> protocols.  If we agree that there is a bug (which is often the case), it
>> gets fixed.  I've had a few cases where it didn't get fixed very fast, but
>> we tend to work out a plan for managing the problem.  Things usually work
>> out better in the end that way.
>>
>
> Ok.
>
> Yes.  That's a huge problem.  That's why I'm a big fan of efforts from the
>> IESG to smooth the path for updates (draft-roach-bis-documents, the work on
>> finding referenceable interoperable targets, and the associated work).
>> Institutionally, the IETF is not very well suited to this.  Despite that,
>> we've been able to make the process work in a few groups.
>>
>
> Please see the comment about maturity levels.  I agree with your comment
> about the IETF not being well suited for "updates".  There has been some
> progress in the recent past on putting a little more effort after the
> publication of the initial specification.
>
> Yes, but I really didn't want to get into that.  To a first approximation,
>> I find that the desire for interoperability is the overriding concern in
>> most cases.  However, we routinely get into situations where competitive
>> pressures might affect the process of reaching an amicable conclusion.
>> That's why we have the IETF and other such places, and the process
>>
>
> Ok.
>
> Probably a whole lot of better-informed developers and a whole lot of
>> software that is built for use cases that matter.  There's a privacy risk,
>> of course, but I know that Mozilla wouldn't survive without telemetry.  We
>> have a little bit, but it is never enough.
>>
>
> I am not keen on using telemetry (excluding the Mozilla case) as one has
> to do a PIA.  There was a recent case about telemetry:
> https://www.rijksoverheid.nl/documenten/rapporten/2018/11/07
> /data-protection-impact-assessment-op-microsoft-office
>
> Testing is awesome, but tests are fallible just like specifications.  Test
>> the wrong thing and you get the wrong behaviour.  And it's possible that
>> tests miss something entirely.  Telemetry can give you insight into
>> problems if you ask the right questions (a difficult skill, to be sure),
>> and provide a useful barometer for transient problems.  I doubt that you
>> would find any server operator out there who could operate without a feed
>> of CPU and network utilization from server instances.  What is measured
>> differs depending on what your system does, but it's all the same
>> principle: the longer and looser the feedback loop, the harder the system
>> is to operate.
>>
>
> Ok.
>
> Nah, this is mostly just my own bias.  As others have pointed out, we
>> don't know if that's a problem.  The next version will probably have some
>> sort of caveat on it to that effect.  There are lots of good examples out
>> there, but it's hard finding concise descriptions of them.  (They tend to
>> read like Paul Wouters' tale of IPsec woe.)
>>
>> I don't quite know what you refer to in Mozilla's FTC submission there.
>> There's a lot going on.
>>
>
> There was a comment in that submission about interoperability.
>
> Regards,
> S. Moonesamy
> _______________________________________________
> Architecture-discuss mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/architecture-discuss
>