Hi Les, I considered this as well.
On 4/4/18, 3:39 PM, "Les Ginsberg (ginsberg)" <[email protected]> wrote: 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) In this case, the name should include -isis- or -ospf- if there is any ambiguity. In the case of RFC 7810 BIS, there is none since RFC 7810 is IS-IS only. However, I wouldn't complain if you made it draft-ginsberg-lsr-isis-rfc7810bis.txt. We just need to have "-lsr-" as the WG for all new documents. Thanks, Acee 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) <[email protected]>; [email protected] > 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- > [email protected] on behalf of [email protected]> 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: [email protected] <[email protected]> > Sent: Friday, March 30, 2018 3:33 PM > To: Qin Wu <[email protected]>; David Ward (wardd) > <[email protected]>; Spencer Giacolone <[email protected]>; > Spencer Giacalone <[email protected]>; John Drake > <[email protected]>; Les Ginsberg (ginsberg) <[email protected]>; David > Ward (wardd) <[email protected]>; Stefano Previdi <[email protected]> > 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 > [email protected] > https://www.ietf.org/mailman/listinfo/lsr > _______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr
