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 >> >> >> >> >> >> >> >> >> >> > >
- [OSPF] AD review of draft-ietf-ospf-node-admin-ta… Alia Atlas
- Re: [OSPF] AD review of draft-ietf-ospf-node-admi… Alia Atlas
- Re: [OSPF] AD review of draft-ietf-ospf-node-admi… Acee Lindem (acee)
- Re: [OSPF] AD review of draft-ietf-ospf-node-admi… Acee Lindem (acee)
- Re: [OSPF] AD review of draft-ietf-ospf-node-admi… Shraddha Hegde
- Re: [OSPF] AD review of draft-ietf-ospf-node-admi… Alia Atlas
- Re: [OSPF] AD review of draft-ietf-ospf-node-admi… Acee Lindem (acee)
- Re: [OSPF] AD review of draft-ietf-ospf-node-admi… Alia Atlas
- Re: [OSPF] AD review of draft-ietf-ospf-node-admi… Acee Lindem (acee)
- Re: [OSPF] AD review of draft-ietf-ospf-node-admi… Shraddha Hegde