Re: [Idr] Shepherd report on draft-ietf-idr-eag-distribution

Jeff Tantsura <jefftant.ietf@gmail.com> Fri, 13 November 2020 19:13 UTC

Return-Path: <jefftant.ietf@gmail.com>
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 93D2F3A106C; Fri, 13 Nov 2020 11:13:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, 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 MI8JxkVYTcWM; Fri, 13 Nov 2020 11:12:58 -0800 (PST)
Received: from mail-pf1-x432.google.com (mail-pf1-x432.google.com [IPv6:2607:f8b0:4864:20::432]) (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 D651A3A1065; Fri, 13 Nov 2020 11:12:58 -0800 (PST)
Received: by mail-pf1-x432.google.com with SMTP id v12so8396497pfm.13; Fri, 13 Nov 2020 11:12:58 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:message-id:in-reply-to:references:subject:mime-version; bh=JMTm3AMDPuZzkPa7kXQ4sGQuxtFcutvzdpm5Z2bzMgU=; b=RnNEZF/lMh28TTkVrNtskEma15+6wM61UErnoddCwB3MdA6iVAcTpTMwCqazWGyrUF 4WV2dDNFX+UQ+LbwXe6rN6v54CkeyQfJjcHiieeAKll/r0qmx1pPniDdpMlDPMZKq3Bb jRQ0pcMP83t2PNXaOzH/93eDvZJxX3MxQpvLGW7w/IuzxilVW5kBw+bVxV8GZkANr8Qc 7OpTUj45uqaWGVBRAa4a5hpk2VlgGZpaLXY0giPKT+46lIIU46MNeAAkRMJMapAN0Q9R 0Lz5Z5lOuvLhdmGKDehNRm9eMC9UJmQC6GglnWnoRxkVnvdOS+NXHmICDcRYM3ewEX2Z XeXA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:message-id:in-reply-to:references :subject:mime-version; bh=JMTm3AMDPuZzkPa7kXQ4sGQuxtFcutvzdpm5Z2bzMgU=; b=ERPTcR+tKvEhEo7QWFKgSsMOZJh26MLR0bUcTQJuy9ztaOMuOwh0tKZGBvGDjY9dxG a2A7v1+4UlZC+Eo+pwtQ3uxzNrvvi0PzzxII73PjkaoLHOWsywn/Ra8vpczxBPLplqns +4p+GT4oRn+UtjSraXA/dn1prtV+8gPV9rxlaWr3SWw9HSoY9snsKP1LA4dQOGFThkX8 3vPmf8IgRqdXeDSoYtn+KcqujvhK8ZtLSDMm4W7E6shGtmPWaBz8vzCxAYSFigyHC6L+ 0UazkngQDVTyCh7eTFA6uTRbsTSr7a2dWPUR/HA2wulrlWLGogvGbgYyUtxJVdiEgs1q aB+g==
X-Gm-Message-State: AOAM531I6i/rB3icRrD64IYONOOi563B1J+mKZ7IPekdLHJb8HZTWV/F SMsFnuva6CQo3KX0tLYTyrlr/fSZOt4=
X-Google-Smtp-Source: ABdhPJymUhhE+2KCP8SNj7W3XhEhNxgc+gQ2PrJeMCzRN85iMSy1dlxz2DX7GQnl4BIe2llZxa9HsQ==
X-Received: by 2002:aa7:9abb:0:b029:195:2f0d:755d with SMTP id x27-20020aa79abb0000b02901952f0d755dmr2707643pfi.28.1605294776542; Fri, 13 Nov 2020 11:12:56 -0800 (PST)
Received: from [192.168.1.7] (c-73-63-232-212.hsd1.ca.comcast.net. [73.63.232.212]) by smtp.gmail.com with ESMTPSA id u10sm10669183pfn.101.2020.11.13.11.12.55 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 13 Nov 2020 11:12:55 -0800 (PST)
Date: Fri, 13 Nov 2020 11:12:49 -0800
From: Jeff Tantsura <jefftant.ietf@gmail.com>
To: idr@ietf.org, draft-ietf-idr-eag-distribution@ietf.org, Susan Hares <shares@ndzh.com>
Message-ID: <d1407cb4-e8a9-4daf-9ec3-d27273186d29@Spark>
In-Reply-To: <02e101d6b928$f83b3af0$e8b1b0d0$@ndzh.com>
References: <02e101d6b928$f83b3af0$e8b1b0d0$@ndzh.com>
X-Readdle-Message-ID: d1407cb4-e8a9-4daf-9ec3-d27273186d29@Spark
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="5faedab6_66ef438d_ba5e"
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/OB536M0464UH4KBttj0ozISF_Dw>
Subject: Re: [Idr] Shepherd report on draft-ietf-idr-eag-distribution
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/idr/>
List-Post: <mailto:idr@ietf.org>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 13 Nov 2020 19:13:01 -0000

Hi Sue,

Many thanks for your review and comments.
The authors will happily use them in the updated version of the document which will be published ASAP.

Thanks!

Cheers,
Jeff
On Nov 12, 2020, 11:21 AM -0800, Susan Hares <shares@ndzh.com>om>, wrote:
> Status: Ready with 2 issues plus 2 editorial changes
>
> 1) Abstract:
> Why: IESG wishes succinct abstracts.
> Type: Editorial
> Required/optional:   Optional, authors choice
>
> Old text:/
>    Administrative groups (commonly referred to as "colors" or "link
>    colors") are link attributes that are advertised by link state
>    protocols like IS-IS (Intermediate System to Intermediate System) and
>    OSPF (Open Shortest Path First) and used for traffic engineering.
>    These administrative groups have initially been defined as a fixed-
>    length 32-bit bitmask.  As networks grew and more use-cases were
>    introduced, the 32-bit length was found to be constraining and hence
>    extended administrative groups were introduced in the link state
>    protocols.  The 32-bit administrative groups are already advertised
>    as link attributes in BGP-LS (Border Gateway Protocol Link-State).
>    This document defines extensions to BGP-LS for advertisement of the
>    extended administrative groups./
>
> shorter text:
>    /Administrative Groups are link attributes (commonly referred to as
>   "colors" or link colors") advertised by link state protocols
>   (e.g. ISIS or OSPF) and used for traffic engineering.  These administrative
>   groups were initially defined as 32 bit masks.  As network usage grew,
>   these 32 bit masks were found to constrain traffic engineering.
>   Therefore, link state protocols (ISIS, OSPF) were expanded to advertise
>   a variable length administrative group.
>
>    This document defines extensions to BGP-LS for advertisement of the
>    Extended administrative groups./
>
>
> 2)  Error handling added to section 2
>
>      Location:  section 2 paragraph 2, line that specifies length.
>     Type: error handling issue
>     change: required
>
> old:/
>       Length: variable (MUST be multiple of 4); represents the total
>       length of the value field in octets.
>      /
>
>
> new:/length:  variable length which represents the total length of the
>                         value field. The length value must MUST be multiple of 4.
>                         If the length is not a multiple of 4, the TLV must be considered
>                        malformed.
>  /
>
> 3) Typographical error – Section 2
>    Status:  optional, but recommended
>
>   Old:/Value :/
>    New:/Value:/
>
> 4) Security considerations
>     status: issue, required change
>
>    Old:/
>    The extensions in this document advertise same administrative group
>    information specified via [RFC7752] but as a larger/extended value
>    and hence does not introduce security issues beyond those discussed
>    in [RFC7752].
>     /
>
>     New:/
>    The extensions in this document advertise same administrative group
>    information specified via [RFC7752] but as a larger/extended value
>    and hence does not introduce security issues beyond those discussed
>    in [RFC7752] and [RFC7752bis].
>   /
>
> Please list [RFC7752bis] as an informative reference.
>
>