Pekka Savola <[email protected]> writes: > I have reviewed this document.
Thanks agin! > The most important omission is that RFC4294 changelog is not up-to-date. > This gives a good overview on what has changed and it needs to convey > accurate information. ACK. I've just posted a new version. Have a look to see the changes. > At the same time, I'd also add (or check from WG) if some of the RFCs > not listed should be included. We've done multiple passes on trying to include all relevant RFCs. Seems to be a never-ending task... > Some requirement levels have also changed, and explicit support from > WG would be good on these. With an updated RFC4294 changelog, rough > consensus on the result could be evaluated. OK. But to be clear, the changes in this document have been discussed on the list and IMO do have consensus. I.e., they are not "surprises". > I think a brief WGLC should be warranted after document update. OK (if we can get more reviewers!) > The document should be IETF last called. No objection. > WG should explicitly request feedback from at least IPSECME WG. IPsecME has seen and reviewed text. Indeed, some IPsecME members helped with getting the text right. I also presented the text at the saag meeting in Maastricht > substantial > ----------- > General: > Section 21 describes Changes from RFC 4294. This is not up-to-date. > Specifically, at least S 17-20 describe changes between draft versions that > are not incorporated in S 21. As "changes between drafts" sections are > removed upon publication, it is important that the changes from the previous > RFC are complete. The updated RFC references are of medium importance > (there are significant changes e.g. in the requirements imposed by ICMP > specification versons), but changes in requirement level seem like a high > importance issue. As such the former could be addressed with a short > list. I took a stab at this, but I'm not sure I got all the major changes. In particular, there were a couple of revs of the ID before we started adding changes between versions. > This is a very important section for a document like this as just by > looking at it you should be able to see the major new requirements > or changes in requirements. Therefore, updating this should be the > first priority. Then I would suggest another Last Call, just to > make sure there's rough consensus on these higher level bits. fine with me. > Specific not in text: > --------------------- > I think this document should also discuss APIs we have defined and that > relate to the protocols described in the document. A separate section > should be added on this. I added a section on APIs. I made them all FYIs. I agree with the comments others have made on the list that we can't mandate them. > RFC4191 (Default Router Preferences and More-Specific Routes) should > be discussed. Is this a MAY? Quite a few host implementations > already support it. I added it as a MAY. I don't think its widely enough implmented or used (?) to say this is even a SHOULD. > In the context of autoconfiguration, RFC5453 (Reserved IPv6 > Interface Identifiers) should probably be discussed. My quick > (re-)read of it seems to say that every host should avoid the > designated IIDs. Is host support needed for this? I added a reference to 5453 to the section on temporary addresses. > Should Node Information Queries be mentioned (RFC4620)? It would be > a MAY. I'm fine with leaving it out. I think not. AFAIK, its not widely used. > S 5.8.2 could refer to RFC4429 (Optimistic DAD) with a MAY support. I added a paragraph on this, but made it clear this is not something that general purpose nodes need to do at this time. > The document is silent on Flow Label (as Brian mentioned). Rather than > silence, I might be tempted to say something at least from the current > perspective. The key point here is, "are hosts expected to randomize or > otherwise by default set a flow label"? I'll defer to the list for guidance. That said, the general position being taken for this document is not to update other specs, but to refer to them. Given the Flow Label spec is under review, I don't think we should say much. > Specific on text: > ----------------- > S 5.2 no longer requires support for DAD but this is actually done > in S 5.8.2. A pointer might be helpful (though not necessary). I think what I did was consolidate text that was (previously) in two sections in RFC 4294. > Text on redirects is also new, but probably not very controversial. It was taken from the mailing list... > S 5.5.1 does not make any (uppercase) recommendation on PMTUD like the > previous version did, just quoting RFC2460. That was intentional. I don't see why we need to say you MUST do 2460, and then go and say you MUST/SHOULD do things that are required in 2460 already. That seems redudent to me, and raises the question of why we do that for some, but not other pieces. AFAICT, most everyone implements PMTUD. So I don't think we need to call out any part of RFC 1981 specifically. > line with: "Path MTU Discovery [RFC1981] SHOULD be Supported. From > [RFC2460]:" done > S 5.8.3 has watered down the privacy addresses text: > In such situations, RFC4941 SHOULD be implemented. In other cases, > such as with dedicated servers in a data center, RFC4941 provides > limited or no benefit. > .. this is not acceptable. Per previous RFC, we should say: > RFC4941 SHOULD be supported. I strongly disagree, and there was a thread about this. I have seen cases where people just assume that 4941 should be supported by all nodes, including servers (not clients) in data centers. There is no need to implement 4941 on server-only systems. Please review the thread at http://www.ietf.org/mail-archive/web/ipv6/current/msg10468.html and if you have further comments, speak up. But it was an explicit goal to not just say "SHOULD" with not context/direction, as RFC 4294 does. > We could also add (or make specific recommendations): > This document does not make a generic recommendation on the default > behaviour. > I note that previous version of the doc also suggested privacy be configurable > on per-connection basis, etc. -- this text has been removed now. (I did not > dig deeper whether it has been incorporated in RFC4941 revisions > etc.) Discussed on list (a very long while back). The suggestion to do per-connection overrides and all was deemed as going too far. > In S 5.9, > A reference should be added (MAY support) to RFC 5790, > "Lightweight Internet Group Management Protocol Version 3 (IGMPv3) and > Multicast Listener Discovery Version 2 (MLDv2) Protocols" Actually, I may need some help with this. If 5790 is enough, and omits functionality that most nodes don't need, we should recommend its usage. We should provide clear guidance on when it makes sense to recommend one over the other. > In S 7.3: > Implementations SHOULD implement the DNS RA option [RFC6106]. > .. is this too strong? DHCP is (only) a conditional SHOULD. I'm OK with > this as it is, but I would also be fine with a MAY. This was discussed on the list (a little). I could go either way. Curent text is a SHOULD (see Section 7.3 of the draft). > In S 10, Certain Mobile IP-specific SHOULDs have been downgraded to > a general MAY. I'm fine with this but I would have been OK with > retaining those specific SHOULDs. Long list discussion. I think the feeling about MIPv6 has changed. It has clearly not been deployed and there may be better alternatives now. Hence, a MAY. > In S 11, IPsec and IKE have been downgraded to a SHOULD. I'm fine with this. > (None of the changes I've mentioned are listed in the changelog.) Added to changelog. And discussed in all the right places, (6man, saag, ipsecme). > editorial: > ---------- > - Transmission of IPv6 over IPv4 Domains without Explicit Tunnels > [RFC2529] > ... even as an example, this is a bad one. It is not used and there exists > probably about one implementation. I suggest replacing this with RFC4213 > (an existing reference). Done. > 5.9. Multicast Listener Discovery (MLD) for IPv6 - RFC 2710 > .. take out the RFC number from the title as you're actually addressing two > different MLD versions in this subsection. Done. > The following two MIBs SHOULD be supported by nodes that support an > SNMP agent. > .. s/MIBs/MIB modules/ :P Done. Thomas -------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
