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 <ianfar...@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 _______________________________________________ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
