Re: [OSPF] AD review of draft-ietf-ospf-node-admin-tag-04

Alia Atlas <akatlas@gmail.com> Thu, 24 September 2015 18:19 UTC

Return-Path: <akatlas@gmail.com>
X-Original-To: ospf@ietfa.amsl.com
Delivered-To: ospf@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 013691A1B66; Thu, 24 Sep 2015 11:19:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.999
X-Spam-Level:
X-Spam-Status: No, score=-101.999 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, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham
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 mNRDTFj8mup0; Thu, 24 Sep 2015 11:19:10 -0700 (PDT)
Received: from mail-oi0-x230.google.com (mail-oi0-x230.google.com [IPv6:2607:f8b0:4003:c06::230]) (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 772F61A1B64; Thu, 24 Sep 2015 11:19:10 -0700 (PDT)
Received: by oiev17 with SMTP id v17so45967674oie.1; Thu, 24 Sep 2015 11:19:10 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=7lPjlKsdgCBJ4hogqZZDftqFe4jrBwiLrfvvFlXfTQk=; b=zmM1vsIiPBA5TOhkxzCFyOhSeMwFVJ4euPhHDbIAg9ZPaiB9mIsxXwyCua3JcvxQD7 hdE3GINFJmL9ZXxmShDn+klVWqkfWsRhluD1KG/kjjZe7SViWySjeSGxtceXrYFx25oq XIkfOuU9HMmc0yezluLZxYDU/laB5bSgTkjF55Lykb7uYeSJcUP5aXPiwapovefNo105 qo1NqrZT9uYMf96V32EBkjcT4yKROb9Jxrim/fDQu89gAvNxrhFY/5c+xujMZ1jmh/f0 jowUSey6Mgm2f8fMQCWeS+5IwaECNnGW5x/qRMNzJe3w7axQcma/EVM6VEHM6lMyAusE rr/g==
MIME-Version: 1.0
X-Received: by 10.202.198.139 with SMTP id w133mr668012oif.72.1443118749879; Thu, 24 Sep 2015 11:19:09 -0700 (PDT)
Received: by 10.60.55.170 with HTTP; Thu, 24 Sep 2015 11:19:09 -0700 (PDT)
In-Reply-To: <A66D8806-EBA6-4ED8-A7A6-E8E248657BE8@cisco.com>
References: <CAG4d1rdCDNrk+Hn0SkSx1LeRfSUHr+LLSJ8LR-k5ui6WUm0h3A@mail.gmail.com> <CAG4d1rfOa9M8adSxocHka0wYL7wZbUP94ujGC9CW16QOiSBEfA@mail.gmail.com> <D2272216.30E2B%acee@cisco.com> <BY1PR0501MB13813D6AF5B739F98D9383E9D5430@BY1PR0501MB1381.namprd05.prod.outlook.com> <ABA2F0CE-A287-4F5D-963F-963292AEAEFD@gredler.at> <CAG4d1rdCPKTQE+bpXv3H_JPDe=pHJk4AD5YdUwDLpcPcOKCkUg@mail.gmail.com> <A66D8806-EBA6-4ED8-A7A6-E8E248657BE8@cisco.com>
Date: Thu, 24 Sep 2015 14:19:09 -0400
Message-ID: <CAG4d1rc-tzxLtk5Ti0DJDxpgC=X9T=hUYjS-51VF_PSTCe67ww@mail.gmail.com>
From: Alia Atlas <akatlas@gmail.com>
To: "Acee Lindem (acee)" <acee@cisco.com>
Content-Type: multipart/alternative; boundary="001a1134fbd674999405208244fa"
Archived-At: <http://mailarchive.ietf.org/arch/msg/ospf/i_WVJlqDqzgH3qkemOIXyH-Nn48>
Cc: Hannes Gredler <hannes@gredler.at>, OSPF List <ospf@ietf.org>, "draft-ietf-ospf-node-admin-tag@ietf.org" <draft-ietf-ospf-node-admin-tag@ietf.org>
Subject: Re: [OSPF] AD review of draft-ietf-ospf-node-admin-tag-04
X-BeenThere: ospf@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: The Official IETF OSPG WG Mailing List <ospf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ospf>, <mailto:ospf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ospf/>
List-Post: <mailto:ospf@ietf.org>
List-Help: <mailto:ospf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ospf>, <mailto:ospf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 24 Sep 2015 18:19:14 -0000

Hi Acee,

On Thu, Sep 24, 2015 at 2:14 PM, Acee Lindem (acee) <acee@cisco.com> wrote:

> Hi Alia, Hannes,
>
> On Sep 24, 2015, at 2:03 PM, Alia Atlas <akatlas@gmail.com> wrote:
>
> Hannes,
>
> On Thu, Sep 24, 2015 at 1:59 PM, Hannes Gredler <hannes@gredler.at> wrote:
>
>> i can be moved to contributors list as well if it helps.
>>
>
> Thanks - that would get us to 5 authors, which is the RFC Editor limit.
>
>
> Shraddha already moved one Juniper author to the contributors list.
> Perhaps, we could do a swap in the spirit of getting more new people
> involved.
>

Whatever works between the WG chairs and the authors.

Practically, having watched through many of these AUTH48 periods - they
> really
> drag on with lots of authors.
>
>
> Actually, my experience has been that BIS documents where the original
> authors are no longer following the IETF are the toughest. Greater than
> five authors has not been a problem for OSPF if they are all actively
> contributing and engaged (although I have had to contact one particular
> former colleague of yours and current colleague of mine via alternate
> channels ;^)
>

Yup - BIS documents are hard.  Responsiveness depends on the people.  Of
course, those involved in OSPF
are naturally more responsive;-)

Regards,
Alia



> Thanks,
> Acee
>
>
>
>
> Thanks,
> Alia
>
>
>
>> On 24.09.2015, at 19:27, Shraddha Hegde <shraddha@juniper.net> wrote:
>>
>> Alia,
>>
>>
>>
>> Thank you very much for the review and comments.
>>
>> I have updated the draft and draft-ietf-ospf-node-admin-tag-05 is posted.
>>
>>
>>
>> Authors list has been reduced to 6 and one author moved to contributor’s
>> list.
>>
>> Here is the list of other comments and resolutions
>>
>>
>>
>> 1) In the abstract: "This optional operational capability allows to
>>
>>    express and act upon locally-defined network policy which considers
>>
>>    node properties conveyed by tags."
>>
>>
>>
>>    What is the subject that "to express and act upon"?  Is it a router?
>>
>>    Please clean up.
>>
>> <Shraddha>changed  to
>>
>> “The node-tags can be used to express and apply locally-defined
>>
>> network policies which is a very useful operational capability.”
>>
>>
>>
>>
>>
>> 2) In Sec 3.2: "The TLV SHOULD be considered an unordered list."  Perhaps
>>
>>    "the value contents of the TLV" or something that makes it clearer?
>>
>> <Shraddha>Changed to
>>
>> “The administrative tag list within the TLV SHOULD be considered
>>
>> an unordered list.”
>>
>>
>>
>>
>>
>> 3) In Sec 4.3: " [RFC7490] proposed method of"  should be
>>
>>    "[RFC7490] defines a method of"
>>
>> <Shraddha> Updated
>>
>>
>>
>> 4) In Sec 5, I'm fairly certain that admin tags can leak additional
>>
>>    information to an IGP snooper.  It would be useful to have some
>> thoughts
>>
>>    about that.
>>
>> <Shraddha>
>>
>> Node admin tags may be used by operators to indicate geographical
>> location or other
>>
>> sensitive information.
>>
>> As indicated in <xref target="RFC2328"/> and <xref target="RFC5340"/>
>> OSPF authentication
>>
>> mechanisms do not provide  confidentiality and the information carried in
>> node admin tags could be leaked to an IGP
>>
>> snooper.
>>
>>
>>
>> 5) In IANA considerations, please duplicated the suggested value (10) that
>>
>>    was mentioned in Sec 3.1
>>
>>
>>
>> <Shraddha> Updated
>>
>>
>>
>> Rgds
>>
>> Shraddha
>>
>>
>>
>>
>>
>> *From:* Acee Lindem (acee) [mailto:acee@cisco.com <acee@cisco.com>]
>> *Sent:* Wednesday, September 23, 2015 1:01 AM
>> *To:* Alia Atlas <akatlas@gmail.com>; OSPF List <ospf@ietf.org>;
>> draft-ietf-ospf-node-admin-tag@ietf.org
>> *Subject:* Re: [OSPF] AD review of draft-ietf-ospf-node-admin-tag-04
>>
>>
>>
>> Thanks Alias - Speaking as Document Shepherd…
>>
>>
>>
>> Authors,
>>
>>
>>
>> Please let me know if you require any assistance - these all seem like
>> good comments.
>>
>>
>>
>> *From: *OSPF <ospf-bounces@ietf.org> on behalf of Alia Atlas <
>> akatlas@gmail.com>
>> *Date: *Tuesday, September 22, 2015 at 3:02 PM
>> *To: *OSPF WG List <ospf@ietf.org>, "
>> draft-ietf-ospf-node-admin-tag@ietf.org" <
>> draft-ietf-ospf-node-admin-tag@ietf.org>
>> *Subject: *Re: [OSPF] AD review of draft-ietf-ospf-node-admin-tag-04
>>
>>
>>
>>
>>
>>
>>
>> On Tue, Sep 22, 2015 at 2:58 PM, Alia Atlas <akatlas@gmail.com> wrote:
>>
>> As is customary, I have done my AD review of
>> draft-ietf-ospf-node-admin-tag-04
>>
>> before requesting IETF Last Call.
>>
>>
>>
>> First, I'd like to thank the working group and Shraddha, Harish, Hannes,
>> Rob,
>>
>> Anton, Zhenbin, and Bruno for their hard work on the draft.  However,
>> this short
>>
>> draft has 7 authors, which is a couple over the author limit for RFCs.
>> Experience
>>
>> has shown that it takes much longer to process a draft through AUTH48 and
>> the
>>
>> other steps necessary (responsiveness to comments, agreement, etc) with a
>> large
>>
>> number of authors.  While I am willing to be persuaded - on or off list -
>> that all 7
>>
>> of the current authors are actively editing, I would prefer that a
>> smaller number be
>>
>> selected as the active editors.
>>
>>
>>
>> In some cases, a draft represents a multi-vendor effort requiring a
>> significant commitment from more than 5 authors and I’d specifically
>> request a deviation from the author limit. I don’t see this to be the case
>> with this draft.
>>
>>
>>
>>
>>
>>
>>
>> While that discussion is ongoing, here are my technical comments.  In
>> general,
>>
>> the draft is in good shape but could use some English grammar editing; I
>> have not
>>
>> tried to indicate all the places where "the" is missing, for instance.
>>
>>
>>
>> 1) In the abstract: "This optional operational capability allows to
>>
>>    express and act upon locally-defined network policy which considers
>>
>>    node properties conveyed by tags."
>>
>>
>>
>>    What is the subject that "to express and act upon"?  Is it a router?
>>
>>    Please clean up.
>>
>>
>>
>> 2) In Sec 3.2: "The TLV SHOULD be considered an unordered list."  Perhaps
>>
>>    "the value contents of the TLV" or something that makes it clearer?
>>
>>
>>
>> 3) In Sec 4.3: " [RFC7490] proposed method of"  should be
>>
>>    "[RFC7490] defines a method of"
>>
>>
>>
>> 4) In Sec 5, I'm fairly certain that admin tags can leak additional
>>
>>    information to an IGP snooper.  It would be useful to have some
>> thoughts
>>
>>    about that.
>>
>>
>>
>> When you include this, be sure and point out the the attacker would also
>> require knowledge of the policies corresponding to the tags. I’d also point
>> out that the policies and advertised tags are local to the OSPF routing
>> domain as is done in RFC 5530.
>>
>>
>>
>> Thanks,
>>
>> Acee
>>
>>
>>
>>
>>
>> 5) In IANA considerations, please duplicated the suggested value (10) that
>>
>>    was mentioned in Sec 3.1
>>
>>
>>
>> Thanks again for the hard work.  The sooner we resolve whom the editors
>> are,
>>
>> the sooner this draft can proceed.  Ideally, if updated by Thursday, it
>> could enter
>>
>> IETF Last Call and make the IESG telechat on Oct 17.
>>
>>
>>
>> Oct 15 that is.
>>
>>
>>
>>
>>
>> Regards,
>>
>> Alia
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>
>