Chris - > -----Original Message----- > From: Christian Hopps <cho...@chopps.org> > Sent: Thursday, April 05, 2018 7:32 AM > To: Les Ginsberg (ginsberg) <ginsb...@cisco.com> > Cc: Acee Lindem (acee) <a...@cisco.com>; firstname.lastname@example.org > Subject: Re: [Lsr] FW: New Version Notification for draft-ginsberg-isis- > rfc7810bis-00.txt > > > I think that the only time we should include the protocol (in addition to > '-lsr-') > is if we have split documents (for whatever reason) on the same solution. > We have an example of this actually: > > draft-ietf-isis-segment-routing-msd-09 > draft-ietf-ospf-segment-routing-msd-09 > > Going forward we either combine these types of documents into a single > document (discussion started @101) so "-lsr-" is appropriate, or if there's > some reason not to merge them then we have 2 documents that need the > protocol identifier to disambiguate. > > In this case there's no ambiguity so I don't see the need of adding an extra > "- > isis-". [Les:] RFC 7810 is IS-IS specific. There is a separate document for equivalent OSPF functionality (RFC 7471).
My point is - the reader should not have to go through the body of the document to find out that the document is specific to a particular protocol. The document name (which is preserved in the text even when it becomes an RFC) should make that clear. Les > > Thanks, > Chris. > > Les Ginsberg (ginsberg) <ginsb...@cisco.com> writes: > > > Well...this raises a topic on which I would like to have feedback from the > WG. > > > > Combining IS-IS/OSPF into one working group is fine - no argument there. > > But, we now may be producing two classes of documents: > > > > 1)Documents which are specific to a protocol (IS-IS or OSPFv2 or > > OSPFv3) > > > > 2)Documents which cover 2 or more protocols > > > > draft-ginsberg-isis-rfc7810bis-00.txt is Category #1 - and there is NO > CHANCE this document will EVER cover OSPF - since OSPF already has RFC > 7471 and this bis document is a correction to the IS-IS specific RFC7810. > Calling > it "-lsr-" to me is simply confusing as it in no way indicates that it is > IS-IS > specific. > > I suggest that any document which falls into Category 1 should continue to > follow the traditional protocol specific naming. > > If this somehow violates some IETF rule then I suppose we could use > > "-lsr-isis-". (somewhat verbose) > > > > For Category 2 documents "-lsr-" certainly makes sense. > > > > Comments?? > > > > Les > > > > > >> -----Original Message----- > >> From: Acee Lindem (acee) > >> Sent: Tuesday, April 03, 2018 7:45 AM > >> To: Les Ginsberg (ginsberg) <ginsb...@cisco.com>; email@example.com > >> Subject: Re: [Lsr] FW: New Version Notification for > >> draft-ginsberg-isis- rfc7810bis-00.txt > >> > >> Hi Les, > >> > >> Can you resubmit as draft-ginsberg-lsr-rfc7810bis-00.txt? Also, > >> please add a "Changes from RFC 7810" section to the "Introduction". I > >> see you have added > >> RFC8174 to the "Requirements Language" section already. > >> > >> I think we should accept this as an LSR Working Group document - does > >> anyone disagree? > >> > >> Thanks, > >> Acee > >> > >> On 3/30/18, 6:39 PM, "Lsr on behalf of Les Ginsberg (ginsberg)" > >> <lsr- boun...@ietf.org on behalf of ginsb...@cisco.com> wrote: > >> > >> Folks - > >> > >> A bis version of RFC 7810 has been submitted to address the issue > >> reported in Errata ID: 5293 > >> https://www.rfc-editor.org/errata_search.php?rfc=7810 > >> > >> Given that there exist implementations which have interpreted the > >> ambiguous encoding of some sub-TLVs in different/non-interoperable > >> ways it was felt that a bis version of the RFC was justified. > >> Please see the Appendix of the draft for a discussion of the > >> changes from RFC 7810 and the reasons why. > >> > >> Les > >> > >> > >> -----Original Message----- > >> From: internet-dra...@ietf.org <internet-dra...@ietf.org> > >> Sent: Friday, March 30, 2018 3:33 PM > >> To: Qin Wu <sunse...@huawei.com>; David Ward (wardd) > >> <wa...@cisco.com>; Spencer Giacolone > <spencer.giacal...@gmail.com>; > >> Spencer Giacalone <spencer.giacal...@gmail.com>; John Drake > >> <ldr...@juniper.net>; Les Ginsberg (ginsberg) <ginsb...@cisco.com>; > >> David Ward (wardd) <wa...@cisco.com>; Stefano Previdi > <stef...@previdi.net> > >> Subject: New Version Notification for > >> draft-ginsberg-isis-rfc7810bis-00.txt > >> > >> > >> A new version of I-D, draft-ginsberg-isis-rfc7810bis-00.txt > >> has been successfully submitted by Les Ginsberg and posted to the > >> IETF repository. > >> > >> Name: draft-ginsberg-isis-rfc7810bis > >> Revision: 00 > >> Title: IS-IS Traffic Engineering (TE) Metric Extensions > >> Document date: 2018-03-30 > >> Group: Individual Submission > >> Pages: 19 > >> URL: > >> https://www.ietf.org/internet-drafts/draft-ginsberg-isis- > >> rfc7810bis-00.txt > >> Status: https://datatracker.ietf.org/doc/draft-ginsberg-isis- > rfc7810bis/ > >> Htmlized: > >> https://tools.ietf.org/html/draft-ginsberg-isis-rfc7810bis- > 00 > >> Htmlized: > >> https://datatracker.ietf.org/doc/html/draft-ginsberg-isis- > >> rfc7810bis > >> > >> > >> Abstract: > >> In certain networks, such as, but not limited to, financial > >> information networks (e.g., stock market data providers), network- > >> performance criteria (e.g., latency) are becoming as critical to > >> data-path selection as other metrics. > >> > >> This document describes extensions to IS-IS Traffic Engineering > >> Extensions (RFC 5305) such that network-performance information > can > >> be distributed and collected in a scalable fashion. The information > >> distributed using IS-IS TE Metric Extensions can then be used to > >> make > >> path-selection decisions based on network performance. > >> > >> Note that this document only covers the mechanisms with which > >> network-performance information is distributed. The mechanisms for > >> measuring network performance or acting on that information, once > >> distributed, are outside the scope of this document. > >> > >> This document obsoletes RFC 7810. > >> > >> > >> > >> > >> > >> Please note that it may take a couple of minutes from the time of > >> submission until the htmlized version and diff are available at > tools.ietf.org. > >> > >> The IETF Secretariat > >> > >> _______________________________________________ > >> Lsr mailing list > >> Lsr@ietf.org > >> https://www.ietf.org/mailman/listinfo/lsr > >> > > > > _______________________________________________ > > Lsr mailing list > > Lsr@ietf.org > > https://www.ietf.org/mailman/listinfo/lsr _______________________________________________ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr