There are gaps here, but there in other places:
- the gap between what a protocol needs and what is in the spec
if HBH isn’t needed and can’t be implemented, remove them
if HBH is needed, then we need to find a way to have the requirement
mean something
A similar problem exists with fragmentation. NIMBYisnm won’t fix it, nor will
operator declarations, nor false security declarations.
I don’t have a problem with fixing the STANDARD. I have a problem with an
end-run in ops.
Joe
> On Dec 5, 2018, at 6:31 AM, Stewart Bryant <[email protected]> wrote:
>
>
> As far as I see, this thread illustrates that there is a significant gap
> between the protocol designers, the protocol implementers and the protocol
> users. This is something that needs to be addressed if the IETF is not to
> loose its reason to exist.
>
> Best regards
>
> Stewart
>
>
>> On 05/12/2018 13:45, Joe Touch wrote:
>> Vendors are not required to lie when claiming IPv6 support.
>>
>>> On Dec 5, 2018, at 5:38 AM, Gert Doering <[email protected]> wrote:
>>>
>>> Hi,
>>>
>>> On Wed, Dec 05, 2018 at 04:31:17AM -0800, Joe Touch wrote:
>>>>> On Dec 5, 2018, at 4:21 AM, Gert Doering <[email protected]> wrote:
>>>>>
>>>>>> On Wed, Dec 05, 2018 at 04:13:47AM -0800, Joe Touch wrote:
>>>>>> Then THAT is the security issue. Not the packets that cause a broken
>>>>>> implementation to have problems.
>>>>> Can we declare folks at IETF that have no idea about operational realities
>>>>> to be a security issue?
>>>> As long as we can do the same for operators that blame protocols for
>>>> vendor issues.
>>> If a protocol cannot be implemented in a way that can be paid by real world
>>> participants, it's not a vendor issue.
>>>
>>> Gert Doering
>>> -- NetMaster
>>> --
>>> have you enabled IPv6 on something today...?
>>>
>>> SpaceNet AG Vorstand: Sebastian v. Bomhard, Michael
>>> Emmer
>>> Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann
>>> D-80807 Muenchen HRB: 136055 (AG Muenchen)
>>> Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279
>>> _______________________________________________
>>> Tsv-art mailing list
>>> [email protected]
>>> https://www.ietf.org/mailman/listinfo/tsv-art
>
_______________________________________________
OPSEC mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/opsec
