Re: [homenet] Kathleen Moriarty's Discuss on draft-ietf-homenet-hncp-09: (with DISCUSS)

[Mark Andrews <[e-mail]>]

In message <[e-mail]>, Ted Lemon writ
es:
>
> Thursday, Nov 19, 2015 1:49 AM Brian E Carpenter wrote:
> >> Just to clarify, mandatory to implement doesn't mean you have to write
> >> the code.   It means the functionality has to be present in the deployed
> >> implementation so that two communicating partners can be configured to
> >> use it.
> >
> > Um, where is that defined? Is there a BCP that says that?
>
> It's not codified into law, but what else could it mean?   Why would we
> specify something as mandatory to implement if an expression of that
> implementation in running code did not actually contain the
> implementation?
>
> > I don't think a protocol spec can say that feature X cannot be ifdeffed.
> > It can say that a protocol must be capable of X and that implementations
> > must therefore be capable of X. But if you tell implementors that they
> > can't
> > ifdef unused stuff when building images for highly constrained nodes, I
> > don't think they will take you seriously.
>
> The protocol spec would just say MUST implement.   If the implementor
> wants to conditionalize the compilation of the code, we can't stop them
> from doing that, but then they don't have an implementation of the
> specification, and they shouldn't say "supports RFC XXX".   "supports RFC
> XXX" means that anything that is specified in the RFC is asserted to be
> functional in the implementation.
>
> They can perfectly well say "supports a subset of RFC XXX," and I can't
> imagine that anybody would object to that.

Unless they say what the subset they support / don't support, then
I object.  "partial support" is meaningless unless it is qualified.

> --
> Sent from Whiteout Mail - https://whiteout.io
> 
> My PGP key: https://keys.whiteout.io/mellon@fugue.=
> com
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: [phone]                 INTERNET: [e-mail]