FW: Evaluation of: draft-ietf-ipv6-node-requirements-07.txt

[john.loughney@nokia.com]

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
ipv6@ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------