Re: [Isis-wg] AD review of draft-ietf-isis-mi-bis-01

Uma Chunduri <uma.chunduri@huawei.com> Mon, 20 March 2017 17:30 UTC

Return-Path: <uma.chunduri@huawei.com>
X-Original-To: isis-wg@ietfa.amsl.com
Delivered-To: isis-wg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D55A4131540; Mon, 20 Mar 2017 10:30:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.221
X-Spam-Level:
X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LG08jbwLF3M9; Mon, 20 Mar 2017 10:30:38 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 269EA131560; Mon, 20 Mar 2017 10:29:33 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml701-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DJF91366; Mon, 20 Mar 2017 17:29:30 +0000 (GMT)
Received: from SJCEML702-CHM.china.huawei.com (10.208.112.38) by lhreml701-cah.china.huawei.com (10.201.108.42) with Microsoft SMTP Server (TLS) id 14.3.301.0; Mon, 20 Mar 2017 17:29:28 +0000
Received: from SJCEML701-CHM.china.huawei.com ([169.254.3.8]) by SJCEML702-CHM.china.huawei.com ([169.254.4.233]) with mapi id 14.03.0235.001; Mon, 20 Mar 2017 10:29:19 -0700
From: Uma Chunduri <uma.chunduri@huawei.com>
To: "Acee Lindem (acee)" <acee@cisco.com>, Alia Atlas <akatlas@gmail.com>, "Les Ginsberg (ginsberg)" <ginsberg@cisco.com>
CC: "draft-ietf-isis-mi-bis@ietf.org" <draft-ietf-isis-mi-bis@ietf.org>, "isis-wg@ietf.org" <isis-wg@ietf.org>
Thread-Topic: [Isis-wg] AD review of draft-ietf-isis-mi-bis-01
Thread-Index: AQHSoAhu03+V1fi3M0Gyqxr2JPkZjaGd+t5A
Date: Mon, 20 Mar 2017 17:29:18 +0000
Message-ID: <25B4902B1192E84696414485F5726854018886AC@SJCEML701-CHM.china.huawei.com>
References: <D4F2D32F.A3554%acee@cisco.com>
In-Reply-To: <D4F2D32F.A3554%acee@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.213.49.150]
Content-Type: multipart/alternative; boundary="_000_25B4902B1192E84696414485F5726854018886ACSJCEML701CHMchi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020203.58D0117B.0295, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.3.8, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32
X-Mirapoint-Loop-Id: f274c07edf6f82a9f04a3890396317d7
Archived-At: <https://mailarchive.ietf.org/arch/msg/isis-wg/-UJs89bf8xT1lYxLKYJiiIuwzrc>
Subject: Re: [Isis-wg] AD review of draft-ietf-isis-mi-bis-01
X-BeenThere: isis-wg@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: IETF IS-IS working group <isis-wg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/isis-wg>, <mailto:isis-wg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/isis-wg/>
List-Post: <mailto:isis-wg@ietf.org>
List-Help: <mailto:isis-wg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/isis-wg>, <mailto:isis-wg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 20 Mar 2017 17:30:42 -0000

Hi Acee,

Quick replies in-line [Uma]:
Thx!
--
Uma C.

From: Acee Lindem (acee) [mailto:acee@cisco.com]
Sent: Saturday, March 18, 2017 9:55 AM
To: Uma Chunduri <uma.chunduri@huawei.com>om>; Alia Atlas <akatlas@gmail.com>om>; Les Ginsberg (ginsberg) <ginsberg@cisco.com>
Cc: draft-ietf-isis-mi-bis@ietf.org; isis-wg@ietf.org
Subject: Re: [Isis-wg] AD review of draft-ietf-isis-mi-bis-01

Hi Uma,

As a WG Chair, there have been instances where authors that were not actively participating in the WG at the time of the BIS requested to be retained as authors. In these cases, we usually retained them on the condition that they reviewed the draft and responding promptly to IPR and RFC editor queries.
In some cases, this resulted in more than 5 authors but it was easy to get a dispensation. However, in other cases, the original authors were no longer actively participating in the WG and didn't really care.
Another consideration is whether there is an overlap of authors from original and whether the overlap includes those who did the lion's share of the work on the original document.
[Uma]: I get that and I see that's  immaterial on the broader point..
If this is the case, than I don't see a requirement to retain all the original authors.
[Uma]: We don't know what is the case here, as there is no discussion in the list.

Please note that my observations are general and not specific to this draft or any other draft.
[Uma]: ... and my comments were too in general and not particularly for this draft (happened to notice the conversation and looked at both documents in detail).

Thanks,
Acee



From: Isis-wg <isis-wg-bounces@ietf.org<mailto:isis-wg-bounces@ietf.org>> on behalf of Uma Chunduri <uma.chunduri@huawei.com<mailto:uma.chunduri@huawei.com>>
Date: Friday, March 17, 2017 at 8:29 PM
To: Alia Atlas <akatlas@gmail.com<mailto:akatlas@gmail.com>>, "Les Ginsberg (ginsberg)" <ginsberg@cisco.com<mailto:ginsberg@cisco.com>>
Cc: "draft-ietf-isis-mi-bis@ietf.org<mailto:draft-ietf-isis-mi-bis@ietf.org>" <draft-ietf-isis-mi-bis@ietf.org<mailto:draft-ietf-isis-mi-bis@ietf.org>>, "isis-wg@ietf.org<mailto:isis-wg@ietf.org>" <isis-wg@ietf.org<mailto:isis-wg@ietf.org>>
Subject: Re: [Isis-wg] AD review of draft-ietf-isis-mi-bis-01

Hi Alia,

Thx for your response.
In-line [Uma]:
--
Uma C.

From: Alia Atlas [mailto:akatlas@gmail.com]
Sent: Friday, March 17, 2017 1:51 PM
To: Les Ginsberg (ginsberg) <ginsberg@cisco.com<mailto:ginsberg@cisco.com>>
Cc: Uma Chunduri <uma.chunduri@huawei.com<mailto:uma.chunduri@huawei.com>>; isis-wg@ietf.org<mailto:isis-wg@ietf.org>; draft-ietf-isis-mi-bis@ietf.org<mailto:draft-ietf-isis-mi-bis@ietf.org>
Subject: Re: AD review of draft-ietf-isis-mi-bis-01

To clarify further, it is most common for the authors to be retained in a bis draft.
[Uma]: This is what I generally see in other WGs..

However, if they are unresponsive (which can cause process problems) or it causes the author list (which is really more active editors) to grow too long, then an acknowledgements section is appropriate.
[Uma]: Possible, but I see your "if" clause..

In this case, where there are active authors who were also on RFC 6822, I assume
that appropriate discussions have happened.
[Uma]: I didn't remember any discussion on this..


Regards,
Alia


On Fri, Mar 17, 2017 at 4:34 PM, Alia Atlas <akatlas@gmail.com<mailto:akatlas@gmail.com>> wrote:
Uma,

Les has already said it.  It is common to have a section that mentions and thanks the authors of the original RFC when a bis version is done with different authors.

Keeping the previous authors can cause issues for reviews and approvals later on.

Regards,
Alia

On Fri, Mar 17, 2017 at 4:05 PM, Les Ginsberg (ginsberg) <ginsberg@cisco.com<mailto:ginsberg@cisco.com>> wrote:
Uma -

I am not aware of any requirement to have the original set of authors be authors of a bis document - and there are certainly other examples where authorship has changed. And there are obvious practical reasons why authorship may change.

The authors of the bis draft are the ones who actively participated in the writing of the bis draft. The fact that some of the authors of RFC 6822 did not participate in the writing of the bis draft  in no way diminishes their past contributions which are permanently recorded in RFC 6822.

I'll let Alia take it from here from an official IETF process standpoint.

   Les


From: Uma Chunduri [mailto:uma.chunduri@huawei.com<mailto:uma.chunduri@huawei.com>]
Sent: Friday, March 17, 2017 11:45 AM

To: Les Ginsberg (ginsberg); Alia Atlas; isis-wg@ietf.org<mailto:isis-wg@ietf.org>; draft-ietf-isis-mi-bis@ietf.org<mailto:draft-ietf-isis-mi-bis@ietf.org>
Subject: RE: AD review of draft-ietf-isis-mi-bis-01

Les,

Thx for the clarification.

I too agree on this (couldn't notice this earlier more thoroughly..) and in that case why original authors were completely replaced with new set of folks as opposed to adding?

W.r.t. this, why we how to do this differently while numerous other WGs just do the addition and the ratified changes to the original document.

My view is we need not be different here but would be happy to listen from you, AD and other esteemed members of this group.

--
Uma C.

From: Les Ginsberg (ginsberg) [mailto:ginsberg@cisco.com]
Sent: Friday, March 17, 2017 11:30 AM
To: Uma Chunduri <uma.chunduri@huawei.com<mailto:uma.chunduri@huawei.com>>; Alia Atlas <akatlas@gmail.com<mailto:akatlas@gmail.com>>; isis-wg@ietf.org<mailto:isis-wg@ietf.org>; draft-ietf-isis-mi-bis@ietf.org<mailto:draft-ietf-isis-mi-bis@ietf.org>
Subject: RE: AD review of draft-ietf-isis-mi-bis-01

Uma -

I agree w Alia's evaluation that this replaces RFC 6822.

   Les


From: Uma Chunduri [mailto:uma.chunduri@huawei.com]
Sent: Friday, March 17, 2017 11:15 AM
To: Les Ginsberg (ginsberg); Alia Atlas; isis-wg@ietf.org<mailto:isis-wg@ietf.org>; draft-ietf-isis-mi-bis@ietf.org<mailto:draft-ietf-isis-mi-bis@ietf.org>
Subject: RE: AD review of draft-ietf-isis-mi-bis-01

>4) In the IANA considerations, the references should be updated to point to this document, and most particularly if it obsoletes RFC 6822.
>[Les:] Agreed. I did not think I had to state that - I assumed IANA would just do that - but I am happy to add a line in IANA section stating that all references to RFC 6822 should be updated to point to this document.

Quick comment:

Currently document says it updates 6822 - which is correct?

-          I can guess but want to hear author thoughts..


--
Uma C.

From: Isis-wg [mailto:isis-wg-bounces@ietf.org] On Behalf Of Les Ginsberg (ginsberg)
Sent: Friday, March 17, 2017 10:57 AM
To: Alia Atlas <akatlas@gmail.com<mailto:akatlas@gmail.com>>; isis-wg@ietf.org<mailto:isis-wg@ietf.org>; draft-ietf-isis-mi-bis@ietf.org<mailto:draft-ietf-isis-mi-bis@ietf.org>
Subject: Re: [Isis-wg] AD review of draft-ietf-isis-mi-bis-01

Alia -

Thanx for meticulous review.
Inline.

From: Alia Atlas [mailto:akatlas@gmail.com]
Sent: Friday, March 17, 2017 8:47 AM
To: isis-wg@ietf.org<mailto:isis-wg@ietf.org>; draft-ietf-isis-mi-bis@ietf.org<mailto:draft-ietf-isis-mi-bis@ietf.org>
Subject: AD review of draft-ietf-isis-mi-bis-01

As is customary, I have done my AD review of draft-ietf-isis-mi-bis-01.  First, I would like to thank the authors - Les, Stefano, and Wim - for their work on this document.

I do have a few minor issues that need to be fixed ASAP.   I will, however, go ahead and issue a 3 week IETF Last Call for it so that, if the authors act promptly, it can be on the April 13 telechat.


1) This draft pretty clearly should obsolete RFC 6822, but the header claims to merely
update it.

[Les:] OK

 2) Sec 2.6.2: " Point-to-point adjacency setup MUST be done through the use of the
         three-way handshaking procedure as defined in [RFC5303] in order to
         prevent a non-MI capable neighbor from bringing up an adjacency
         prematurely based on reception of an IIH with an IID-TLV for a non-
         zero instance."
     While obviously the 3-way handshake in RFC5303 is fine, given that different MAC addresses are used, I don't see how a non-MI capable neighbor would receive and process an IIH with an IID-TLV where IID != 0.

[Les:] Section 2.6.2 is only talking about true pt-pt media - hence MAC multicast addresses are not relevant. In Section 2.6.1 we discuss the case of operating in Pt-Pt mode on a broadcast circuit:

"When operating in point-to-point mode on a broadcast circuit
   [RFC5309]..."


3) In Appendix A:" Clarification that the IID-TLV is only included in Pt-Pt IIHs
   associated with non-zero instances has been added.  This addresses
   Errata ID #4519."
   In Sec 2.6.2, it says "The presence or absence of the IID-TLV in an IIH indicates that the
   neighbor does or does not support this extension, respectively.
   Therefore, all IIHs sent on a point-to-point circuit by an MI-RTR
   MUST include an IID-TLV.  This includes IIHs associated with IID #0." which is a direct
   contradiction and needed since the IID-TLV is used as a capability indication.  The
   simplest solution is to remove the claim from the Appendix.
[Les:] Again, you are confusing Pt-Pt media with Pt-Pt operation on a Broadcast media. Errata 4519 is concerned with Pt-Pt operation on a LAN - and some modest clarifications in Section 2.6.1 were made to more completely cover the latter case.
In the Pt-Pt operation on a LAN case it IS illegal to send IID-TLV in hellos for the zero instance - which Section 2.6.1 explicitly states.

Perhaps the Appendix should say:

"Clarification that when operating in point-to-point mode on a broadcast circuit the IID-TLV is only included in Pt-Pt IIHs
   associated with non-zero instances has been added. .."

Will this address your concern?

4) In the IANA considerations, the references should be updated to point to this document, and most particularly if it obsoletes RFC 6822.

[Les:] Agreed. I did not think I had to state that - I assumed IANA would just do that - but I am happy to add a line in IANA section stating that all references to RFC 6822 should be updated to point to this document.


Let me know if the above changes will suffice and I will spin a new version.

   Les

Regards,
Alia