Subject: [Sidrops] Alvaro Retana's Yes on draft-ietf-sidrops-ov-clarify-04: (with COMMENT)

From: Alvaro Retana <[email-masked]>
Date: Mon, 13 Aug 2018 09:28:49 -0700

Alvaro Retana has entered the following ballot position for
draft-ietf-sidrops-ov-clarify-04: Yes

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-sidrops-ov-clarify/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Thanks for the clarifications!!   I have just a couple of comments:

(1) §3: "...the router SHOULD use the AS of the router's BGP configuration". 
If not ambiguous, when would it be ok to not use the ASN from the local
configuration?  IOW, why SHOULD and not MUST?

(2) §1: s/the origin validation state of the is set to as NotFound/the origin
validation state is set to NotFound

(3) [nit] The language in the Introduction is very tentative for a Standards
Track document.  For example: "This document attempts to clarify...The
implementation issues seem not to be about how to validate...The issues seem to
be ..."  Either this document clarifies or it doesn't; IOW, this is not an
attempt at clarification.  Also, I'm sure the issues are known.

---

From: Randy Bush <[email-masked]>
Date: Mon, 13 Aug 2018 12:22:53 -0500

> (1) §3: "...the router SHOULD use the AS of the router's BGP
> configuration".  If not ambiguous, when would it be ok to not use the
> ASN from the local configuration?  IOW, why SHOULD and not MUST?

ok.  hacked.

> (2) §1: s/the origin validation state of the is set to as NotFound/the
> origin validation state is set to NotFound

yep.  someone already dinged me on this one

> (3) [nit] The language in the Introduction is very tentative for a
> Standards Track document.  For example: "This document attempts to
> clarify...The implementation issues seem not to be about how to
> validate...The issues seem to be ..."  Either this document clarifies
> or it doesn't; IOW, this is not an attempt at clarification.

i am willing to harden the language.  but this would seem to need
support in the wg.  your call.

> I'm sure the issues are known.

well, not if you ask your account rep :)

will not push -05 until a few more comments come in.

thanks for the review!

randy