Subject: [Bier] Adam Roach's Discuss on draft-ietf-bier-isis-extensions-07: (with DISCUSS and COMMENT)

From: Adam Roach <[email-masked]>
Date: Wed, 21 Feb 2018 20:53:58 -0800

Adam Roach has entered the following ballot position for
draft-ietf-bier-isis-extensions-07: Discuss

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-isis-extensions/

----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

I think we have a process problem here.

This document (Standards Track) makes normative references to RFC 8279
(Experimental) and RFC 8296 (Experimental), neither of which appear in the
downref registry. My understanding of the rules defined in RFC 3967 is that
these downreferences need to be explicitly called out in the IETF last call
announcement so that the community can discuss whether such downreferences are
acceptable. Unless the last call text in the datatracker doesn't match the text
sent to the IETF discussion list, this document needs to run through IETF LC
again with these downrefs explicitly called out before it can move forward.

This also raises the question of whether *this* document should be Experimental
rather than Standards Track, as it appears to be defining an extension that is
used exclusively for enabling experimental specifications. This would fix the
downref problem, but I'm not sure whether it requires another Last Call.

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

I support EKR's discuss position.

§6.1:

>   BAR  BIER Algorithm. 0 is the only supported value defined in this
>      document.  Other values may be defined in the future. 8 bits

I expected to find a registry for this in the IANA section. Does some other
document establish this registry? If so, is 0 already registered? If "no" and
"no", then this document needs to do both. If "yes" and "no", then this
document need to register "0". If "yes" and "yes", then the phrase "in this
document" needs to be replaced by "in [RFCxxxx]".

>   subdomain-id:  Unique value identifying the BIER sub-domain. 1 octet

You need to scope "Unique" (e.g. "Value identifying the BIER sub-domain, unique
within the domain.")

>   Local BitString Length (BS Len):  Encoded bitstring length as per
>      [RFC8296]. 4 bits.
>
>   Max SI  Maximum Set Identifier (section 1 of [RFC8279]) used in the
>      encapsulation for this BIER sub-domain for this bitstring length,
>      1 octet.  Each SI maps to a single label in the label range.  The
>      first label is for SI=0, the second label is for SI=1, etc.

This is a bit confusing, since the fields appear in the opposite order from
this in the diagram. Would recommend re-ordering to match.

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Thu, 22 Feb 2018 07:14:18 +0000

Adam -

Thanx for the review.

> -----Original Message-----
> From: Adam Roach [mailto:[email-masked]]
> Sent: Wednesday, February 21, 2018 8:54 PM
> To: The IESG <[email-masked]>
> Cc: [email-masked]; Hooman Bidgoli
> <[email-masked]>; [email-masked];
> [email-masked]; [email-masked]
> Subject: Adam Roach's Discuss on draft-ietf-bier-isis-extensions-07: (with
> DISCUSS and COMMENT)
> 
> 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.)
> 
> 
> announcement so that the community can discuss whether such
> downreferences are acceptable. Unless the last call text in the datatracker
> doesn't match the text sent to the IETF discussion list, this document needs
> to run through IETF LC again with these downrefs explicitly called out before
> it can move forward.
> 

[Les:] The reference issues have been corrected in the soon to be published next version.

> This also raises the question of whether *this* document should be
> Experimental rather than Standards Track, as it appears to be defining an
> extension that is used exclusively for enabling experimental specifications.
> This would fix the downref problem, but I'm not sure whether it requires
> another Last Call.
>

[Les:] This issue has already been addressed by Alia. Please see the attached email.

   Les

> You need to scope "Unique" (e.g. "Value identifying the BIER sub-domain,
> unique within the domain.")
> 
> This is a bit confusing, since the fields appear in the opposite order from this
> in the diagram. Would recommend re-ordering to match.
> 

Subject: Re: Mirja Kühlewind's No Objection on draft-ietf-bier-isis-extensions-07: (with COMMENT)
From: Alia Atlas <[email-masked]>
To: Mirja Kühlewind <[email-masked]>
Cc: The IESG <[email-masked]>, BIER WG <[email-masked]>, "[email-masked]" <[email-masked]>, "Bidgoli, Hooman (Nokia - CA/Ottawa)" <[email-masked]>, "[email-masked]" <[email-masked]>
Date: Mon, 19 Feb 2018 14:54:56 +0000

On the status, we're also starting the BIER recharter this telechat - to move the work from
Experimental to Standards Track. The WG has wanted the work to be Standards Track from the beginning.

Regards,
Alia

On Mon, Feb 19, 2018 at 9:50 AM, Mirja Kühlewind <[email-masked]<mailto:[email-masked]>> wrote:
Mirja Kühlewind has entered the following ballot position for
draft-ietf-bier-isis-extensions-07: No Objection

1) Minor comment: The shepherd write-up says wrongly that this docoment is
experimental. Assume that was changed at some point during the process.

2) There further seem to be unaddressed comments in the write-up...

3) Please use rfc8174 boilerplate.

4) The IANA section should contain the exact name and URL of the registry that
the new sub-TLV value should be addd to.

5) The document should maybe provide further guidance on how the stated goal in
the security  considerations section could be achieved.