Re: [Dots] Alissa Cooper's Discuss on draft-ietf-dots-signal-channel-31: (with DISCUSS and COMMENT)

[<[e-mail]>]

Re-,

Please see inline.

Cheers,
Med

> -----Message d'origine-----
> De : Benjamin Kaduk [mailto:[e-mail]]
> Envoyé : lundi 6 mai 2019 19:12
> À : BOUCADAIR Mohamed TGI/OLN
> Cc : Alexey Melnikov; [e-mail]; Alissa Cooper;
> [e-mail]; Liang Xia; The IESG; [e-mail]
> Objet : Re: Alissa Cooper's Discuss on draft-ietf-dots-signal-channel-31:
> (with DISCUSS and COMMENT)
> 
> On Thu, May 02, 2019 at 08:30:51AM +0000, [e-mail] wrote:
> > Re-,
> >
> > Actually, there is no interoperability problem.
> 
> The reference to both draft-ietf-core-yang-cbor and RFCs 7951+7049 presents
> an attractive nuisance of an interoperability problem; to say that "both
> approaches produce a valid encoding" without qualifier that an extra
> consultation to tables 4 and 6 is grossly misleading.
> 
> > The implementers do only need to look at tables 4 and 6:
> 
> If that's what they have to do, you need to point them there, instead of
> just the "normal" ways to go from YANG to CBOR.

[Med] I made this change: 

OLD: 
   This document specifies a YANG module for representing DOTS
   mitigation scopes, DOTS signal channel session configuration data,
   and DOTS redirected signalling (Section 5).  Representing these data
   as CBOR data can either follow the rules in [I-D.ietf-core-yang-cbor]
   or those in [RFC7951] combined with JSON/CBOR conversion rules in
   [RFC7049]; both approaches produce a valid encoding.  All parameters
   in the payload of the DOTS signal channel are mapped to CBOR types as
   specified in Section 6.

NEW:
   This document specifies a YANG module for representing DOTS
   mitigation scopes, DOTS signal channel session configuration data,
   and DOTS redirected signaling (Section 5).  All parameters in the
   payload of the DOTS signal channel are mapped to CBOR types as
   specified in Table 4 (Section 6).

> 
> -Ben
> 
> >    All parameters in the payload of the DOTS signal channel MUST be
> >    mapped to CBOR types as shown in Table 4.
> >
> > Cheers,
> > Med
> >
> > > -----Message d'origine-----
> > > De : Alexey Melnikov [mailto:[e-mail]]
> > > Envoyé : jeudi 2 mai 2019 10:20
> > > À : BOUCADAIR Mohamed TGI/OLN
> > > Cc : Alissa Cooper; The IESG; [e-mail];
> Liang
> > > Xia; [e-mail]; [e-mail]
> > > Objet : Re: Alissa Cooper's Discuss on draft-ietf-dots-signal-channel-31:
> > > (with DISCUSS and COMMENT)
> > >
> > > Hi,
> > >
> > > On 2 May 2019, at 08:18, <[e-mail]>
> > > <[e-mail]> wrote:
> > >
> > > >> = Section 13.1 =
> > > >>
> > > >> I don't understand why RFC 7951 is a normative reference but
> > > >> draft-ietf-core-yang-cbor is an informative reference.
> > > >
> > > > [Med] We used to have both as informative references, but unless I'm
> > > mistaken 7951 was moved to normative so that at least one method is
> > > supported.
> > >
> > > As other IESG reviewers pointed out (better than my own description),
> having
> > > 2 non identical ways to encode the same information is going to cause
> > > interoperability problems. It also forces implementations to support both
> > > encodings and it makes draft-ietf-core-yang-cbor Normative.
> > >
> > > I would encourage the WG to pick one mechanism. If it ends up being
> draft-
> > > ietf-core-yang-cbor, I am happy to progress it quick. (CORE WG is one of
> the
> > > WGs I am responsible for)
> > >
> > > Best Regards,
> > > Alexey
> >