Hi, thanks for the response. Comments inline: > On Dec 20, 2017, at 5:35 PM, Les Ginsberg (ginsberg) <[email protected]> > wrote: > > Ben - > > Thanx for the review. > V14 has been published and it attempts to address the Security concerns. > Look forward to your feedback.
It’s not clear to me how the new version addresses Adam’s major comment or Alissa’s second DISCUSS point. But it’s probably best to discuss those points directly with Adam and Alissa. […] >> >> >> ---------------------------------------------------------------------- >> COMMENT: >> ---------------------------------------------------------------------- >> >> Substantive Comments: >> >> - I support Alissa's discuss and Adam's major comment. >> >> - Requirements Language: There are lower case instances of 2119 keywords. >> Unless you mean for those to also be normative, please use the boilerplate >> from RFC 8174. >> >> -3.1.1, last paragraph: Why are the SHOULDs not MUSTs? >> > [Les:] Failure to do the validation will result in the packet being dropped > when it reaches a node which does not support the algorithm i.e., the > algorithm specific label will not match any installed incoming label. This is > sub-optimal but not fatal - hence SHOULD rather than MUST. Do you think that would ever be a reasonable implementation choice? If so, it would help to add a sentence or two about the consequences into the text. > >> -12.2: The citations to the following references seem to be used normatively: >> I-D.ietf-6man-segment-routing-header >> I-D.ietf-isis-segment-routing-extensions >> I-D.ietf-ospf-ospfv3-segment-routing-extensions >> I-D.ietf-ospf-segment-routing-extensions >> > [Les:] I respectfully disagree. > The architecture document is NOT dependent upon the IGP/6man documents - the > dependency is the other way around. > The referenced documents are useful for readers who wish to better understand > how the architecture is supported by routing protocols/IPv6 - but there is no > dependency that the architecture definition has on the implementation > specifics. A reference is normative if reading it is necessary to understand or implement this draft. I-D.ietf-6man-segment-routing-header is referenced several times in the security considerations section in a way that seems to make the security considerations incomplete unless you read that. The other 3 seem necessary to implement IGP segment advertising as described in section 3. […]
signature.asc
Description: Message signed with OpenPGP
_______________________________________________ spring mailing list [email protected] https://www.ietf.org/mailman/listinfo/spring
