Adrian's text looks fine to me (i.e. unambiguous, without needing RFC 2119 language).
Regards Brian Carpenter On 2010-12-25 02:16, Adrian Farrel wrote: > Hi, > > IETF last call completed without further comments. > > Can I suggest > > OLD > When a Group-to-RP mapping entry is created in the > pimGroupMappingTable in the PIM-STD MIB[RFC5060], it would be > acceptable to have an entry with an RP with address type 'unknown' > and a PimMode of Dense Mode or SSM. These entries would represent > group ranges for Dense mode or SSM. > > Also all the entries which are already included in the SSM Range > table in the IP Mcast MIB would be copied over to > pimGroupMappingTable. They would have a type of configSSM and an RP > with address type 'unknown' as described above. > > The advantage of keeping all the ranges in the table would be that > this table will contain all the known multicast group ranges. > NEW > An implementation of this specification can continue to be managed > using the PIM-STD-MIB [RFC5060]. When a Group-to-RP mapping entry is > created in the pimGroupMappingTable the RP with address type in the > pimGroupMappingRPAddressType object is set to unknown(0), and the > PIM Mode in the pimGroupMappingPimMode onject is set to either > ssm(2) or dm(5) to represent group ranges for SSM or Dense mode. > > Also, all the entries which are already included in the SSM Range > table in the IP Mcast MIB [insert reference] are copied to the > pimGroupMappingTable. Such entries have their type in the > pimGroupMappingOrigin object set to configSsm(3), and the RP > address type in the pimGroupMappingRPAddressType object set to > unknown(0) as described above. > END > > In addition, you have a few other changes to make, so I will wait for a new > revision before asking the IESG to review the document. > >> -----Original Message----- >> From: Bharat Joshi [mailto:[email protected]] >> Sent: 20 December 2010 02:35 >> To: Brian E Carpenter; Andy Kessler (kessler) >> Cc: [email protected]; General Area Review >> Team; Stig Venaas; Mike McBride (mmcbride) >> Subject: RE: Gen-ART LC review of draft-ietf-pim-group-rp-mapping-07.txt >> >> Hi, >> >> > 3. In section 8, "Clarification for MIB Objects", I'm not >>>> sure what we have to say to be sure its understood that this >>>> is a normative reference. Suggestions ? >>> You know, maybe you need to have a MIB expert glance at this text, >>> for example the original MIB Doctor who reviewed the MIB module in >>> the first place. I'm not sure that any language I propose will be >>> any better than what you already have. However, if 'it would be >>> acceptable' becomes a MAY construct and 'would be copied' becomes >>> 'SHOULD be copied', then it's clearly normative. >>> >>>> Bharat, please spin a new version... >>> Or you can wait to see if any other last call comments come in... >>> >> Let us wait for other last call comments. I am hoping one of the MIB Doctors >> will >> comment on this and we can find a way to address this concern. >> >> Regards, >> Bharat >> >>> Thanks >>> Brian Carpenter >>> >>> >>> On 2010-12-20 07:49, Andy Kessler (kessler) wrote: >>>> Ok, we have made progress. >>>> >>>> These are the suggested changes we need to make: >>>> >>>> 1. In Section 3, Existing Algorithm. Add a new sentence to >>>> the end: >>>> >>>> The full benefits of the new algorithm will not be realized >>>> until it is widely deployed. >>>> >>>> 2. In section 5, Common use cases, first section "Default static >>>> Group-to-RP mapping with dynamically learned entries", add >>>> a sentence to the end: >>>> >>>> This is not an issue for IPv6 Multicast address ranges. >>>> >>>> 3. In section 8, "Clarification for MIB Objects", I'm not >>>> sure what we have to say to be sure its understood that this >>>> is a normative reference. Suggestions ? >>>> >>>> 4. Section 5, Common use cases, remove the subsection "More use >>>> cases". >>>> >>>> Bharat, please spin a new version with these changes when we >>>> resolve number 3 above. >>>> >>>> Thanks, >>>> >>>> Andy >>>> >>>> -----Original Message----- >>>> From: Brian E Carpenter [mailto:[email protected]] >>>> Sent: Saturday, December 18, 2010 11:54 AM >>>> To: Andy Kessler (kessler) >>>> Cc: [email protected]; General Area >>> Review Team; Bharat Joshi; Stig Venaas; Mike McBride (mmcbride) >>>> Subject: Re: Gen-ART LC review of draft-ietf-pim-group-rp-mapping- >>> 07.txt >>>> Hi Andy, thanks for responding so promptly. A few comments in line: >>>> >>>> >>>> On 2010-12-18 18:36, Andy Kessler (kessler) wrote: >>>>> Hi, >>>>> >>>>> Thank you for the review. >>>>> My comments are below annotated with Andy> >>>>> >>>>> Andy >>>>> >>>>> >>>>> I am the assigned Gen-ART reviewer for this draft. For background on >>>>> Gen-ART, please see the FAQ at >>>>> <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>. >>>>> >>>>> Please resolve these comments along with any other Last Call >>> comments >>>>> you may receive. >>>>> >>>>> Document: draft-ietf-pim-group-rp-mapping-07.txt >>>>> Reviewer: Brian Carpenter >>>>> Review Date: 2010-12-18 >>>>> IETF LC End Date: 2010-12-23 >>>>> IESG Telechat date: >>>>> >>>>> Summary: In good shape, a few issues. >>>>> -------- >>>>> >>>>> Major issues: >>>>> ------------- >>>>> >>>>> 3. Existing algorithm >>>>> ... >>>>> The algorithm defined in this document updates algorithm defined >>> in >>>>> PIM-SM ( Section 4.7.1 in [RFC4601]). The new algorithm is >>> backward >>>>> compatible and will produce the same result only if the Group-to- >>> RP >>>>> mappings are learned from a single mapping source. >>>>> >>>>> A logical implication of the last sentence is that if some of the >>> Group-to-RP >>>>> mappings are learned from more than one mapping source, the new >>> algorithm might >>>>> not produce the same result as the existing algorithm. Is that >>> indeed the case, >>>>> and if so, don't we have a problem until all PIM-SM routers have >>> been updated? >>>>> Andy> Most vendors today do not officially support deployments with >>> multiple >>>>> Andy> dynamic routing protocols. They probably have inconsistent >>> results now. >>>>> Andy> This algorithm will standardize the results for those vendors. >>> It will >>>>> Andy> be more consistent when all vendors do support the new >>> algorithm. >>>> OK. Maybe you could add a sentence to make it clear that adding the >>> new >>>> algorithm doesn't fix the problem completely until it's universally >>> deployed. >>>>> 5. Common use cases >>>>> >>>>> o Default static Group-to-RP mappings with dynamically learned >>>>> entries >>>>> >>>>> Many network operators will have a dedicated infrastructure for >>> the >>>>> standard multicast group range (224/4) and so might be using >>>>> statically configured Group-to-RP mappings for this range. >>>>> >>>>> Please indicate whether this issue also applies to IPv6. >>>>> >>>>> Andy> There is no issue with IPv6. IPv4 has some older baggage >>> because >>>>> Andy> the 224/4 addressing scheme has been around since before there >>> was >>>>> Andy> SSM and BSR. IPv6 Multicast does not have that history. >>>> OK. For someone ignorant of the history, it might be worth adding >>>> "This issue does not arise for IPv6." >>>> >>>>> >>>>> 6. Proposed algorithm >>>>> ... >>>>> 10. From the remaining set of Group-to-RP Mappings we will >>> select >>>>> the RP with the highest IP address. This will serve as a >>> final >>>>> tiebreaker. >>>>> >>>>> Please define "highest". Does it mean "greatest when considered as >>> an >>>>> unsigned integer"? >>>>> >>>>> Andy> This should be the same method that is used to pick >>>>> Andy> the highest IP address in many protocols. One I know well is >>>>> Andy> the way that a designated router is selected in RFC 4601 in >>>>> Andy> section 4.3.2. The main part of the function says: >>>>> Andy> a.primary_ip_address > b.primary_ip_address >>>>> Andy> To me that has always meant you compare the first byte, >>>>> Andy> then the 2nd, the 3rd and then the 4th. >>>> and the 5th, etc, for IPv6 ;-) >>>> >>>>> Andy> I don't know where that would be defined. Maybe someone else >>> knows. >>>>> Andy> It is not defined in RFC 4601. >>>> I have no idea either. Maybe it's a term of art in routing protocols, >>>> so I won't insist; I was just looking at it from the viewpoint >>>> of a naive implementor. >>>> >>>>> 8. Clarification for MIB Objects >>>>> >>>>> When a Group-to-RP mapping entry is created in the >>>>> pimGroupMappingTable in the PIM-STD MIB[RFC5060], it would be >>>>> acceptable to have an entry with an RP with address type >>> 'unknown' >>>>> and a PimMode of Dense Mode or SSM. These entries would >>> represent >>>>> group ranges for Dense mode or SSM. >>>>> >>>>> Also all the entries which are already included in the SSM Range >>>>> table in the IP Mcast MIB would be copied over to >>>>> pimGroupMappingTable. They would have a type of configSSM and an >>> RP >>>>> with address type 'unknown' as described above. >>>>> >>>>> Is this section intended to be a normative update of RFC 5060, or is >>>>> it just commentary? The phrase "it would be acceptable" almost >>> sounds >>>>> like a normative MAY. >>>>> >>>>> Also, shouldn't it be 'unknown(0)' in the context of the MIB? (This >>>>> applies in three places in the draft.) >>>>> >>>>> Andy> At some point we received comments and requests to include all >>>>> Andy> the group mappings in this table - even for Dense Mode or SSM >>>>> Andy> which do not have an RP. We are merely stating that it OK to >>>>> Andy> do that and use the RP address and type (of the RP) of >>> unknown. >>>> Yes, it makes sense, but please make it very clear whether you >>>> are writing normatively or not. >>>> >>>>> Nits: >>>>> ----- >>>>> >>>>> 5. Common use cases >>>>> ... >>>>> o More use cases >>>>> >>>>> By no means, the above list is complete. Please drop a mail to >>>>> 'authors' if you see any other use case for this. >>>>> >>>>> This seems a bit strange to appear in the final RFC; at the least it >>> needs rewriting. >>>>> Andy> I agree. That was for the draft and should be removed. Should >>> we >>>>> Andy> just remove the whole section ? Or change the wording to >>> somehow >>>>> Andy> say there are more use cases that will benefit from this >>> algorithm ? >>>> Either way is fine for me. >>>> >>>>> The checker says: >>>>> >>>>> == There are 1 instance of lines with multicast IPv4 addresses in >>> the >>>>> document. If these are generic example addresses, they should >>> be changed >>>>> to use the 233.252.0.x range defined in RFC 5771 >>>>> >>>>> Andy> We have discussed this before. We need to use the addresses >>> that in the >>>>> Andy> examples. 239/8 is the Administratively Scoped Block as >>> defined in RFC 5771. >>>>> Andy> Its the same thing for 239.100.0.0/16 in section 5. We were >>> told to add >>>>> Andy> the comment that says its an administratively scoped multicast >>> address >>>>> Andy> range. Using GLOP will not make the same point we are trying >>> to explain. >>>> Fair enough. Don't be surprised if someone in the IESG asks the same >>> question. >>>> Brian >> **************** CAUTION - Disclaimer ***************** >> This e-mail contains PRIVILEGED AND CONFIDENTIAL INFORMATION intended >> solely >> for the use of the addressee(s). If you are not the intended recipient, >> please >> notify the sender by e-mail and delete the original message. Further, you >> are not >> to copy, disclose, or distribute this e-mail or its contents to any other >> person and >> any such actions are unlawful. This e-mail may contain viruses. Infosys has >> taken >> every reasonable precaution to minimize this risk, but is not liable for any >> damage >> you may sustain as a result of any virus in this e-mail. You should carry >> out your >> own virus checks before opening the e-mail or attachment. Infosys reserves >> the >> right to monitor and review the content of all messages sent to or from this >> e- >> mail >> address. Messages sent to or from this e-mail address may be stored on the >> Infosys e-mail system. >> ***INFOSYS******** End of Disclaimer ********INFOSYS*** > > _______________________________________________ Gen-art mailing list [email protected] https://www.ietf.org/mailman/listinfo/gen-art
