Hello Dave For some reason I only see this now. Very sorry!
> > > A PDF with my comments inline is on my OneDrive share at: > > https://onedrive.live.com/?cid=DC2B364F3F06FEA8&id=DC2B364F3F06FEA8%21522413&parId=DC2B364F3F06FEA8%21522414&o=OneUp I could not open the link > > Summary: > * Overall the document is well written and readable > > * Section 2.3 has a nice list of acronyms but many acronyms are in the > document > that are not listed in that section > * Many typos and grammatical errors exist, as noted throughout my marked > up copy Hopefully a number were fixed! > * It is unclear whether a prefix can be a multicast prefix or not. For > example, in Table 1 in the discussion of updating > RFC 8505, the table has separate values for unicast, anycast, and > multicast, > but only one value for prefix. The idea is only unicast prefixes. But the way it's done, as you point out, is not extensible. Do you think there's an operational need for registering multicast prefixes? > * There are a number of uses of "should" that would be better as "SHOULD" > or "MUST" depending on the intent. Will review that * Section 7.3's use of a 112 bit prefix is confusing given that the field > length is 120 bits not 112 bits. Where does the number 112 come from? A glitch I guess! Fixed > * Section 7.4 talks about the case where "it determined that the 6LBR is > legacy and does not support this specification" but it does not explain how > a 6LR can determine this. Elaborate. This is section 5. I'll add an xref > * draft-ietf-6lo-multicast-registration is used normatively so should be a > Normative, not Informative, reference > > done Due to cutoff today, I'll post with the fixes I could make and will work on the pdf after IETF 120. Many thanks for your review! all the best; -- Pascal
_______________________________________________ 6lo mailing list -- 6lo@ietf.org To unsubscribe send an email to 6lo-le...@ietf.org
