Re: [Gen-art] Gen-ART Last Call review of draft-ietf-isis-prefix-attributes-03

Paul Kyzivat <pkyzivat@alum.mit.edu> Sun, 03 January 2016 20:49 UTC

Return-Path: <pkyzivat@alum.mit.edu>
X-Original-To: gen-art@ietfa.amsl.com
Delivered-To: gen-art@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C96B1A01A4 for <gen-art@ietfa.amsl.com>; Sun, 3 Jan 2016 12:49:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.165
X-Spam-Level:
X-Spam-Status: No, score=0.165 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=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 BLYkuAiih6IA for <gen-art@ietfa.amsl.com>; Sun, 3 Jan 2016 12:49:07 -0800 (PST)
Received: from resqmta-po-11v.sys.comcast.net (resqmta-po-11v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:170]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2111F1A0187 for <gen-art@ietf.org>; Sun, 3 Jan 2016 12:49:07 -0800 (PST)
Received: from resomta-po-03v.sys.comcast.net ([96.114.154.227]) by resqmta-po-11v.sys.comcast.net with comcast id 1Yp61s0024ueUHc01Yp6xZ; Sun, 03 Jan 2016 20:49:06 +0000
Received: from Paul-Kyzivats-MacBook-Pro.local ([73.218.51.154]) by resomta-po-03v.sys.comcast.net with comcast id 1Yp51s00C3KdFy101Yp5Yj; Sun, 03 Jan 2016 20:49:06 +0000
To: "Les Ginsberg (ginsberg)" <ginsberg@cisco.com>, "draft-ietf-isis-prefix-attributes.all@ietf.org" <draft-ietf-isis-prefix-attributes.all@ietf.org>
References: <56818AED.8090909@alum.mit.edu> <d4b8085a5e4c4087adfa44c0e8fbc4b4@XCH-ALN-001.cisco.com> <56843F07.4000606@alum.mit.edu> <fbac0b22d4f247abb6f88f47a0aeaf10@XCH-ALN-001.cisco.com>
From: Paul Kyzivat <pkyzivat@alum.mit.edu>
Message-ID: <56898941.8030804@alum.mit.edu>
Date: Sun, 03 Jan 2016 15:49:05 -0500
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.5.0
MIME-Version: 1.0
In-Reply-To: <fbac0b22d4f247abb6f88f47a0aeaf10@XCH-ALN-001.cisco.com>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 7bit
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1451854146; bh=EDzsHSONn4WP+7Pk3to/us5dGhvZQkS2fypIycgGK18=; h=Received:Received:Subject:To:From:Message-ID:Date:MIME-Version: Content-Type; b=WNmc8PittbY/HZrZUWClk+zXXr0+hvXriiekpMMVB13FZG4jq8rkktZXE4YObT/NS w1HUxcyMHmK1Jl8KLbGNvq0vcASrPYOcQH55DAf2lgMwuAhsKvRfNocsdjTSNAEObX F80ePxRCmcOoO2+nbBR1HIwPI50Bzhv+W3LqqZr8qchGW2rx9jVoFdQLvot2A8AYTr KPkdvZ+zF54FQqgfs/7UNIdQoUGM8kAadXr98ZHHHasRqplc4R7qfaCY74c1VD1Zl6 FU/aYe1SiC8fxpsmwOqTH6ZLaKEeYSnbbGPX6J9LpkjcwFMGdclysNswNsybCxkSAI aBhyoR/FvMVOw==
Archived-At: <http://mailarchive.ietf.org/arch/msg/gen-art/KMrbRJ-qfMAWcNxw4iqDANO-N_k>
Cc: General Area Review Team <gen-art@ietf.org>
Subject: Re: [Gen-art] Gen-ART Last Call review of draft-ietf-isis-prefix-attributes-03
X-BeenThere: gen-art@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "GEN-ART: General Area Review Team" <gen-art.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/gen-art>, <mailto:gen-art-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/gen-art/>
List-Post: <mailto:gen-art@ietf.org>
List-Help: <mailto:gen-art-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/gen-art>, <mailto:gen-art-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 03 Jan 2016 20:49:08 -0000

Hi Les,

Trimming to the relevant points:

On 1/3/16 9:27 AM, Les Ginsberg (ginsberg) wrote:

>> Note that at the end of the day my comments are just suggestions. You can
>> act on them or not. They only become binding if the IESG decides to raise
>> them.
>
> [Les:] I want you to know that I take your comments seriously - binding or not. You obviously invested time in reviewing - which I appreciate.

Thanks. Genart is educational for the reviewers (at least for me) 
because we are usually reviewing things we know nothing about! It often 
takes some sniffing around to gain enough context to do the review.

But I think that is the point of genart - to get a review from somebody 
who doesn't already know the subject.

>> Understood. But the abstract will be seen by many (like me) who don't fall
>> into that category. They are left entirely in the dark about what this is about.
>> Might it be something they *ought* to be interested in?
>> After reading the abstract, the only clue I had about the scope of this
>> document was the name of the wg from the draft name. And once this
>> becomes an RFC that won't be available as a hint. I had to look up isis in the
>> list of WGs to discover that this was in the routing area. Then I had to do
>> more searching to figure out what IS-IS was about.
>>
>
> [Les:] The title (even once it becomes an RFC) includes "IS-IS".  If you don't know that IS-IS is a routing protocol, do you think that further clarification is needed to help you understand that this isn't something which you are interested in reading?

It is sufficient to get people to stop reading and ignore it. Maybe that 
is enough.

But for the person who goes a step further and pulls the full document 
and still doesn't know, it would be nice to add an informative reference 
to the intro, to a base document for IS-IS. As best I can tell, the 
likely one is RFC1195. For example, revise the first sentence of the intro:

    There are existing use cases for IS-IS [RFC1195] in which knowing
    additional attributes of a network prefix is useful.

>>> In regards to the term "prefix", you seem to be expecting the document to
>> define that term - but in looking at multiple RFCs I do not see precedent for
>> that. It is part of the base knowledge that has been assumed that readers
>> understand . Perhaps this is a bad practice - but if so there are many
>> documents - not restricted solely to IS-IS related documents - that could be
>> critiqued on this basis. I would ask that this comment be viewed in a larger
>> context - I don't think this particular draft should be asked to deviate from
>> common practice without larger guidance from the IETF community.
>>
>> Not a definition, just a disambiguation. Simply replacing "prefix" with
>> "network prefix" would have met my need.
>>
>
> [Les:] You are proposing that "prefix" be replaced by "network prefix" throughout the document?
> This has not been done in any of the existing RFCs that I checked.

Not everywhere, just one or a few places - say in the abstract and the 
intro.

>>> In regards to "references to the Introduction", I emphasize that the
>> Introduction is neither normative nor exhaustive. It is meant to provide some
>> examples of cases where the information contained in the new
>> advertisements could be useful. I therefore find that references to it would
>> be inappropriate.
>>
>> I guess I wasn't clear. I was suggesting that reference(s) be added to the
>> introduction. (References are not permitted in the abstract, but they are
>> allowed in the intro.) A reference to the base specification for the internet
>> version of IS-IS would have helped me.
>>
>
> [Les:] I usually constrain references to those which are actually useful in the context of the topics being discussed in the draft. Base specifications are not directly referenced in this draft because we are extending TLVs which were defined in RFCs issued long after the base specifications were published. However, the following could be added to the introduction:
>
> "IS-IS is a link state routing protocol defined in [ISO10589] and [RFC1195].  Extensions in support of advertising new forms of IP/IPv6 prefix reachability are defined in [RFC5305], [RFC5308], and [RFC5120]."
>
> Is this what you had in mind?

Yes.

	Thanks,
	Paul