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>; lsr@ietf.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>; lsr@ietf.org
> >> 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

Reply via email to