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

Alia Atlas <akatlas@gmail.com> Fri, 17 March 2017 20:34 UTC

Return-Path: <akatlas@gmail.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 80FBF129533; Fri, 17 Mar 2017 13:34:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.698
X-Spam-Level:
X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 pZYzfLEctjI8; Fri, 17 Mar 2017 13:34:30 -0700 (PDT)
Received: from mail-wm0-x235.google.com (mail-wm0-x235.google.com [IPv6:2a00:1450:400c:c09::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7A7C312952E; Fri, 17 Mar 2017 13:34:29 -0700 (PDT)
Received: by mail-wm0-x235.google.com with SMTP id n11so24086001wma.1; Fri, 17 Mar 2017 13:34:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=eA03y2U9OLINxA1qxMuUQNSHhQI5KyBENXOjjKsR0mE=; b=Ge8u/d3RX1vXaApb81aEAb2tCAy/hAPC+9o8GYHGhgc+6dfhFvVjWzzWSZ1aOvg7tR XLr4tIdRxWNYGu1tTNlb1tHWX0XrxMNiPvW63UlpsKXYWP1HOXQ9T/3/x8MUDp49ahLk OEKTE/UhT3HPir6ATLRuKPtFhVuY6OVoEbvXOXE2EIBgLr+n0LBvP723yQ7+CI0itwE0 HVLQfILVv2D7G78V+35RHQo/KBhcEBomxnLXOFxcJ7KT/7M+1wcWcLnMj3gl5PbYewBW O6Dky+R+t69UVdgHF0M/3wWih+nookpOF2Nc/OzLgrPzO/TL6vyIaoc4ERFWELGnS1Ks 5cRw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=eA03y2U9OLINxA1qxMuUQNSHhQI5KyBENXOjjKsR0mE=; b=NEdFCGHavIkgXi/1Pvf5b5wK91NEsxGuhOfvAS8+I05MNeHNaLVjyAyoiSxEz30yXz +d1dn/rKCFOvRPoy+ejnmUHteXLcllcnus33kBbU3gtMMyi5iefiXUOo3mY6uM9d/QN1 X6Rs0G3jOHIOBGtscGBLCkuDNuz2h1DoWxFOfnWBQH3/fpmzxS3Rmda64o9v0OTIS0kf zT1ZLnwYSz5fwD9r+BDtViedbcQrAHGayz03Oz7+10SiE2ChjFkgjpCHnbyp9CgDpuDN p8Q9/G3BUCWJmQ9Rlu/6neBk6v1U2lNXKCJ08EP0f+Pts7fK2cE2wZ997kRdswcYeLqr HP4w==
X-Gm-Message-State: AFeK/H1BDZok8GaOv86bDBhjjmn/viVY9txoqO8oEvhFUjDY5hvB9bh8rtcsReiVmBVUtwDlv+p33E457hzoVw==
X-Received: by 10.28.50.6 with SMTP id y6mr117941wmy.112.1489782867560; Fri, 17 Mar 2017 13:34:27 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.223.145.69 with HTTP; Fri, 17 Mar 2017 13:34:26 -0700 (PDT)
In-Reply-To: <66747b32bd0a4bb5a920736eca0b491a@XCH-ALN-001.cisco.com>
References: <CAG4d1reSNUyDZwUN1tB4zJAJcfs40618_x5DpFofr99cQc3B0g@mail.gmail.com> <43be9b6ac3fa41708303a2a352360ab4@XCH-ALN-001.cisco.com> <25B4902B1192E84696414485F572685401886050@SJCEML703-CHM.china.huawei.com> <d35ee990ce104caaad61bd389c941dc4@XCH-ALN-001.cisco.com> <25B4902B1192E84696414485F57268540188607C@SJCEML703-CHM.china.huawei.com> <66747b32bd0a4bb5a920736eca0b491a@XCH-ALN-001.cisco.com>
From: Alia Atlas <akatlas@gmail.com>
Date: Fri, 17 Mar 2017 16:34:26 -0400
Message-ID: <CAG4d1rfr=2x9Mf6aH5uudMuRXbiE7nt6j_DmY+tCTmYvTAG5Jg@mail.gmail.com>
To: "Les Ginsberg (ginsberg)" <ginsberg@cisco.com>
Cc: Uma Chunduri <uma.chunduri@huawei.com>, "isis-wg@ietf.org" <isis-wg@ietf.org>, "draft-ietf-isis-mi-bis@ietf.org" <draft-ietf-isis-mi-bis@ietf.org>
Content-Type: multipart/alternative; boundary=001a1140dc569d125d054af31a4f
Archived-At: <https://mailarchive.ietf.org/arch/msg/isis-wg/J-IOCbkO5z4wb0ttVffS0I_Mpkc>
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: Fri, 17 Mar 2017 20:34:32 -0000

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
> 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]
> *Sent:* Friday, March 17, 2017 11:45 AM
>
> *To:* Les Ginsberg (ginsberg); Alia Atlas; isis-wg@ietf.org;
> 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
> <ginsberg@cisco.com>]
> *Sent:* Friday, March 17, 2017 11:30 AM
> *To:* Uma Chunduri <uma.chunduri@huawei.com>om>; Alia Atlas <
> akatlas@gmail.com>gt;; isis-wg@ietf.org; 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
> <uma.chunduri@huawei.com>]
> *Sent:* Friday, March 17, 2017 11:15 AM
> *To:* Les Ginsberg (ginsberg); Alia Atlas; isis-wg@ietf.org;
> 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
> <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>om>; isis-wg@ietf.org;
> 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 <akatlas@gmail.com>]
> *Sent:* Friday, March 17, 2017 8:47 AM
> *To:* isis-wg@ietf.org; 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
>