Re: 6MAN WG Last Call: draft-shore-icmp-aup

["Carlos Pignataro (cpignata)" <[e-mail]>]

Hello, Jinmei,

Many thanks for your review! Please see inline.

On Dec 13, 2013, at 4:06 PM, 神明達哉 <[e-mail]> wrote:

> At Fri, 13 Dec 2013 11:41:05 +0100,
> Ole Troan <[e-mail]> wrote:
> 
>> Our AD has requested that the 6MAN working group review this document. This is part of our chartered work
>> to review documents produced outside of 6MAN, that may extend or change the IPv6 protocol.
> 
> [...]
> 
>> As with our regular working group last calls, the chairs would like to solicit one or two people in the working group
>> to do a detailed review of the document.
> 
> I've read the draft.  I don't know if this meets the requirement for a
> "detailed review", but here are my comments anyway:
> 
> - Overall, I didn't see a critical issue in it.  It's also pretty
>  clear and easy to understand.  I can't say anything about the
>  importance of the draft, though, simply because I don't know much
>  about the background concerns.  I also don't know if the proposed
>  guideline and categorization are the "best current practice", but I
>  don't have a strong opinion on these anyway.
> 

Regarding the doc being clear and easy to understand -- Thanks!

Regarding the motivation -- the main goal is to have a documented basis for the IESG to decline ICMP uses when other protocols should be used and ICMP is inappropriate. For example, using ICMP as a substitute of SNMP, or for full-fledged industrial control protocol or full-fledged routing protocol. 

> - In Section 2, I think it'd be more helpful if it shows some examples
>  of "other uses":
> 
>   Normally, other uses are not advisable.
> 
>  Now that I've read the entire draft (Section 2.1.1 and Section 4 in
>  particular), I guess the example could be "used as a routing or
>  network management protocol".

Exactly, as above, and as you point out, those are some of the not advisable uses. We debated and chose not to include examples of other uses, to further future proof the document and not be overly restrictive. That said, I like what you propose below.

> 
> - The subsequent sentence placed in the same paragraph was confusing
>  to me:
> 
>   [...]  While ICMP's role is not to
>   be a general-purpose network management protocol, it does have a role
>   to play in conveying dynamic information about a network.
> 
>  in that I couldn't understand the relationship between the first and
>  second sentences.  Maybe the example mentioning "network management
>  protocol" as suggested in the previous bullet will help clarify
>  that.  For example:
> 
>   Normally, other uses such as implementing a routing or
>   general-purpose network management protocol are not advisable.
>   However, it does have a role to play in conveying dynamic
>   information about a network, which would belong to category 2
>   above.

I think this is better than what we have now. Thanks for the proposal.

> 
> - In Section 2.3, it states:
> 
>   Because ICMPv6 is used for IPv6 Neighbor Discovery, deployed IPv6
>   routers, IPv6-capable security gateways, and IPv6-capable firewalls
>   normally support administrator configuration of how specific ICMPv6
>   message types are handled.
> 
>  Is this true?  The question is actually two-fold: I'm not sure if
>  it's true that "IPv6-capable firewalls normally support..."
>  (especially if such FWs don't have the support for ICMPv4); even if
>  this is true, I'm not sure if that's because ICMPv6 is used for ND.
>  ND messages are only used in a single link, so at least for
>  firewalls from one link to another, ND should still work even if
>  they filter any ICMPv6 packets without any configuration knob.  If
>  these are really true and the fact, then that's fine.  It just
>  didn't seem to me likely.

You will find that the tone of this section is not that of a definitive absolute statement. Chances (and hopes) are that future of configuration features will be implemented in v6 (and ICMPv6) before ICMPv4, if at all on v4.

> 
> - A very minor point: I think "sections" should be "section":
> 
>   In following sections we provide some background on the differences
>   between control and management traffic.
>   (last paragraph of Section 3)
> 
>  because, if I understand it correctly, this "sections" specifically
>  means Section 4 and only that section (and it doesn't have any
>  subsections).
> 

Yes, ack. Since singular, we will also have to add a "the", I will make this change.

Thanks again for the review.

-- Carlos.

> --
> JINMEI, Tatuya
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [e-mail]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------