Ole, Getting back to some of your other points...
Ole Troan <otr...@employees.org> writes: > >> * RFC2675: I would just remove that. > > > > The docuent currently says: > > > > IPv6 Jumbograms [RFC2675] MAY be supported. > > > > How about I replace that with: > > > > IPv6 Jumbograms [RFC2675] are an optional extension that allow > > the sending of IP datagrams larger than 65.535 bytes. IPv6 > > Jumbograms make use of IPv6 hop-by-hop options and are only > > suitable on paths in which every hop and link are capable of > > supporting Jumbograms (e.g., within a campus or datacenter). To > > date, few implementations exist and there is essentially no > > reported experience from usage. Consequently, IPv6 Jumbograms > > [RFC2675] remain optional at this time. > > > > (key change is "MAY" to just lower case "optional"). > I'm fine with that. > the reason I brought it up is because we have people (aka customers) > asking us for support for this. and it has so far in every case > been either because of mixing it up with jumbo frames, or not > understanding what it is. Understood. One of the goals of this version of the document is to make sure that there is real guidance, and not just "you SHOULD do this". If there is guidance, hopefully people will think a little bit more before asking vendors to implement something that does not appear to be needed in practice... > I disagree. the consequence is that hosts that not support DHCP, > will just not get service. that's pretty bad, and I think the > prudent approach would be to have SLAAC as a MUST and stateful as a > SHOULD. after all you have the following text that states: > "However, some environments may require the use of DHCP and may > not support the configuration of addresses via RAs." > that is a pretty severe interoperability problem. I'm happy that > 6106 is a SHOULD, but if you are looking for implementations for > that option you have to look very hard "at the present time". > basically I want the document to say that IETF has standardised two > mechanisms to configure hosts. one using ND and one using DHCP. as > they apply to different management models, nodes SHOULD implement > both. (and add suitable apologies to the world for having messed > this up badly. ;-)) I personally would support having DHCP be a SHOULD rather than a MAY. The justification in my mind is that if you want the network operator to have the choice of whether they want to use Stateless addrconf OR DHCP, they only have that choice of devices widely implement both. But that is not a new argument, and isn't any different today than it was ten years ago. And over the years, the WG has not always been particularly friendly towards DHCv6. It's only in the last few years that there has been an acceptance that DHCPv6 will actually get used on some deployments (by operator choice). However, I do not see evidence that the WG has changed its thinking and would now be willing to make implementation of DHCP a SHOULD. Unless this changes, I will leave the text as is. Thomas -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
