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) <[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

Reply via email to