Les, Changes look good to me.
New year wishes to all. -- Uma C. -----Original Message----- From: Les Ginsberg (ginsberg) [mailto:ginsb...@cisco.com] Sent: Sunday, January 03, 2016 7:54 PM To: Paul Kyzivat; 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 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
