Fine with me.

More important, I would like to fast track this bis document since the changes 
are so pointed and directly affect the probability of interoperable 

How quickly can we move to WG status?
Can we do that even before the name change – so I can issue 
“ietf-lsr-isis-rfc7810bis” ??


From: Jeff Tantsura <>
Sent: Wednesday, April 04, 2018 1:58 PM
To: Acee Lindem (acee) <>; Tony Li <>; Les 
Ginsberg (ginsberg) <>
Subject: Re: [Lsr] FW: New Version Notification for 


I’d think the below would work:
lsr for #2
lsr-ospf(ospfv3) / lsr-isis for #1

From: Lsr <<>> on behalf of 
"Acee Lindem (acee)" <<>>
Date: Wednesday, April 4, 2018 at 13:27
To: Tony Li <<>>, "Les Ginsberg 
(ginsberg)" <<>>
Cc: "<>" <<>>
Subject: Re: [Lsr] FW: New Version Notification for 

I think the WG name should be in the expected place in the file name. I seem to 
remember some drafts with -bgp- rather than -idr- that flew under the radar for 
a while.

From: Tony Li <<>>
Date: Wednesday, April 4, 2018 at 4:03 PM
To: "Les Ginsberg (ginsberg)" <<>>
Cc: Acee Lindem <<>>, 
"<>" <<>>
Subject: Re: [Lsr] FW: New Version Notification for 

I don’t see the big deal in having the WG name in the draft title, even for 
category 1 documents.

It’s only the name of the draft and the fact that it is protocol specific 
doesn’t really need to be called out at that level.  People who read the 
document will certainly figure it out.


On Wed, Apr 4, 2018 at 12:39 PM Les Ginsberg (ginsberg) 
<<>> 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)

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.



> -----Original Message-----
> From: Acee Lindem (acee)
> Sent: Tuesday, April 03, 2018 7:45 AM
> To: Les Ginsberg (ginsberg) <<>>; 
> 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-
><> on behalf of 
><>> wrote:
>     Folks -
>     A bis version of RFC 7810 has been submitted to address the issue reported
> in Errata ID: 5293
>     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:<> 
> <<>>
>     Sent: Friday, March 30, 2018 3:33 PM
>     To: Qin Wu <<>>; David Ward 
> (wardd)
> <<>>; Spencer Giacolone 
> <<>>;
> Spencer Giacalone 
> <<>>; John Drake
> <<>>; Les Ginsberg (ginsberg) 
> <<>>; David
> Ward (wardd) <<>>; Stefano Previdi 
> <<>>
>     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:  
> rfc7810bis-00.txt
>     Status:         
>     Htmlized:       
>     Htmlized:
> 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 
>     The IETF Secretariat
>     _______________________________________________
>     Lsr mailing list

Lsr mailing list<>
_______________________________________________ Lsr mailing list<>
Lsr mailing list

Reply via email to