Subject: [Bier] Alvaro Retana's No Objection on draft-ietf-bier-mvpn-09: (with COMMENT)

From: Alvaro Retana <[email-masked]>
Date: Tue, 06 Feb 2018 12:22:25 -0800

Alvaro Retana has entered the following ballot position for
draft-ietf-bier-mvpn-09: No Objection

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-bier-mvpn/

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

[I am balloting No Objection, and not DISCUSS [1], because I think this comment
is very easy to address.]

The reference to draft-ietf-bess-mvpn-expl-track (EXPLICIT_TRACKING) should be
Normative because of the use of the LIR-pF flag in this document.

[1] https://www.ietf.org/iesg/statement/discuss-criteria.html#stand-disc

---

From: Eric C Rosen <[email-masked]>
Date: Tue, 6 Feb 2018 15:35:53 -0500

> Normative because of the use of the LIR-pF flag in this document.

Alvaro,

The use of the LIR-pF flag in the bier-mvpn document is optional. That's 
why I thought the reference to the explicit tracking draft should be 
informational.  The mandatory features of the bier-mvpn document can be 
implemented without any understanding of the LIR-pF mechanism.

Is that reasoning incorrect?

Eric

---

From: Alvaro Retana <[email-masked]>
Date: Tue, 6 Feb 2018 17:02:25 -0500

On February 6, 2018 at 3:36:03 PM, Eric C Rosen ([email-masked]) wrote:

Eric:

Hi!

Even if the use is optional, the document specifies its use when it is
utilized.  To me, that is what makes it Normative.

Thanks!

Alvaro.

---

From: Eric C Rosen <[email-masked]>
Date: Wed, 7 Feb 2018 10:07:58 -0500

> utilized.  To me, that is what makes it Normative.

There are many RFCs where the dependencies of optional features are not 
normative references.

Can you point to a BCP that supports your interpretation?

---

From: Eric C Rosen <[email-masked]>
Date: Wed, 7 Feb 2018 11:54:22 -0500

Just to provide a bit more context ...

I think there will be implementations of bier-mvpn before there are any 
implementations of mvpn-expl-track.  When mvpn-expl-track goes for last 
call, someone is bound to object that it should be held until there is 
an implementation.  If mvpn-expl-track is a normative reference of 
bier-mvpn, then bier-mvpn will have to wait on the RFC Editor's queue 
until there is an implementation of one of its optional features.  This 
doesn't seem appropriate.

I also don't want to go through the overhead of separating bier-mvpn 
into two drafts, one specifying the mandatory features and one 
specifying the optional feature.  That seems like it would just be a 
waste of everyone's time.

That is why I am pushing back against your request to make 
mvpn-expl-track a normative reference of bier-mvpn.

On 2/6/2018 5:02 PM, Alvaro Retana wrote:
> On February 6, 2018 at 3:36:03 PM, Eric C Rosen ([email-masked] 
> <mailto:[email-masked]>) wrote:
>
> Eric:
>
> Hi!
>

---

From: Alvaro Retana <[email-masked]>
Date: Wed, 7 Feb 2018 12:23:31 -0800

On February 7, 2018 at 10:08:05 AM, Eric C Rosen ([email-masked]) wrote:

I can point to the IESG Statement about Normative and Informative
References: https://www.ietf.org/iesg/statement/normative-informative.html

Two relevant pieces of text from that statement:

"Normative references specify documents that must be read to understand or
implement the technology in the new RFC, or whose technology must be
present for the technology in the new RFC to work.”

"Even references that are relevant only for optional features must be
classified as normative if they meet the above conditions for normative
references."