>There's been some discussion of using pcount=0 to manage >some parts of this, but that would have to be covered in the >update validation and origination algorithm if we choose to >solve the problem that way.
The use of pcount=0 was hoped/expected to require NO changes in the update validation algorithm. If you have discovered places where it would require changes, it will indeed be interesting to see and discuss. --Sandy ________________________________________ From: [email protected] [[email protected]] on behalf of George, Wes [[email protected]] Sent: Tuesday, September 18, 2012 4:21 PM To: Murphy, Sandra; [email protected] Subject: Re: [sidr] WGLC for draft-ietf-sidr-bgpsec-protocol-05 Nits: Multiple sections have "musts" and "shoulds" that are not 2119-formatted (lower-case) - please ensure that this is intentional Substantial: Any reason why we're using "good" and "not good" for validation state instead of valid/invalid (and unknown)? I'd think that consistency between this and the language in the origin validation stuff would be helpful unless we have a specific reason not to use the same language. And I realize that there isn't really an "unknown" status as the result of trying to validate a BGPSec update, but as far as the implementation is concerned, standard BGP updates (those without BGPSec) are considered unknown, and it might be good to explicitly state that as a part of the validation algorithm. I'm awaiting co-author review of the I-D version of the email I wrote about AS-Migration, and am hoping to have it posted next week sometime. I think that we need to discuss the considerations from that issue to ensure that no changes need to be made in the protocol spec document/design before we progress this. There's been some discussion of using pcount=0 to manage some parts of this, but that would have to be covered in the update validation and origination algorithm if we choose to solve the problem that way. Also I'm not completely certain that pcount will solve the use case completely. I'm not opposed to using the draft as a follow-on to the protocol draft (update it) to handle this specific case, but I'd like to have WG consensus that this is the route we should take rather than incorporating any solution for this use case into the current document since it is still in draft. Thanks, Wes George > -----Original Message----- > From: [email protected] [mailto:[email protected]] On Behalf Of > Murphy, Sandra > Sent: Saturday, September 15, 2012 7:45 AM > To: [email protected] > Subject: [sidr] WGLC for draft-ietf-sidr-bgpsec-protocol-05 > > This starts a working group last call for draft-ietf-sidr-bgpsec- > protocol-05. The draft is available at > http://tools.ietf.org/html/draft-ietf-sidr-bgpsec-protocol-05 and > https://datatracker.ietf.org/doc/draft-ietf-sidr-bgpsec-protocol/ > > Please review this draft to see if you think it is ready for > publication. Send end comments to the list. > > The WGLC will end on 29 September 2012. > > --Sandy, speaking as wg co-chair > _______________________________________________ > sidr mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/sidr This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout. _______________________________________________ sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr _______________________________________________ sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
