Hi all, The node requirements draft was reviewed by the IESG. Here are the main points raised, arranged by reviewer.
The big issue I see is about upgrading IKE to a SHOULD. I'll try to start addressing the points after Christmas, but feel free to discuss it already. Set 1: > I'm astonished that Path MTU is a MAY -- I had thought it was > a MUST. I'd really like some more text explaining what some > of the many exceptions are that are alluded to here. > > For Section 8, RFCs 2401, 2402, and 2406 are currently being > revised by the IPsec group; that should be mentioned. > > The crypto algorithm requirements should be better aligned > with recommendations from the IPsec wg. There's a draft that > lists 3DES as SHOULD, not MAY. > > I think that IKEv? should be a SHOULD, not a MAY. While the > IESG hasn't yet seen draft-bellovin-mandate-keymgmt, it will > soon and it describes automated key management as a "strong > SHOULD". That's certainly the consensus in the security area. > > More generically, I don't think that this WG should > standardize weaker security requirements than the security > area thinks are appropriate, without strong justification. > (Stronger requirements are fine -- they may have a different > operational environment, or a different threat model.) Set 2: > 1. Section 10.1.1 talks about "IP Forwarding Table MIB" > The revision of this MIB document (that you refer to) has a number > of deprecated and obsoleted objects. I think what you want (intend) > to say is that an agent must implement those objects that are > required as per ipForwardFullCompliance or ipForwardReadOnlyCompliance. > > I am also not sure that this is correct: > Support for this MIB does not imply that IPv4 or IPv4 specific > portions of this MIB be supported. > Did you mean "IPv4 or IPv6 specific portions" ? > But maybe the sentence is not needed at all. The two MODULE-COMPLIANCEs > that I point you to above specify IP version neurtral objects! > > 2. Similar comments/issue with Sect 10.1.2 > I think you want to refer to CURRENT MODULE-COMPLIANCE, namely > ipMIBCompliance2. Pls check and make sure you be specific as to what > needs to be supported. Set 3: > One bigger issue, which may not be worth a Discuss, but > something that > IMHO should be discussed in some forum: > > All nodes that need to resolve names SHOULD implement stub- > resolver [RFC-1034] functionality, in RFC 1034 section 5.3.1 with > support for: > > - AAAA type Resource Records [RFC-3596]; > - reverse addressing in ip6.arpa using PTR records [RFC-3152]; > - EDNS0 [RFC-2671] to allow for DNS packet sizes larger than 512 > octets. > > .. I'm operationally concerned about the last SHOULD. As far as I > know, EDNS0 is not really implemented. It does not seem to include a > SHOULD to something that hasn't seen practical, wide-spread deployment > already. I'd recommend removing this or rewording it to a MAY. John -------------------------------------------------------------------- IETF IPv6 working group mailing list [EMAIL PROTECTED] Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
