Re: [CCAMP] Vendor-Specific Application Code in draft-ietf-ccamp-rwa-wson-encode

[Daniele Ceccarelli <[e-mail]>]

I think Xian's proposal makes sense.

I would like not to hold the draft for 6 more months. 
As chair I would suggest to go for option 1 or 3 and then go for a bis when G.874.1 will be consented.
As contributor, among 1 and 3 I would prefer 1 but I think 3 leaves more room for a simple and straightforward bis.

Opinions on this last statement?

BR
Daniele

> -----Original Message-----
> From: CCAMP [mailto:[e-mail]] On Behalf Of Lou Berger
> Sent: giovedì 29 gennaio 2015 17:22
> To: Zhangxian (Xian)
> Cc: [e-mail]; [e-mail]; draft-ietf-ccamp-rwa-
> [e-mail]
> Subject: Re: [CCAMP] Vendor-Specific Application Code in draft-ietf-ccamp-
> rwa-wson-encode
> 
> On 01/29/2015 11:17 AM, Zhangxian (Xian) wrote:
> > Hi, Lou,
> >
> >    I support your proposal.
> >
> > Just a thought: given the massive support of Option 2 from WG,  maybe
> > we can reconcile by moving the WG draft forward using either Option
> > 1/3, while writing a short draft to document the update needed to
> > match the to-be-updated G.874.1? So that once it is updated, we can
> > move the draft quickly.
> >
> 
> Seems right to me (as contributor)
> 
> Lou
> 
> > Regards,
> > Xian
> >
> > ________________________________________
> > 发件人: CCAMP [[e-mail]] 代表 Lou Berger
> [[e-mail]]
> > 发送时间: 2015年1月29日 23:59
> > 收件人: Leeyoung; [e-mail]; 'Varma, Eve L (Eve)';
> > [e-mail]; 'Lam, Hing-Kam (Kam)'; [e-mail];
> > [e-mail]
> > 抄送: [e-mail]; [e-mail];
> > [e-mail];
> > [e-mail]
> > 主题: Re: [CCAMP] Vendor-Specific Application Code in
> > draft-ietf-ccamp-rwa-wson-encode
> >
> > I thought it would be good to let things settle a bit before
> > responding as Shepherd.
> >
> > So option 1 (No definition of proprietary semantics and conflicts are
> > handled outside of the control plane, i.e., belong to operator) was
> > the intent of the WG at the time of publication request.  This
> > approach was also aligned with the then, and actually current, state
> > of the ITU-T data plane (and management info) as discussed in our
> > joint meeting. I believe option 3 (dropping the vendor specific
> > option) isn't in conflict with this.
> >
> > There now seems to be support for changing the document to align it
> > with, what I understand is, a planned update to G.874.1.  This of
> > course implies that such a change would result in this document being
> > blocked until that update is published in 6 months or so, and assumes
> > no substantive change its contents.
> >
> > Again with Shepherd hat on, I recommend avoiding the additional delay
> > and not tie this document to the planned G.874.1 update at this time,
> > i.e., by following option 1 (or even 3).  This allows for a future
> > bis/update that is align with the expected update to G.874.1 once it
> > is published.
> >
> > Comments, objections, support?  (AD, authors, chairs, wg, ...)
> >
> > Lou
> >
> > On 01/29/2015 09:51 AM, Leeyoung wrote:
> >> Hi,
> >>
> >> It seems like the world is against Option 1. No big deal, please provide
> relevant text to support Option 2.
> >>
> >> Young
> >>
> >>
> >>
> >> -----Original Message-----
> >> From: Adrian Farrel [mailto:[e-mail]]
> >> Sent: Thursday, January 29, 2015 7:24 AM
> >> To: Leeyoung; 'Varma, Eve L (Eve)'; [e-mail]; 'Lam, Hing-Kam
> >> (Kam)'; [e-mail]; [e-mail]
> >> Cc: [e-mail]; [e-mail];
> >> [e-mail];
> >> [e-mail]
> >> Subject: RE: [CCAMP] Vendor-Specific Application Code in
> >> draft-ietf-ccamp-rwa-wson-encode
> >>
> >> Hi again,
> >>
> >>> There is always a priori knowledge in optical network domain as to
> >>> who are you interfacing with. So you know which vendor you are
> interfacing.
> >>> If you do not know, then you are in trouble.
> >>
> >> Hmmm. It is exactly type of trouble we are trying to detect and protect
> against.
> >>
> >> I refute your statement of a priori knowledge. I think there is a priori
> intention, but not knowledge. Unless you have very good eyesight or
> someone at the other end of the fiber when you give it a tug, you don't
> know. And even then. Fibering errors happen from time to time. Consider, in
> particular a patch panel.
> >>
> >>> Now, what is the purpose of standard FECs and modulations in the AI?
> >>> Given several choices each vendor may support in its device, the
> >>> path computation would find a matched types for FEC and modulation
> for a given optical path.
> >>> This is what is intended when optical signal processing constraints
> >>> were proposed as part of path computation constraints in optical
> networks.
> >>
> >>
> >> The case you are making here is for no standard control plane!
> >> What is the point of standardising if there is never any interworking?
> >> But actually, we know about interworking at the physical layer, and (more
> important) we know about a single, end-to-end control plane that spans
> multiple vendor devices. It all exists.
> >>
> >> Of course, we can fall back into the old-style vendor islands, and many
> like to do so. But it is not a compulsory deployment model.
> >>
> >>> There is very little chance for vendor specific FECs and Modulations
> >>> will match even if they are identified with the OUI code.
> >>
> >> You have it the wrong way round!
> >> The OUI is largely to protect against expectations of interworking when
> none can exist.
> >> It might (much less frequently) be used to describe the way that vendorA
> and vendorB pick FECs and modulations in order to achieve interworking.
> >>
> >> Adrian
> >>
> >> _______________________________________________
> >> CCAMP mailing list
> >> [e-mail]
> >> https://www.ietf.org/mailman/listinfo/ccamp
> >>
> >
> > _______________________________________________
> > CCAMP mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/ccamp
> >
> 
> _______________________________________________
> CCAMP mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ccamp