Subject: [Isis-wg] Adam Roach's Discuss on draft-ietf-isis-l2bundles-05: (with DISCUSS and COMMENT)

From: Adam Roach <[email-masked]>
Date: Tue, 23 May 2017 20:29:47 -0700

Adam Roach has entered the following ballot position for
draft-ietf-isis-l2bundles-05: 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-isis-l2bundles/

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

Blocking Issue 1: I am truly concerned that the shepherd's write up
implies that there has been a failure by some authors to comply with IETF
IPR rules laid out in BCP 79. I do not believe the IETF can publish a
document under such circumstances.

Blocking Issue 2: This document is at odds with BCP 72, and is
inappropriate for publication with its current security considerations
section.

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

If the Discuss objections I lay out can be addressed, I plan to abstain
for the many of the same reasons Mirja cites in her abstention. I find
the shepherd's write-up to contain an alarming number of red flags
indicating a lack of WG consensus and, lack of proper review by parties
who should be involved, claims that operator input has been ignored (for
a routing protocol no less), and indication that IPR disclosures have not
apparently been brought to the WG's attention.

These overarching process problems seem large enough that any comments I
may have on actual content -- such as an apparent lack of IPv6 support
(or, at least, a complete omission of IPv6 from the examples) -- would
seem like rearranging deck chairs on the Titanic.

---

From: Alia Atlas <[email-masked]>
Date: Wed, 24 May 2017 08:10:22 -0400

Adam,

First, I would greatly appreciate it if you and others could read the
ballot write-up.  I did
try to explain what I did to mitigate the concerns in the shepherd's
write-up; as far as I
can tell, this is a case of one person being in the rough.

> https://datatracker.ietf.org/doc/draft-ietf-isis-l2bundles/

As far as the IPR declarations go, I have asked the two authors that didn't
declare their
knowledge of IPR to do so.  Ebben has already done so.  I expect Clarence
will as well;
he also works with and at the same company as another author; I do not have
active concern.
This is part of a process that we do in Routing, where each author is asked
to confirm that
all IPR has been disclosed at  WGLC.  It is not an indication that IPR
rules have been
violated.  It's a process that we've added in Routing to help remind folks.

> inappropriate for publication with its current security considerations

Yes, this should at least have the same common text as other ISIS documents.
Sorry I missed this - I was focused on other aspects.

Please read my write-up - which I did spend time on to explain some of these
aspects.   The existing IPR claim - by a non-author- was brought up to the
WG
and very briefly discussed, as is typical.

> seem like rearranging deck chairs on the Titanic.

If you have specific technical concerns, they are, of course, easier to
just deal with
at the same time.  The document does, of course, support IPv6 - as is
clearly indicated
in Section 2.1 where, for instance,  use of " IPv6 Interface Address
(sub-TLV 12
defined in [RFC6119])" is mentioned.  The appendix doesn't include an IPv6
example,
but the primary purpose there is to explain the complex sub-TLV structuring
since
the standard bit-fields ascii art was challenging to do in a meaningful way.

Regards,
Alia

______________________________________________

> Isis-wg mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/isis-wg
>

---

From: Adam Roach <[email-masked]>
Date: Wed, 24 May 2017 12:28:01 -0500

> can tell, this is a case of one person being in the rough.

Thanks for the pointer. For clarity, the person you're describing as "in 
the rough" is the document shepherd, right?

For avoidance of doubt: I did read both the shepherd's write-up and the 
ballot write-up prior to entering my position. The problem I'm running 
into is that the explanations in the ballot writeup seem to be 
contradictions rather than clarifications. For example, the shepherd's 
answer to question (9) paints a different picture than the "clear WG 
consensus to publish" in the ballot writeup.

> aspects.   The existing IPR claim - by a non-author- was brought up to 
> the WG

Thanks for the clarification; "briefly discussed" disagrees with the 
answer in the shepherd's writeup: "no WG discussion around IPR." I do 
see that the Ericsson disclosure was posted to the list on May 12, 2016; 
and a number of assertions in June of 2016 that other individuals were 
unaware of additional IPR, but I find no emails that directly contradict 
the shepherd's assertion, so I must be missing the "brief discussion" 
you refer to. Do you have a pointer? Note that I don't consider this 
lack of discussion to be blocking in and of itself, but it does add to 
the "this smells kind of funny" situation around this draft.

I concede that many of the issues I'm seeing may be the result of a 
reluctant shepherd rather than actual process issues. Is there a chance 
we could get a different shepherd assigned (e.g., the other ISIS chair)? 
In addition to noting that the current shepherd, if opposed to the 
document in the way that is being implied, is unlikely to be proactive 
in moving it forward, I think shepherd-writeup-style input from a 
different party who was involved in the working group during the 
progression of this document would be very helpful in clearing the air here.

> If you have specific technical concerns, they are, of course, easier 
> to just deal with
> defined in [RFC6119])" is mentioned.  The appendix doesn't include an 
> IPv6 example,
> but the primary purpose there is to explain the complex sub-TLV 
> structuring since

Well, they're more editorial than technical, since IS-IS is a bit 
outside of my wheelhouse. If the draft moves forward, I would like to 
see the IPv4 examples use addresses from the RFC5737 blocks, and perhaps 
an alternation between IPv4 and IPv6 in the examples.

/a

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Wed, 24 May 2017 18:28:18 +0000

Hi Adam, and other esteemed IESG members,

As an aside, please note that the missing WGLC IPR declarations have been posted to the ISIS WG list since the shepherd’s report.

https://mailarchive.ietf.org/arch/msg/isis-wg/Du-FujLleUPhkSbo_Ud00rvVEi4

https://mailarchive.ietf.org/arch/msg/isis-wg/hQGriZR12khwiX7NR53lJULqwWk

Thanks,
Acee

From: Isis-wg <[email-masked]<mailto:[email-masked]>> on behalf of Adam Roach <[email-masked]<mailto:[email-masked]>>
Date: Wednesday, May 24, 2017 at 1:28 PM
To: Alia Atlas <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, The IESG <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Isis-wg] Adam Roach's Discuss on draft-ietf-isis-l2bundles-05: (with DISCUSS and COMMENT)

First, I would greatly appreciate it if you and others could read the ballot write-up.  I did
try to explain what I did to mitigate the concerns in the shepherd's write-up; as far as I
can tell, this is a case of one person being in the rough.

Thanks for the pointer. For clarity, the person you're describing as "in the rough" is the document shepherd, right?

For avoidance of doubt: I did read both the shepherd's write-up and the ballot write-up prior to entering my position. The problem I'm running into is that the explanations in the ballot writeup seem to be contradictions rather than clarifications. For example, the shepherd's answer to question (9) paints a different picture than the "clear WG consensus to publish" in the ballot writeup.

Please read my write-up - which I did spend time on to explain some of these
aspects.   The existing IPR claim - by a non-author- was brought up to the WG
and very briefly discussed, as is typical.

Thanks for the clarification; "briefly discussed" disagrees with the answer in the shepherd's writeup: "no WG discussion around IPR." I do see that the Ericsson disclosure was posted to the list on May 12, 2016; and a number of assertions in June of 2016 that other individuals were unaware of additional IPR, but I find no emails that directly contradict the shepherd's assertion, so I must be missing the "brief discussion" you refer to. Do you have a pointer? Note that I don't consider this lack of discussion to be blocking in and of itself, but it does add to the "this smells kind of funny" situation around this draft.

I concede that many of the issues I'm seeing may be the result of a reluctant shepherd rather than actual process issues. Is there a chance we could get a different shepherd assigned (e.g., the other ISIS chair)? In addition to noting that the current shepherd, if opposed to the document in the way that is being implied, is unlikely to be proactive in moving it forward, I think shepherd-writeup-style input from a different party who was involved in the working group during the progression of this document would be very helpful in clearing the air here.

If you have specific technical concerns, they are, of course, easier to just deal with
at the same time.  The document does, of course, support IPv6 - as is clearly indicated
in Section 2.1 where, for instance,  use of " IPv6 Interface Address (sub-TLV 12
defined in [RFC6119])" is mentioned.  The appendix doesn't include an IPv6 example,
but the primary purpose there is to explain the complex sub-TLV structuring since
the standard bit-fields ascii art was challenging to do in a meaningful way.

Well, they're more editorial than technical, since IS-IS is a bit outside of my wheelhouse. If the draft moves forward, I would like to see the IPv4 examples use addresses from the RFC5737 blocks, and perhaps an alternation between IPv4 and IPv6 in the examples.

/a