Hi Les, The modification looks fine to me.
Best regards, Xiaohu > -----Original Message----- > From: Les Ginsberg (ginsberg) [mailto:[email protected]] > Sent: Monday, January 04, 2016 11:54 AM > To: Paul Kyzivat; [email protected] > 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:[email protected]] > > Sent: Sunday, January 03, 2016 12:49 PM > > To: Les Ginsberg (ginsberg); > > [email protected] > > 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 [email protected] https://www.ietf.org/mailman/listinfo/gen-art
