Les,

This works for me.

        Thanks,
        Paul

On 1/3/16 10:53 PM, Les Ginsberg (ginsberg) wrote:
Paul -

Attached is a diff file w the changes I have made to address your comments. 
Please let me know if this suffices.

(co-authors - please let me know if you have any concerns regarding the 
proposed changes)

Thanx.

    Les


-----Original Message-----
From: Paul Kyzivat [mailto:pkyzi...@alum.mit.edu]
Sent: Sunday, January 03, 2016 12:49 PM
To: Les Ginsberg (ginsberg); draft-ietf-isis-prefix-attributes....@ietf.org
Cc: General Area Review Team
Subject: Re: Gen-ART Last Call review of draft-ietf-isis-prefix-attributes-03

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



_______________________________________________
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

Reply via email to