Sold!

Cheers,
Jeff
On 4/6/18, 14:45, "Acee Lindem (acee)" <[email protected]> wrote:

    Good point - we will expand to: 
    
        <author-name>-lsr-ospf-<draft-specific-name>      - OSPF Specific 
drafts pertaining to both OSPFv2 and OSPFv3
        <author-name>-lsr-ospfv2-<draft-specific-name>  - OSPFv2 only Specific 
drafts 
        <author-name>-lsr-ospfv3-<draft-specific-name>  - OSPFv3 only Specific 
drafts     
        <author-name>-lsr-isis-<draft-specific-name>        - IS-IS Specific 
drafts
        <author-name>-lsr-<draft-specific-name>               - Drafts covering 
both protocols.
    
    I'd hope the OSPFv2 and OSPFv3 specific drafts are few and far between but 
I can still see reasons to have both (e.g., OSPFv2 will never support multiple 
address familes). 
    
    Thanks,
    Acee    
    
    On 4/6/18, 5:29 PM, "Jeff Tantsura" <[email protected]> wrote:
    
        Acee,
        
        What about ospfv2 vs ospfv3 specifics?
        We keep it as before - eg “ospf” covers either or ospfv2, “ospfv3” is 
for ospfv3 only? 
        
        Regards,
        Jeff
        
        > On Apr 6, 2018, at 12:25, Acee Lindem (acee) <[email protected]> wrote:
        > 
        > I'm fine with the proposed naming conventions for new drafts. 
Formally: 
        > 
        >    <author-name>-lsr-ospf-<draft-specific-name>   - OSPF Specific 
drafts
        >    <author-name>-lsr-isis-<draft-specific-name>      - IS-IS Specific 
drafts 
        >    <author-name>-lsr-<draft-specific-name>             - Drafts 
covering both protocols. 
        > 
        > Anyone strongly disagree? 
        > 
        > Thanks,
        > Acee 
        > 
        > 
        > 
        > 
        > On 4/6/18, 1:57 PM, "Les Ginsberg (ginsberg)" <[email protected]> 
wrote:
        > 
        >    Tom -
        > 
        >    Thanx for the support.
        > 
        >    It occurs to me that your filter still needs adjustment however - 
since there will be cases when a common document is used for all protocols - 
and in such a case you can only expect "-lsr-" to be in the title.
        > 
        >    My point is there should be a straightforward way to identify the 
scope of the content from the name - just using "-lsr-" for all documents is 
very sub-optimal - and the fix for this is very easy.
        > 
        >       Les
        > 
        > 
        >> -----Original Message-----
        >> From: t.petch <[email protected]>
        >> Sent: Friday, April 06, 2018 3:43 AM
        >> To: Les Ginsberg (ginsberg) <[email protected]>; Christian Hopps
        >> <[email protected]>
        >> Cc: [email protected]; Acee Lindem (acee) <[email protected]>
        >> Subject: Re: [Lsr] FW: New Version Notification for 
draft-ginsberg-isis-
        >> rfc7810bis-00.txt
        >> 
        >> ----- Original Message -----
        >> From: "Les Ginsberg (ginsberg)" <[email protected]>
        >> Sent: Thursday, April 05, 2018 5:26 PM
        >> 
        >>> Chris -
        >>> 
        >>>> -----Original Message-----
        >>>> From: Christian Hopps <[email protected]>
        >>>> Sent: Thursday, April 05, 2018 7:32 AM
        >>>> 
        >>>> 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-xxxx-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 xxxx 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.
        >>> 
        >> 
        >> I agree.
        >> 
        >> From a purely personal point of view, I track OSPF but have no 
interest in the
        >> other protocol (mention of which causes my ISP to blackhole my 
e-mail).  I
        >> filter the I-D announce list and will see notification of any I-D 
with OSPF in the
        >> title - any without OSPF in the title will pass under the radar.
        >> 
        >> Tom Petch
        >> 
        >>>   Les
        >>> 
        >>>> Thanks,
        >>>> Chris.
        >>>> 
        >>>> Les Ginsberg (ginsberg) <[email protected]> writes:
        >>>> 
        >>>>> Well...this raises a topic on which I would like to have feedback
        >> from the
        >>>> WG.
        >>>>> 
        >>>>> Combining xxxx/OSPF into one working group is fine - no argument
        >> there.
        >>>>> But, we now may be producing two classes of documents:
        >>>>> 
        > 
        > 
        > 
        > _______________________________________________
        > 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