On Mon, 17 Jan 2011, Thomas Narten wrote:
This message starts a 6MAN Working Group Last Call on advancing:
Title : IPv6 Node Requirements RFC 4294-bis
Author(s) : E. Jankiewicz, et al.
Filename : draft-ietf-6man-node-req-bis-07.txt
Pages : 26
Date : 2010-12-16
http://tools.ietf.org/html/draft-ietf-6man-node-req-bis-07
as an Informational RFC. Substantive comments and statements of
support for advancing this document should be directed to the
mailing list. Editorial suggestions can be sent to the authors.
This last call will end on January 6, 2011.
I have reviewed this document.
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.
At the same time, I'd also add (or check from WG) if some of the RFCs
not listed should be included.
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.
I think a brief WGLC should be warranted after document update.
The document should be IETF last called.
WG should explicitly request feedback from at least IPSECME WG.
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.
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.
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.
Specifically I'm thinking of the following:
- RFC5014 (IPv6 Socket API for Source Address Selection) - a MAY?
- RFC4584 (Extension to Sockets API for Mobile IPv6) - a MAY, or not listed
- RFC3678 (Socket Interface Extensions for Multicast Source Filters) - SHOULD
- RFC3542 (Advanced Sockets Application Program Interface (API) for IPv6) -
SHOULD
- RFC3493 (Basic Socket Interface Extensions for IPv6) - SHOULD/MUST
RFC4191 (Default Router Preferences and More-Specific Routes) should be
discussed. Is this a MAY? Quite a few host implementations already support
it.
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?
Should Node Information Queries be mentioned (RFC4620)? It would be a MAY.
I'm fine with leaving it out.
S 5.8.2 could refer to RFC4429 (Optimistic DAD) with a MAY support.
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"?
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).
Text on redirects is also new, but probably not very controversial.
S 5.5.1 does not make any (uppercase) recommendation on PMTUD like the
previous version did, just quoting RFC2460. Suggest substituting the first
line with: "Path MTU Discovery [RFC1981] SHOULD be Supported. From
[RFC2460]:"
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.
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.)
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"
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.
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.
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.)
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).
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.
The following two MIBs SHOULD be supported by nodes that support an
SNMP agent.
.. s/MIBs/MIB modules/ :P
--
Pekka Savola "You each name yourselves king, yet the
Netcore Oy kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
