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
