Re: [CCAMP] Closing Issue #49 (Was: Re: R: Closing G.709 open issues)

[Lou Berger <[e-mail]>]

Fatai,

Just to be clear, the following covers your correction:

    G.709
   Payload
    Type   G-PID   Type/Comment    LSP Encoding
    ====   =====   ==============  ===================
    0x05    TBA1   Framed GFP      G.709 ODUk
            54     Ethernet MAC    G.709 ODUk
                   (framed GFP)

Right?

Thanks,
Lou

On 5/23/2013 9:01 PM, Fatai Zhang wrote:
> Hi Lou,
> 
> Fine, thanks for your explanation.
> 
> As I said, I will update the signaling draft based on your proposal if there are no further comments.
> 
> 
> 
> Best Regards
> 
> Fatai
> 
> 
> -----Original Message-----
> From: Lou Berger [mailto:[e-mail]] 
> Sent: Friday, May 24, 2013 12:15 AM
> To: Fatai Zhang
> Cc: CCAMP; [e-mail]
> Subject: Re: [CCAMP] Closing Issue #49 (Was: Re: R: Closing G.709 open issues)
> 
> Fatai,
> 	Do we really need to reopen debate on a topic the WG discussed and
> closed last summer?  (i.e., to handle G.709 client adaptation just as we
> do for every other technology.)
> 
> I do agree that some new G-PID assignments were missed in the draft that
> went to LC, but filling in the list doesn't automatically mean that the
> WG needs to reopen debate on adaptation approaches.
> 
> Assuming we don't need to reopen the pre-LC debate from last summer, and
> with respect to the list I sent out, I do agree the WG needs to:
> 
> A) Ensure that the list doesn't have unneeded new G-PIDs (i.e., reuses
> the same/existing G-PIDs wherever possible.)
> 
> B) Identifies the "right" G-PID per payload type, and doesn't have any
> other technical errors
> 
> C) Doesn't conflict with past WG decisions/discussions.
> 
>>From your mails I see the following comment on (A):
> 
>> For 0x05, why you think that RFC4328 does not cover it (ie., G-PID=54)?
> 
> G-PID 54, per IANA, is currently defined as "Ethernet MAC (framed GFP)".
>  Per G.709, PT=0x05 maps to "GFP mapping, see clause 17.4" and looking
> at 17.4 there is no restriction on what is carried in GFP frames.  So it
> seems that PT=0x05 can't be limited to just "Ethernet MAC (framed GFP)".
> 
> Are you suggesting changing the type description of G-PID 54 to just
> "Framed GFP", or including G-PID 54 as an additional possibility for
> PT=0x05?
> 
> The latter seems to be a valid addition/correction.  The former may be
> problematic for existing implementations, so we'll need to discuss more
> broadly if that's the direction you want to head.
> 
> All/ (WG),
> 
> Again, please speak up if you think the above is not aligned with prior
> consensus or if you have an issue with any of the above.
> 
> Lou
> 
> On 5/22/2013 10:35 PM, Fatai Zhang wrote:
>> Hi Lou,
>>
>>  
>>
>> I incorporated your proposal into my table to facilitate the readers.
>>
>>  
>>
>> I think you still insist on reusing some existing G-PIDs like 58, 56.
>>  For 0x04, why you think that RFC4328 does not cover it (ie., G-PID=54)?
>>
>>  
>>
>> Technically, I am not convince by your proposal, but I would like to
>> reserve my opinion for your same motivation (ie., to conclude the
>> discussion as soon as possible).
>>
>>  
>>
>> Any opinions on Lou's proposal from the WG? I will update the signaling
>> draft based on Lou's proposal if there is no comment on Lou's proposal.
>>
>>  
>>
>> Note that all the new G-PID values will be re-ordered with TBA.
>>
>>  
>>
>> *G-PIDs vs **Payload types defined in Table 15-8 of G.709*
>>
>>  
>>
>> Payload Type in Hex codedefined in G.709
>>
>> 	
>>
>> G-PID
>>
>> 	
>>
>> LSP Encoding
>>
>> 	
>>
>> Note
>>
>> 	
>>
>> Interpretationfrom G.709
>>
>> 0x01
>>
>> 	
>>
>> None
>>
>> 	
>>
>>  
>>
>> 	
>>
>> Not needed
>>
>> 	
>>
>> Experimental mapping (Note 3)
>>
>> 0x02
>>
>> 	
>>
>> 49
>>
>> 	
>>
>> G.709 ODUk, G.709 OCh
>>
>> 	
>>
>> 1)G-PID defined in RFC4328;
>>
>> 2) Updated in this draft.
>>
>> 	
>>
>> Asynchronous CBR mapping, see clause 17.2
>>
>> 0x03
>>
>> 	
>>
>> 50
>>
>> 	
>>
>> G.709 ODUk
>>
>> 	
>>
>> ditto
>>
>> 	
>>
>> Bit synchronous CBR mapping, see clause 17.2
>>
>> 0x04
>>
>> 	
>>
>> 32
>>
>> 	
>>
>> SDH, G.709 ODUk
>>
>> 	
>>
>> ditto
>>
>> 	
>>
>> ATM mapping, see clause 17.3
>>
>> 0x05
>>
>> 	
>>
>> 54
>>
>> or
>>
>> TBA (Suggested by Lou)
>>
>> 	
>>
>> G.709 ODUk (and SDH)
>>
>>  
>>
>> 	
>>
>> G-PIDs defined in RFC4328 for framed GFP
>>
>>  
>>
>> 	
>>
>> GFP mapping, see clause 17.4
>>
>> 0x06
>>
>> 	
>>
>> None
>>
>> 	
>>
>>  
>>
>> 	
>>
>> Not needed and Not defined in RFC4328
>>
>> 	
>>
>> Virtual Concatenated signal, see clause 18 (Note 5)
>>
>> 0x07
>>
>> 	
>>
>> 61(TBA)
>>
>> Or55(Suggested by Lou)
>>
>> 	
>>
>> G.709 ODUk (k=0,3,4)
>>
>> 	
>>
>> Is being defined in this draft (new payload type defined in [G.709-2012])
>>
>> 	
>>
>> PCS codeword transparent Ethernet mapping:
>>
>> *      1000BASE-X into OPU0, see clauses 17.7.1 and 17.7.1.1
>>
>> *      40GBASE-R into OPU3, see clauses 17.7.4 and 17.7.4.1
>>
>> *      100GBASE-R into OPU4, see clauses 17.7.5 and 17.7.5.1
>>
>> 0x08
>>
>> 	
>>
>> 62(TBA)
>>
>> Or58(Suggested by Lou)
>>
>> 	
>>
>> G.709 ODUk (k=2e)
>>
>> 	
>>
>> ditto
>>
>> 	
>>
>> FC-1200 into OPU2e mapping, see clause 17.8.2
>>
>> 0x09
>>
>> 	
>>
>> 63(TBA)
>>
>> 	
>>
>> G.709 ODUk (k=2)
>>
>> 	
>>
>> ditto
>>
>> 	
>>
>> GFP mapping into Extended OPU2 payload, see clause 17.4.1 (Note 6)
>>
>> 0x0A
>>
>> 	
>>
>> 64(TBA)
>>
>> 	
>>
>> G.709 ODUk (k=0)
>>
>> 	
>>
>> ditto
>>
>> 	
>>
>> STM-1 mapping into OPU0, see clause 17.7.1
>>
>> 0x0B
>>
>> 	
>>
>> 65(TBA)
>>
>> 	
>>
>> G.709 ODUk (k=0)
>>
>> 	
>>
>> ditto
>>
>> 	
>>
>> STM-4 mapping into OPU0, see clause 17.7.1
>>
>> 0x0C
>>
>> 	
>>
>> 66(TBA)
>>
>> Or58(Suggested by Lou)
>>
>> 	
>>
>> G.709 ODUk (k=0)
>>
>> 	
>>
>> ditto
>>
>> 	
>>
>> FC-100 mapping into OPU0, see clause 17.7.1
>>
>> 0x0D
>>
>> 	
>>
>> 67(TBA)
>>
>> Or58(Suggested by Lou)
>>
>> 	
>>
>> G.709 ODUk (k=1)
>>
>> 	
>>
>> ditto
>>
>> 	
>>
>> FC-200 mapping into OPU1, see clause 17.7.2
>>
>> 0x0E
>>
>> 	
>>
>> 68(TBA)
>>
>> Or58(Suggested by Lou)
>>
>> 	
>>
>> G.709 ODUflex
>>
>> 	
>>
>> ditto
>>
>> 	
>>
>> FC-400 mapping into OPUflex, see clause 17.9
>>
>> 0x0F
>>
>> 	
>>
>> 69(TBA)
>>
>> Or58(Suggested by Lou)
>>
>> 	
>>
>> G.709 ODUflex
>>
>> 	
>>
>> ditto
>>
>> 	
>>
>> FC-800 mapping into OPUflex, see clause 17.9
>>
>> 0x10
>>
>> 	
>>
>> 51
>>
>> 	
>>
>> G.709 ODUk
>>
>> 	
>>
>> 1)G-PID defined in RFC4328;
>>
>> 2) Updated in this draft.
>>
>> 	
>>
>> Bit stream with octet timing mapping, see clause 17.6.1
>>
>> 0x11
>>
>> 	
>>
>> 52
>>
>> 	
>>
>> G.709 ODUk
>>
>> 	
>>
>> ditto
>>
>> 	
>>
>> Bit stream without octet timing mapping, see clause 17.6.2
>>
>> 0x12
>>
>> 	
>>
>> 70(TBA)
>>
>> 	
>>
>> G.709 ODUflex
>>
>> 	
>>
>> Is being defined in this draft (new payload type defined in [G.709-2012])
>>
>> 	
>>
>> IB SDR  mapping into OPUflex, see 17.9
>>
>> 0x13
>>
>> 	
>>
>> 71(TBA)
>>
>> 	
>>
>> G.709 ODUflex
>>
>> 	
>>
>> ditto
>>
>> 	
>>
>> IB DDR mapping into OPUflex, see 17.9
>>
>> 0x14
>>
>> 	
>>
>> 72(TBA)
>>
>> 	
>>
>> G.709 ODUflex
>>
>> 	
>>
>> ditto
>>
>> 	
>>
>> IB QDR mapping into OPUflex, see 17.9
>>
>> 0x15
>>
>> 	
>>
>> 73(TBA)
>>
>> 	
>>
>> G.709 ODUk (k=0)
>>
>> 	
>>
>> ditto
>>
>> 	
>>
>> SDI  mapping into OPU0, see 17.7.1
>>
>> 0x16
>>
>> 	
>>
>> 74(TBA)
>>
>> 	
>>
>> G.709 ODUk (k=1)
>>
>> 	
>>
>> ditto
>>
>> 	
>>
>> (1.485/1.001) Gbit/s SDI mapping into OPU1, see 17.7.2
>>
>> 0x17
>>
>> 	
>>
>> 75(TBA)
>>
>> 	
>>
>> G.709 ODUk (k=1)
>>
>> 	
>>
>> ditto
>>
>> 	
>>
>> 1.485 Gbit/s SDI mapping into OPU1, see 17.7.2
>>
>> 0x18
>>
>> 	
>>
>> 76(TBA)
>>
>> 	
>>
>> G.709 ODUflex
>>
>> 	
>>
>> ditto
>>
>> 	
>>
>> (2.970/1.001) Gbit/s SDI mapping into OPUflex, see 17.9
>>
>> 0x19
>>
>> 	
>>
>> 77(TBA)
>>
>> 	
>>
>> G.709 ODUflex
>>
>> 	
>>
>> ditto
>>
>> 	
>>
>> 2.970 Gbit/s SDI mapping into OPUflex, see 17.9
>>
>> 0x1A
>>
>> 	
>>
>> 78(TBA)
>>
>> Or56(Suggested by Lou)
>>
>> 	
>>
>> G.709 ODUk (k=0)
>>
>> 	
>>
>> ditto
>>
>> 	
>>
>> SBCON/ESCON mapping into OPU0, see 17.7.1
>>
>> 0x1B
>>
>> 	
>>
>> 79(TBA)
>>
>> 	
>>
>> G.709 ODUk (k=0)
>>
>> 	
>>
>> ditto
>>
>> 	
>>
>> DVB_ASI mapping into OPU0, see 17.7.1
>>
>> 0x20
>>
>> 	
>>
>> 47
>>
>> 	
>>
>> G.709 ODUk
>>
>> 	
>>
>> 1) G-PIDs defined in RFC4328.
>>
>> 2) Updated in this draft.
>>
>> 	
>>
>> ODU multiplex structure supporting ODTUjk only, see clause 19 (AMP only)
>>
>> 0x21
>>
>> 	
>>
>> 59/60(TBA)
>>
>> 	
>>
>> G.709 ODUk
>>
>> 	
>>
>> 1)Are being defined in this draft (new payload type defined in
>> [G.709-2012]);
>>
>> 2) 59 for G.709 ODU-1.25G; 60 for G.709 ODU-any
>>
>> 	
>>
>> ODU multiplex structure supporting ODTUk.ts or ODTUk.ts and ODTUjk, see
>> clause 19 (GMP capable) (Note 7)
>>
>> 55
>>
>> 	
>>
>> None
>>
>> 	
>>
>>  
>>
>> 	
>>
>> Not needed
>>
>> 	
>>
>> Not available (Note 2)
>>
>> 66
>>
>> 	
>>
>> None
>>
>> 	
>>
>>  
>>
>> 	
>>
>> Not needed
>>
>> 	
>>
>> Not available (Note 2)
>>
>> 80-8F
>>
>> 	
>>
>> None
>>
>> 	
>>
>>  
>>
>> 	
>>
>> Not needed
>>
>> 	
>>
>> Reserved codes for proprietary use (Note 4)
>>
>> FD
>>
>> 	
>>
>> None
>>
>> OrTBA(Suggested by Lou)
>>
>> 	
>>
>>  
>>
>> 	
>>
>> Not needed
>>
>> 	
>>
>> NULL test signal mapping, see clause 17.5.1
>>
>> FE
>>
>> 	
>>
>> None
>>
>> OrTBA(Suggested by Lou)
>>
>> 	
>>
>>  
>>
>> 	
>>
>> Not needed
>>
>> 	
>>
>> PRBS test signal mapping, see clause 17.5.2
>>
>> FF
>>
>> 	
>>
>> None
>>
>> 	
>>
>>  
>>
>> 	
>>
>> Not needed
>>
>> 	
>>
>> Not available (Note 2)
>>
>>  
>>
>> 	
>>
>>  
>>
>> 	
>>
>>  
>>
>> 	
>>
>>  
>>
>> 	
>>
>>  
>>
>>  
>>
>>  
>>
>>  
>>
>>  
>>
>> Best Regards
>>
>>  
>>
>> Fatai
>>
>>  
>>
>>  
>>
>> -----Original Message-----
>> From: [e-mail] [mailto:[e-mail]] On Behalf
>> Of Lou Berger
>> Sent: Tuesday, May 21, 2013 9:17 PM
>> To: CCAMP
>> Cc: [e-mail]
>> Subject: [CCAMP] Closing Issue #49 (Was: Re: R: Closing G.709 open issues)
>>
>>  
>>
>> All,
>>
>>  
>>
>> In the interest of moving this discussion quickly to closure, I spent
>>
>> some time trying to come up with the full list of G.709 PT to G-PID
>>
>> mappings.  In coming up with this list I tried to be consistent with
>>
>> the last consensus point that I can identify on this topic (the
>>
>> previously referenced July 2012 thread & presentation), which included:
>>
>>  
>>
>> A) Defining new G-PIDs for client types not identified by an assigned
>>
>> G-PID (per
>>
>> http://www.iana.org/assignments/gmpls-sig-parameters/gmpls-sig-parameters.xml)
>>
>>  
>>
>> B) Reusing G-PID wherever {G-PID, ODU rate} unambiguously identify a
>>
>> G.709 payload type, and define new G-PIDs when reuse not possible.
>>
>>  
>>
>> C) No G-PID value for unused, reserved, or proprietary 709 Payload Type.
>>
>>  
>>
>> Here's what I've come up with:
>>
>>  
>>
>>     G.709
>>
>>    Payload
>>
>>     Type   G-PID   Type/Comment    LSP Encoding
>>
>>     ====   =====   ==============  ===================
>>
>>     0x01           No standard value
>>
>>     0x02    49     CBRa            G.709 ODUk
>>
>>     0x03    50     CBRb            G.709 ODUk
>>
>>     0x04    32     ATM             G.709 ODUk
>>
>>     0x05    TBA1   Framed GFP      G.709 ODUk
>>
>>     0x06    ???    Is any valued needed?
>>
>>     0x07    55     Ethernet PHY    G.709 ODUk (k=0)
>>
>>                    (transparent    G.709 ODUk (k=3)
>>
>>                    GFP)            G.709 ODUk (k=4)
>>
>>     0x08    58     Fiber Channel   G.709 ODUk (k=2e)
>>
>>     0x09    TBA1   Framed GFP      G.709 ODUk (k=2e)
>>
>>     0x0A    TBA2   STM-1           G.709 ODUk (k=0)
>>
>>     0x0B    TBA3   STM-4           G.709 ODUk (k=0)
>>
>>     0x0C    58     Fiber Channel   G.709 ODUk (k=0)
>>
>>     0x0D    58     Fiber Channel   G.709 ODUk (k=1)
>>
>>     0x0E    58     Fiber Channel   G.709 ODUflex
>>
>>     0x0F    58     Fiber Channel   G.709 ODUflex
>>
>>     0x10    51     BSOT            G.709 ODUk
>>
>>     0x11    52     BSNT            G.709 ODUk
>>
>>     0x12    TBA4   InfiniBand      G.709 ODUflex
>>
>>     0x13    TBA4   InfiniBand      G.709 ODUflex
>>
>>     0x14    TBA4   InfiniBand      G.709 ODUflex
>>
>>     0x15    TBA5   Serial Digital  G.709 ODUk (k=0)
>>
>>                    Interface
>>
>>     0x16    TBA6   Serial Digital  G.709 ODUk (k=1)
>>
>>                    Interface/1.001
>>
>>     0x17    TBA5   Serial Digital  G.709 ODUk (k=1)
>>
>>                    Interface
>>
>>     0x18    TBA6   Serial Digital  G.709 ODUflex
>>
>>                    Interface/1.001
>>
>>     0x19    TBA5   Serial Digital  G.709 ODUflex
>>
>>                    Interface
>>
>>     0x1A    56     SBCON/ESCON     G.709 ODUk (k=0)
>>
>>                    (IANA to update Type field)
>>
>>     0x1B    TBA7   DVB_ASI         G.709 ODUk (k=0)
>>
>>     0x1C    58     Fiber Channel   G.709 ODUk
>>
>>     0x20    47     G.709 ODU-2.5G  G.709 ODUk
>>
>>                                      (k=2,3)
>>
>>                    (IANA to update Type field)
>>
>>             TBA8   G.709 ODU-1.25G G.709 ODUk
>>
>>                                      (k=1,2,3)
>>
>>     0x21    TBA8   G.709 ODU-1.25G G.709 ODUk
>>
>>                                      (k=2,3,4)
>>
>>             TBA9   G.709 ODU-Any   G.709 ODUk
>>
>>                                    (k=2,3)
>>
>>     0x55           No standard value
>>
>>     0x66           No standard value
>>
>>     0x80-0x8F      No standard value
>>
>>     0xFD    TBA10  Null Test       G.709 ODUk
>>
>>     0xFE    TBA11  Random Test     G.709 ODUk
>>
>>     0xFF           No standard value
>>
>>  
>>
>> Note that there are a few differences with Fatai's list, which doesn't
>>
>> format well in e-mail, but is available in the archive
>>
>> http://www.ietf.org/mail-archive/web/ccamp/current/msg14845.html
>>
>>  
>>
>> Please speak up if you think the above is not aligned with prior
>>
>> consensus or if you have an issue with any of the above.
>>
>>  
>>
>> Much thanks,
>>
>> Lou
>>
>>  
>>
>>  
>>
>> On 5/20/2013 5:09 AM, Fatai Zhang wrote:
>>
>>> Hi Lou,
>>
>>>
>>
>>>  
>>
>>>
>>
>>> I think my mail on March 13rd may have answered your following comments.
>>
>>> My response quoted as follows.
>>
>>>
>>
>>>  
>>
>>>
>>
>>> In addition, if people look at the full list that I provided, I think
>>
>>> people can realize that RFC4328 (section 3.1.3) used the same approach
>>
>>> as the current approach of this draft (ie., 1:1 mapping between GPIDs
>>
>>> and payload types defined by G.709), ie., we are following what RFC4328
>>
>>> did.
>>
>>>
>>
>>>  
>>
>>>
>>
>>> BTW, I am not sure if we need spend so much on discussing this point
>>
>>> (because there is no issue to stick to the data plane by using the
>>
>>> current approach of this draft).
>>
>>>
>>
>>>  
>>
>>>
>>
>>> ======================================================================================================================
>>
>>>
>>
>>> (2) 'Grouped GPID' vs '1:1' mapping (between G.709-2012 and GPIDs
>>
>>> defined in this draft)
>>
>>>
>>
>>>  
>>
>>>
>>
>>> We realize that it is safe to use 1:1 mapping approach to avoid some
>>
>>> potential issues after investigation. We know this payload types have
>>
>>> been defined by G.709 (data plane), so physically it is better to use
>>
>>> 1:1 mapping approach.
>>
>>>
>>
>>> For the potential issues I mentioned above, for example, we cannot use
>>
>>> the existing 34 to represent 'STM-1' and 'STM-4 ', because it is
>>
>>> impossible to differentiate which one is 'STM-1' or 'STM-4'. In
>>
>>> addition, from the concept of payload type, we know that e.g, FC-100 is
>>
>>> different from FC-800, right? So, it is better to assign different GPIDs
>>
>>> to these different payload types defined by the data plane.
>>
>>>
>>
>>>  
>>
>>>
>>
>>> Furthermore, I think it is much cheaper to create new GPIDs in the
>>
>>> control plane than in the data plane (these payload types will be
>>
>>> carried in the OH).
>>
>>>
>>
>>>  
>>
>>>
>>
>>>  
>>
>>>
>>
>>>  
>>
>>>
>>
>>>  
>>
>>>
>>
>>> Best Regards
>>
>>>
>>
>>>  
>>
>>>
>>
>>> Fatai
>>
>>>
>>
>>>  
>>
>>>
>>
>>> -----Original Message-----
>>
>>> From: Lou Berger [mailto:[e-mail]]
>>
>>> Sent: Friday, May 17, 2013 11:16 PM
>>
>>> To: Fatai Zhang
>>
>>> Cc: BELOTTI, SERGIO (SERGIO); Daniele Ceccarelli; CCAMP;
>>
>>> [e-mail]
>>
>>> Subject: Re: R: Closing G.709 open issues
>>
>>>
>>
>>>  
>>
>>>
>>
>>> Fatai,
>>
>>>
>>
>>>         
>>
>>>
>>
>>> That's a great start for the WG.  Thank you.
>>
>>>
>>
>>>  
>>
>>>
>>
>>> To answer your implied question as to why my request for the full list.
>>
>>>
>>
>>> My feeling is that there have been too many "surprises" on the 709
>>
>>>
>>
>>> documents in areas that I thought were either obvious (but from the IETF
>>
>>>
>>
>>> & GMPLS context, not ITU-T or G.709 perspectives) or resolved by past
>>
>>>
>>
>>> discussions.  At this point, as co-chair and Document shepherd, I want
>>
>>>
>>
>>> to ensure that any open point on the documents are unambiguously closed
>>
>>>
>>
>>> and that past discussions (i.e., points of consensus) are 100% captured,
>>
>>>
>>
>>> so that we can smoothly move through the planned second LC and
>>
>>>
>>
>>> publication request.
>>
>>>
>>
>>>  
>>
>>>
>>
>>> To that end, in my previous message I asked two questions about points
>>
>>>
>>
>>> where it seems you are proposing moving away from what has been
>>
>>>
>>
>>> previously been discussed & agreed to by the WG.  Can you answer the
>>
>>>
>>
>>> following:
>>
>>>
>>
>>>  
>>
>>>
>>
>>>>> My questions on the new G-PIDs come down to:
>>
>>>
>>
>>>>> - Why are rate specific G-PIDs being proposed (rather than
>>
>>>
>>
>>>>>   continuing to use the previous approach documented in the draft
>>
>>>
>>
>>>>>   and in Section 3.1.3 of rfc4328)?
>>
>>>
>>
>>>  
>>
>>>
>>
>>>>> - Why are new values being defined rather than using existing
>>
>>>
>>
>>>>>   values, e.g., G-PID 56?
>>
>>>
>>
>>>>>
>>
>>>
>>
>>>  
>>
>>>
>>
>>> Much thanks,
>>
>>>
>>
>>> Lou
>>
>>>
>>
>>>  
>>
>>>
>>
>>>  
>>
>>>
>>
>> _______________________________________________
>>
>> CCAMP mailing list
>>
>> [e-mail]
>>
>> https://www.ietf.org/mailman/listinfo/ccamp
>>
> 
> 
> 
>