Re: For the fairness and justice of the IETF culture//Re: [mpls] What to do with draft-ietf-mpls-sfc-00.txt

I absolutely cannot comment on this specific case, but the normal
and polite way to handle such a situation is a clear reference
to the older draft, and some text such as "A very similar proposal
was originally made by XXX in [reference]." That would apply both
to an earlier IETF contribution or to any external publication.

In a complicated case, a whole section of the document might be
appropriate, e.g. https://tools.ietf.org/html/rfc6740#section-1.2

Regards
   Brian Carpenter

On 05/04/2018 16:34, 徐小虎(义先) wrote:
> Hi all,
> 
>  
> As I had pointed out before, this draft describes two MPLS-based SFC
> approaches: one is how to encode the NSH info, more specifically, the SPI
> and SI info by two MPLS labels, which is still a stateful SFC mechanism
> just like NSH; another is how to leverage the MPLS-SR to realize a
> stateless SFC (see section 6).
> 
>  
> It has been pointed out by many people that section 6 of the draft copies
> the
> idea of (https://tools.ietf.org/html/draft-xu-mpls-service-chaining)
> without any technology contribution except replacing “MPLS Segment
> Routing” by “Label Stack”. Funnily, one author of draft-ietf-mpls-sfc
> had inadvertently admitted
> "using a different name for the same thing is not so clever" (see
> https://mailarchive.ietf.org/arch/msg/mpls/y7FTc38ysVf6PyJlA04MEFSN9nc) in
> another thread. 
> 
> IMHO, the indulgence towards such behavior of copying
> ideas of existing drafts with word tricks would seriously trample
> underfoot the fairness and justice of the IETF culture. At least, it would
> badly damage the interest and enthusiasm of IETF participants, especially
> newcomers and non-native speakers of English.
> 
> Best regards,
> Xiaohu
>  
> 
> 
> 在 2018/4/5 上午1:05， "mpls on behalf of Adrian Farrel"
> <mpls-bounces@ietf.org on behalf of adrian@olddog.co.uk> 写入:
> 
>> WG,
>>
>> Would it help if we added use cases to this document? Usually, the IESG
>> frowns
>> on use cases, but it sounds as though this document needs some further
>> explanation.
>>
>> Of course, not everyone likes every proposed use case. Some will say, "I
>> don't
>> need that." Others will say, "I have another way, or I prefer a different
>> way,
>> of achieving that."
>>
>> Adding such a section would allow the inclusion of some text saying
>> (something
>> like) "A use case is to achieve SFC in an MPLS-SR network, but that is
>> discussed
>> in draft-xuclad-spring-sr-service-chaining."
>>
>>
>> Additionally, I have been wondering how to handle the discussion of using
>> this
>> function in a brownfield network. Normally we don't tell people in our
>> specs how
>> to build their boxes - we make protocol specs not design documents.
>> However, if
>> in addition to how I would build this, I can see a (somewhat clunky)
>> method to
>> achieve this function in existing platforms, would it be worth adding
>> that?
>>
>> Cheers,
>> Adrian
>>
>>> -----Original Message-----
>>> From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of internet-
>>> drafts@ietf.org
>>> Sent: 04 April 2018 10:28
>>> To: i-d-announce@ietf.org
>>> Cc: mpls@ietf.org
>>> Subject: [mpls] I-D Action: draft-ietf-mpls-sfc-00.txt
>>>
>>>
>>> A New Internet-Draft is available from the on-line Internet-Drafts
>> directories.
>>> This draft is a work item of the Multiprotocol Label Switching WG of
>>> the IETF.
>>>
>>>         Title           : An MPLS-Based Forwarding Plane for Service
>>> Function
>> Chaining
>>>         Authors         : Adrian Farrel
>>>                           Stewart Bryant
>>>                           John Drake
>>> 	Filename        : draft-ietf-mpls-sfc-00.txt
>>> 	Pages           : 24
>>> 	Date            : 2018-03-28
>>>
>>> Abstract:
>>>    Service Function Chaining (SFC) is the process of directing packets
>>>    through a network so that they can be acted on by an ordered set of
>>>    abstract service functions before being delivered to the intended
>>>    destination.  An architecture for SFC is defined in RFC7665.
>>>
>>>    The Network Service Header (NSH) can be inserted into packets to
>>>    steer them along a specific path to realize a Service Function Chain.
>>>
>>>    Multiprotocol Label Switching (MPLS) is a widely deployed forwarding
>>>    technology that uses labels placed in a packet in a label stack to
>>>    identify the forwarding actions to be taken at each hop through a
>>>    network.  Actions may include swapping or popping the labels as well,
>>>    as using the labels to determine the next hop for forwarding the
>>>    packet.  Labels may also be used to establish the context under which
>>>    the packet is forwarded.
>>>
>>>    This document describes how Service Function Chaining can be achieved
>>>    in an MPLS network by means of a logical representation of the NSH in
>>>    an MPLS label stack.  It does not deprecate or replace the NSH, but
>>>    acknowledges that there may be a need for an interim deployment of
>>>    SFC functionality in brownfield networks.
>>>
>>>
>>> The IETF datatracker status page for this draft is:
>>> https://datatracker.ietf.org/doc/draft-ietf-mpls-sfc/
>>>
>>> There are also htmlized versions available at:
>>> https://tools.ietf.org/html/draft-ietf-mpls-sfc-00
>>> https://datatracker.ietf.org/doc/html/draft-ietf-mpls-sfc-00
>>>
>>>
>>> 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.
>>>
>>> Internet-Drafts are also available by anonymous FTP at:
>>> ftp://ftp.ietf.org/internet-drafts/
>>>
>>> _______________________________________________
>>> mpls mailing list
>>> mpls@ietf.org
>>> https://www.ietf.org/mailman/listinfo/mpls
>>
>> _______________________________________________
>> mpls mailing list
>> mpls@ietf.org
>> https://www.ietf.org/mailman/listinfo/mpls
> 
> 
> 