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
