Re: [Softwires] Call for reviewers draft-ietf-softwire-mesh-multicast

Ian Farrer <ianfarrer@gmx.com> Fri, 01 July 2016 09:22 UTC

Return-Path: <ianfarrer@gmx.com>
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E202E12D516; Fri, 1 Jul 2016 02:22:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level:
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 819FkIXRUEkG; Fri, 1 Jul 2016 02:22:01 -0700 (PDT)
Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EE94312D51A; Fri, 1 Jul 2016 02:22:00 -0700 (PDT)
Received: from ians-mbp.lan ([62.225.30.139]) by mail.gmx.com (mrgmx102) with ESMTPSA (Nemesis) id 0M7m0a-1bWIlZ3Ny4-00vPY6; Fri, 01 Jul 2016 11:21:49 +0200
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: Ian Farrer <ianfarrer@gmx.com>
In-Reply-To: <201606211045044291264@cernet.edu.cn>
Date: Fri, 1 Jul 2016 11:21:46 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <1740703A-A445-4F93-9A88-16E7898F1BBD@gmx.com>
References: <B5E05CB1-D4ED-457C-B383-824A52C99650@gmx.com> <201606211045044291264@cernet.edu.cn>
To: xmw@cernet.edu.cn
X-Mailer: Apple Mail (2.3124)
X-Provags-ID: V03:K0:viBNUHHnzesmDBDSa2a9GAXIQXg/b69Ymjbpl5rNhIDG/TMzf8E 5wfD9L8AwMB/MqRbDBL+pFY6y6eKYU3T/PrknHz2YX8CISgOK9ZhBZCHoXBUrtlY0tvAIv1 hqoprIHXuXEbHofM1FgjCADVIncSwgSMYekQJUJS0HVYy6TJP1fsyxcB5gfttPyFy4mKwsp HcnRFFA0iqf/OX48/nkdQ==
X-UI-Out-Filterresults: notjunk:1;V01:K0:DU/3Yk6UD0c=:TclWL1+Ysl83IvbP2VDsZ0 stm9Im+2902nmTlIGNJ8avKnrdYEpXWVkQbDG4/b2AM2Yp5WFWULuftk3niRUlKfUVwIUP3uU RTvj8JbtjXXvJ3wlgERZqrAK1jM+g+jQW+ZdJxKIxv4qIB7pmVFGqN/aQJ0nAz8lYoNeD9j1I aV3y5WeUIF48xv0kGEoa1n3rozegjfYIqAKI0iIdP3CWTOnwqOP6jFY6n+ZRBcv6UWB2EWojZ KZbbfDPPdRUmdKhfgTbyES7PmAs4bQ5WLJQySen2hdUR6osLMDIJulW/nTarbMnyX/YAH/6/W 9I0ijE6oXPnX2tKblp9fGkG6lA6Is8M9zjHfwnvomy85Ic2AMVIujTbUP5I7J9WoDTp8rGXRl ZvV/MnKsrvWt61ZxUOLk/WYmzG7EwfBjxzSW6hwBk4KBlJWct1oWILNkYNJb50SVO4olJu3W7 84tBr0Sy/Sg50JFVoRxipfzSbXgvgWradV7SJGa9GUn6IwLN8YyjZDUmhbfMMQK9l02oVGpo4 qkTr4qSh1i2+AQkrLTTPx038FSnxuedH31A+LZ0V21RFgT9H0tIFZcstIbTxZMce1oSXolLSk CsEUupBlB+inuZMgrwdt59HvCjEwgy7MgN4Of/sWKOoZeq/Xg6CZtmxoApiAi7lpPI1u062zX OjYHeeTVe/eJZmE6LfYQkwoMy2uelTJOQ9iWQ0Ppq3K0q/jwASnjoHdYsiSgJGyBrxSUFCGXy F5hiqi3Ky4eylicP/lEgDlEo2OeD6QCQ/4BVLhYosKWeFLovC+3//9gqxiQAxWQ6iX41GxDdO qu4+fap
Archived-At: <https://mailarchive.ietf.org/arch/msg/softwires/3pudYLupBE4-Es9jtNB9tMTQws8>
Cc: softwires <softwires@ietf.org>, draft-ietf-softwire-mesh-multicast <draft-ietf-softwire-mesh-multicast@ietf.org>
Subject: Re: [Softwires] Call for reviewers draft-ietf-softwire-mesh-multicast
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: softwires wg discussion list <softwires.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/softwires>, <mailto:softwires-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/softwires/>
List-Post: <mailto:softwires@ietf.org>
List-Help: <mailto:softwires-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/softwires>, <mailto:softwires-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 01 Jul 2016 09:22:04 -0000

Hi,

Please see inline below.

Cheers,
Ian

> 
> 2. Section 4.1
> The translation between the IPv4 and IPv6 PIM messages seems underspecified. It would be useful to provide some examples showing how the new addresses are used in the different translations into the PIM message formats (RFC7741 Section 4.1).
> 
> Answer: We have added some examples in Section 8.

[if - It would be useful to have a reference in section 4.1 to the section 8 examples]

> 6. Section 7.2
> Are there options on the kind of tunnel encapsulation that can be used? It would be useful to enumerate some of these and for interoperability one of them needs to be mandatory to implement.
> 
> Answer: We have added an paragraph in a new Section (Sec. 9), to state that the mechanism should accommodate a variety of encapsulation mechanism mentioned in RFC 4925 (Sec 3.5).

[if - Section 9 is adds MUST requirements to RFC4925, but RFC4925 is an Informational RFC. What about referring to the encapsulation methods in RFC4925 without RFC2119 language, then have a MUST requirement that all of the AFBRs attached to the I-IP implement the same encapsulation mechanism?]

> 
> 
> 9. The use of RFC2119 language and the case of the words throughout the document is not consistent (there are a number of lower case ‘must’ etc, that probably should be uppercase).
> The term ‘should’ (lower case) is used in a number of places that make the functionality of the mechanism seem uncertain (e.g. Figure 1 - 'Multicast packets should get across the I-IP transit core'. Sec 4.1 'it should be translated back’).
> There are some points that would seem to need MUST requirements that are missing - e.g. Section 4.4 'every uPrefix64 that AFBR announces should be different either, and uniquely identifies each AFBR’. If two AFBRs are announcing the same uPrefix64, surely there will be problems.
> Suggest that the use of RFC2119 language is revised throughout the document to avoid these problems and to tighten up the specification as a whole.
> 
> Answer: We revised throughout the document to make the ‘Conventions/Requirements' words consistent.
> 
> 10. The document needs the language and grammar checking throughout.
> 
> Answer: We have checked throughout the document and re-edited the language and grammar.

[if - I’m still seeing some problems with the above two points. I’ll reply you directly on these]

> 
> 
> Best regards,
> 
> Mingwei
> 
> 
> 
> 发件人: Ian Farrer 
> 发送时间: 2016-04-20  03:53:13 
> 收件人: draft-ietf-softwire-mesh-multicast; softwires 
> 抄送: 
> 主题: Re: [Softwires] Call for reviewers draft-ietf-softwire-mesh-multicast 
> Hi,
> 
> 
> Here is my review of the draft.
> 
> 
> Best regards,
> Ian
> 
> 
> Pg 5 - states a 'dual-stack' router. The AFBR is not really dual-stack here. It has two single stack interfaces and implements a transition technology. Suggest removal of dual-stack.
> 
> 
> Section 4.1
> The translation between the IPv4 and IPv6 PIM messages seems underspecified. It would be useful to provide some examples showing how the new addresses are used in the different translations into the PIM message formats (RFC7741 Section 4.1).
> 
> 
> Section 4.2
> The term ‘MPREFIX64’ is not defined in RFC7371. As there are a number of different formats for multicast prefixes in RFC7371, it would be useful to point to the relevant section to avoid confusion.
> 
> 
> Why was the name MPREFIX64 chosen for 4in6 multicast? In other Softwire docs (e.g. RFC7598), ’46’ is used to denote 4 in 6 functions and 64 for 6 in 4. As the addressing and mechanism for 4in6 differs for 6in4, it would make sense to differentiate this in the naming of the fields (i.e. use MPREFIX46, uPrefix46 for 4in6 and uPrefix64 for 6in4).
> 
> 
> Section 6.3
> Section 6 overall defines requirements for the control plane. Sections 6.1. and 6.2 are MUST requirements. 6.3 uses ‘should’ in defining the behaviour. Can the mechanism work without implementing sec 6.3 and in which situations is it acceptable not to?
> 
> 
> Section 6.5
> This introduces the encapsulation of messages, but doesn’t provide any information about what type of encapsulation is used. Figure 7 shows UDP. Is this part of the encapsulation? As this is necessary for the mechanism to work and needs to be implemented on the AFBRs, there needs to be references and requirements language on what needs to be implemented.
> 
> 
> s/we do insure/it is ensured/
> 
> 
> Section 7.2
> Are there options on the kind of tunnel encapsulation that can be used? It would be useful to enumerate some of these and for interoperability one of them needs to be mandatory to implement.
> 
> 
> References
> RFC2119 Needs to have a normative reference
> RFC4601 has been obsoleted by RFC7761
> 
> 
> General - 
> The document doesn’t contain the ‘Conventions/Requirements Language’ boilerplate pointing to RFC2119 that needs to be in a standards track document. (The key words "MUST", "MUST NOT”, …)
> 
> 
> The use of RFC2119 language and the case of the words throughout the document is not consistent (there are a number of lower case ‘must’ etc, that probably should be uppercase).
> 
> 
> The term ‘should’ (lower case) is used in a number of places that make the functionality of the mechanism seem uncertain (e.g. Figure 1 - 'Multicast packets should get across the I-IP transit core'. Sec 4.1 'it should be translated back’).
> 
> 
> There are some points that would seem to need MUST requirements that are missing - e.g. Section 4.4 'every uPrefix64 that AFBR announces should be different either, and uniquely identifies each AFBR’. If two AFBRs are announcing the same uPrefix64, surely there will be problems.
> 
> 
> Suggest that the use of RFC2119 language is revised throughout the document to avoid these problems and to tighten up the specification as a whole.
> 
> 
> The document needs the language and grammar checking throughout.
> 
> 
> 
> 
> On 7 Apr 2016, at 16:58, Ian Farrer <ianfarrer@gmx.com> wrote:
> 
> 
> Hi,
> 
> This document has been around for some time, but has not received any substantive reviews. Can I ask for volunteers who are willing to provide reviews?
> 
> Thanks,
> Ian
> 
> 
> _______________________________________________
> Softwires mailing list
> Softwires@ietf.org
> https://www.ietf.org/mailman/listinfo/softwires