[ipv6-wg] Latest draft for RIPE554-bis

> On 23 Nov 2021, at 16:41, Dave Taht <dave.taht at gmail.com> wrote:
> 
> On Tue, Nov 23, 2021 at 8:31 AM Tim Chown <Tim.Chown at jisc.ac.uk> wrote:
>> 
>> Hi Dave,
>> 
>>> On 23 Nov 2021, at 16:09, Dave Taht <dave.taht at gmail.com> wrote:
>>> 
>>> It is perhaps selfish of me to really want active queue management, of
>>> some form, as part of specifications for new equipment.
>>> 
>>> https://datatracker.ietf.org/doc/rfc7567/
>> 
>> I would agree, but this doc is IPv6 requirements, while the RFC is generally applicable to v4 or v6?
> 
> It's an and, not an or.
> 
> Additionally useful treatments of the ipv6 flow header, and the
> diffserv & ecn bits, the ability to shape or police traffic, would be
> nice to have in a document that talks to the properties of switches
> and routers.

So we could for example in Section 4 in Optional at least add

	• Active Queue Management support [RFC7567] 

?

(Where AF and EF are listed for QoS)

Tim

> 
>> Tim
>>> 
>>> On Tue, Nov 23, 2021 at 7:38 AM Tim Chown via ipv6-wg <ipv6-wg at ripe.net> wrote:
>>>> 
>>>> Hi Eric,
>>>> 
>>>> 
>>>> Many thanks for your comments, we’ve updated the ‘living draft’ at
>>>> https://docs.google.com/document/d/10HsfHDOIhUPIvGk9WP0azJiIsMVzQ49RsqWfnbNtceI/edit#
>>>> And attached as PDF.
>>>> 
>>>> In-line...
>>>> 
>>>>> On 5 Nov 2021, at 07:52, Eric Vyncke (evyncke) <evyncke at cisco.com> wrote:
>>>>> 
>>>>> Tim*2, Sander, Jan, and Merike,
>>>>> 
>>>>> First of all, thank you for taking the pen to update this document. As you kindly asked for comments, here are some
>>>>> - page 2: 'fairly recent' won't age well ;-)
>>>> 
>>>> Removed.
>>>> 
>>>>> - page 4: all requirements are limited to performance, but should it also include telemetry/monitoring ? Or is it implicit in the list of RFC ?
>>>> 
>>>> Agreed - we added mention of capabilities in a couple of places.
>>>> 
>>>>> - page 4: what about systems to handle VMs and containers ?
>>>> 
>>>> Out of scope.
>>>> 
>>>>> - page 4: mobile devices have a *big difference* with normal host though as they often have multiple interfaces active at the same time.
>>>> 
>>>> True, but out of scope.  The document is about their connectivity to the enterprise infrastructure.  We could note this, but currently do not.
>>>> 
>>>>> - page 4: should we assume that Wi-Fi access points are 'normal layer-2 switches' ?
>>>> 
>>>> Added text to say consider as L2 consumer switch, see Section 3.1.
>>>> 
>>>>> - page 6: I am surprised to see RFC 8415 DHCPv6 client as mandatory…
>>>> 
>>>> Fair comment, as this could be something contentious.  The only way we can think to avoid that is to include the DHCPv6 requirements conditionally, ie. “IF you need DHCPv6 then…” those requirements are required.  So networks deploying with just RA for address configuration can avoid that.
>>>> 
>>>>> - page 6: if not mistaken RFC 8200 now includes RFC 5722 and RFC 8021 (so no need to add the latter in the requirements)
>>>> 
>>>> Deleted 5722 and 8021.
>>>> 
>>>>> - page 7: same surprise to see all DHCP-related requirements
>>>> 
>>>> Also made into an “If DHCPv6 is needed then”
>>>> 
>>>>> - page 7 and other: nice to list some MIB but I would expect some YANG modules as well for enterprise/ISP devices
>>>> 
>>>> RFC8504 covers this in16.2, should we say the same words here, as optional in each section?
>>>> https://datatracker.ietf.org/doc/html/rfc8504#section-16.2
>>>> Thoughts?
>>>> 
>>>>> - page 9: should Jen's RFC 9131 be added as optional ?
>>>> 
>>>> Can do, in which sections?   Presumably 4.1 and 4.4?
>>>> 
>>>> Best wishes,
>>>> Tim
>>>> 
>>>> 
>>>> To unsubscribe from this mailing list, get a password reminder, or change your subscription options, please visit: https://mailman.ripe.net/
>>> 
>>> 
>>> 
>>> --
>>> I tried to build a better future, a few times:
>>> https://wayforward.archive.org/?site=https%3A%2F%2Fwww.icei.org
>>> 
>>> Dave Täht CEO, TekLibre, LLC
>> 
> 
> 
> -- 
> I tried to build a better future, a few times:
> https://wayforward.archive.org/?site=https%3A%2F%2Fwww.icei.org
> 
> Dave Täht CEO, TekLibre, LLC