Subject: [sfc] #2 (architecture): Remove "MD Type" field and the companion "MD-type 1"

From: "sfc issue tracker" <[email-masked]>
Date: Tue, 28 Apr 2015 06:08:36 -0000

#2: Remove "MD Type" field and the companion "MD-type 1"

 I already send an email back in February to ask about the following but I
 didn't got any answer

 ==
 What is the rationale for defining two MD Types? Why MD Type#1 is
 mandatory to support? Wouldn’t the format in Section 3.5 enough for the
 SFC use cases?
 What is the rationale for defining these mandatory contexts headers? What
 is the motivation for defining mandatory context header?

 The current text does not explain those aspects.
 ==

 For the sake of interoperability (mainly to avoid multiple implementations
 with distinct behaviors) and given no technical motivation is provided
 (e.g. why MD-type 1 is mandatory why not the other way around, etc. ), one
 header format should be specified.

 My personal point of view is that we need to choose. I’m personally for a
 minimalist header. Leaving both induces more complexity.

 I suggest to remove the "MD type" field and MD-type 1 from the
 specification.

 Moreover, I don’t understand from the draft what is the rationale for
 classifying the context into these four categories. What is meant by
 “platform-specific metadata” or “service platform specific”?

     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                  Network Platform Context                     |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                  Network Shared Context                       |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                  Service Platform Context                     |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                  Service Shared Context                       |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

-- 
-------------------------------------+-------------------------------------
 Reporter:                           |      Owner:  draft-ietf-sfc-
  [email-masked]       |  [email-masked]
     Type:  defect                   |     Status:  new
 Priority:  major                    |  Milestone:
Component:  architecture             |    Version:
 Severity:  -                        |   Keywords:
-------------------------------------+-------------------------------------

Ticket URL: <http://trac.tools.ietf.org/wg/sfc/trac/ticket/2>
sfc <http://tools.ietf.org/sfc/>

---

From: "sfc issue tracker" <[email-masked]>
Date: Tue, 28 Apr 2015 06:25:14 -0000

Changes (by [email-masked]):

 * owner:  [email-masked] => draft-ietf-sfc-
     [email-masked]
 * component:  architecture => nsh

-- 
-------------------------------------+-------------------------------------
 Reporter:                           |       Owner:  draft-ietf-sfc-
  [email-masked]       |  [email-masked]
     Type:  defect                   |      Status:  new
 Priority:  major                    |   Milestone:
Component:  nsh                      |     Version:
 Severity:  -                        |  Resolution:
 Keywords:                           |
-------------------------------------+-------------------------------------

Ticket URL: <http://trac.tools.ietf.org/wg/sfc/trac/ticket/2#comment:1>
sfc <http://tools.ietf.org/sfc/>

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 28 Apr 2015 10:36:06 -0400

This is an NSH question, not an Architecture draft question.
Yours,
Joel