Hi I've now posted version 12 that addresses some of these points, please see comments inline. I hope that version 12 sufficiently addresses the review comments, and can be approved. On Tue, Jan 30, 2018 at 5:48 PM, Min Ye <amy.yemin@xxxxxxxxxx> wrote: > Reviewer: Papadimitriou Dimitri > Review result: Has Nits > > Couldn't find the template for experiment drafts, but I think this kind of > documents deserve its specific template > > Summary: > > Points to be clarified are related to > > 1.the flooding boundary. The document refers to PIM domain defined in RFC 4601 > > " A domain in this context is a contiguous set of routers that all implement > PIM and are > configured to operate within a common boundary." > > And states " PFM messages are generally forwarded hop by hop to all PIM > routers." > > what now defines a PIM domain: the PFM flooding boundary or the PIM execution > domain. The text you refer to is in the context of BSR where the domain is within the boundaries defined for BSR. Similarly for PFM it will be within the PFM boundaries. > 2. Modified TLV (statement " Some TLVs may be omitted or modified in the > forwarded message." - example a boundary router changes the Src Address in the > GSH TLV to its own address - is that allowed/expected ? actually the document > doesn't explain or justify the need to "modify" TLV in forwarded messages. Yes, we want to allow this. We do not want this for the GSH TLV, but new TLVs could be defined where this is needed. E.g., if we defined a TLV for source hop-count, or message hop-count, we might want the value to be increased by 1 each time a message is forwarded. > 3. Section 4.2 states > > "In order to meet the timing requirements, sending of the message may > have to be delayed a small amount of time." > > Quantify "small amount of time" I agree this is not very precise, but it is quantified in the timing requirements we are referring to. > Editorial: > > First paragraph first sentence: add reference to PIM-SM Fixed. > Second paragraph fifth sentence: add reference to SSM Fixed. > Last paragraph > > o) Refers to "parameters" please differentiate so-called architectural > constants from configurable parameters. Cf.RFC 2328 for a good example. I've done this. > o) Suggest to write last paragraph as numbered points to facilitate their > clearing as more experience from the field is being obtained. I thought about doing this, but I feel the points are fairly interconnected. It is all about scale and I do not see how we could say how one point is cleared and another is not. But hopefully at some point we have more experience and we can revise this in a bis document. Thanks for review, Stig > Dimitri >