Re: [core] Robert Wilton's Discuss on draft-ietf-core-sid-16: (with DISCUSS and COMMENT)

["Rob Wilton (rwilton)" <[e-mail]>]

Hi Carsten,

Apologies for my delayed reply, please see inline ...

> -----Original Message-----
> From: Carsten Bormann <[e-mail]>
> Sent: 19 November 2021 00:12
> To: Rob Wilton (rwilton) <[e-mail]>
> Cc: The IESG <[e-mail]>; [e-mail]; core-
> [e-mail]; [e-mail]; [e-mail]
> Subject: Re: Robert Wilton's Discuss on draft-ietf-core-sid-16: (with DISCUSS
> and COMMENT)
> 
> Hi Rob,
> 
> We have prepared an updated core-sid document at:
> 
> https://datatracker.ietf.org/doc/draft-ietf-core-sid/
> https://www.ietf.org/archive/id/draft-ietf-core-sid-18.html
> https://www.ietf.org/rfcdiff?url2=draft-ietf-core-sid-18.txt
> 
> > On 2021-07-13, at 17:59, Robert Wilton via Datatracker <[e-mail]>
> wrote:
> > […]
> > ----------------------------------------------------------------------
> > DISCUSS:
> > ----------------------------------------------------------------------
> >
> > Hi,
> >
> > Thank you for this work, I believe that it likely to be useful, perhaps not
> > only for constrained devices, it may also turn out to be popular for
> streaming
> > telemetry.
> >
> > There are a couple of points that I would like to see discussed and perhaps
> > addressed:
> >
> > (1) I would like further discussion regarding whether SIDs are bound just to
> > the schema name, or the schema item definition.  The draft states that if
> the
> > definition is changed in a non-backwards-compatible (NBC) way then a new
> SID
> > SHOULD be allocated.  But I don't understand how this will work.  Given
> that
> > the .sid file would then contain exactly the same path but with different
> sids
> > assigned (for every time the meaning of the definition changes), then how
> do
> > consumers of the sid file know which sid to use for a given path (given that
> > there is no indication in the .sid file)?  Instead, I think that this is the
> > wrong way to be handling NBC changes, and SIDs should be bound only to
> the
> > schema path (i.e., the name of the item), and a new SID is only allocated if
> > the name/path changes, and otherwise the same SID is used, even if the
> > definition changes in a non-backwards-compatible way.
> 
> We have toned down the need for allocating a new SID quite a bit; see
> updated appendix B.
> The point of the text here is to say that existing allocations stay in place; the
> exceptions listed in Appendix B notwithstanding.
> 
> Now it seems to me that you are arguing for a more mechanistic rule:
> essentially a bijection between SIDs and (namespace, name) pairs.  This takes
> away the possibility to “optimize” the renaming of an identifier by keeping a
> SID, or a change in the semantics of a name by allocating a second SID.  But
> the rule would sure be simpler, and taking away some of the discretion now
> afforded in Appendix B by creating a simple mechanism.

Splitting my two concerns:

(1) I understand the desire to allow optimization by renumbering, particularly between initial development and first publication, and I'm not completely opposed to this, but I can also foresee that it may make some interop issues trickier.

E.g., consider a controller that understands two SID values for a given leaf, configuring two devices, each of which only understand one of the SID values.  The controller can easily be setup to receive data using either SID value, but when sending configuration would need to have a per client SID mapping.  Hence, my question is whether that extra complexity is worth it?  Or perhaps there should be a rule that clients MUST always accept the original published SID value?  But this then places an ordering between SID definitions and would seem to make initial development SIDs permanent. 

(2) I have a much bigger concern with conflating the SID with the data node definition/type, rather than the SID just being an alternative more efficient numeric representation of the (namespace, name) pair.  I think that it effectively means that your SID becomes a binding to (namespace, name, fet of module revisions).  I basically think that doing this would be a mistake and should be avoided.  Some potential issues:

 A) Should new SIDs be allocated every time the data node definition changes, or only sometimes? 
  (i) If only sometimes, then each SID needs to be map to (namespace, name, set of module revisions/versions), how would this mapping be maintained/updated?
  (ii) If every time, then you have a similar mapping issue as per (i), only a single revision, but may also get a proliferation of SID values for the same logical path.
 B) Each YANG server only implements a single revision of a YANG module, and hence a single definition of a particular YANG data node.  What happens if a server states that it's using module revision X, but then receives a SID that is bound to the leaf definition in a different module revision Y.  Presumably the only thing that it can do is treat that as an unknown identifier/SID.  Possibly it also opens up further possible issues between conflating the SID 
 C) If you had a middlebox translating between SIDs and Names then it would also need to know the schema revision information to perform the translation correctly.


> 
> (It would not be a very strict bijection — anyone can create a SID file for a
> module where one already exists, out of ignorance, malice, or technical
> reasons; the expectation is that owners of modules will want to make sure
> their SID file is prominent.)
> 
> > (2) I think that this document should be clearer as to the relationship
> between
> > SIDs and submodules (more details in the comment).
> 
> We essentially removed submodules from the document (well, they are still
> in the term import list, because the parallel yang-cbor document needs to
> say:
> 
> >> Note that any structuring of modules into submodules is transparent to
> YANG-CBOR:
> >> SIDs are not allocated for the names of submodules, and any
> >> items within a submodule are effectively allocated SIDs as part of
> >> processing the module that includes them.
> 
> ).

Yes.


> 
> >
> > (3) This draft makes use of the rc:yang-data extension.  Was there any
> > discussion about using "YANG Data Structure Extensions" (RFC 8791)
> instead,
> > which is meant to be a cleaner formulation of the rc:yang-data extension,
> and
> > without the dependency on RESTCONF?  I would suggest that using RFC
> 8791 would
> > be preferable if possible.
> 
> We changed the ietf-sid-files module to use sx:structure (RFC 8791).
> https://github.com/core-wg/yang-cbor/pull/116
> (I don’t think we can validate the sid file example against the module after
> that change.
> Can we?)

Thanks.  IIRC, unfortunately I don't think that you can currently easily validate the sid file against the module afterwards, I think that we need the tooling to still catch up.

I think that you need to fix/change the reference in section 4 from RFC 8040 to RFC 8791.

Whilst checking this, I did notice that the SID document doesn't make use of draft-ietf-netmod-yang-instance-file-format, which is in the RFC Editor Queue.  Sorry I should have spotted this before.  I suspect that it is too late to change this but wanted to flag this in the case the reason that  it wasn't being used is because the CORE WG was not aware of its existence.


> 
> (The above is about the core-sid documents’s *use* of rc:yang—data
> migrating to sx:structure.
> As far as showing sx:structure examples with encoding over in the yang-cbor
> document:
> We plan to instead set up another follow-on document with such examples,
> rules for encoding metadata, etc.)
> 
> > (4) The policy in 7.4.2 for allocation a SID mega-range seems to aiming this
> > towards organizations rather than individuals.  The policy in 7.6 for the
> "IETF
> > YANG SID Registry" requires an RFC.  What is the mechanism if an
> individual or
> > open source project wanted to get SIDs assigned for some of their YANG
> modules?
> > I.e., should we be defining a separate mega-range, managed by IANA, with
> just
> > Expert Review or Specification Required so that these modules could use
> SIDs
> > allocated?  Or do you envisage a separate entity taking up the responsibility
> > for coordinating this?
> 
> The mega-range concept means there can be more than one such entity.
> https://comi.space is a proof of concept for how such an entity could
> operate.
> I’d expect at least one of the organizations in the YANG ecosystem to pick this
> up and become such an entity.
> Whether IANA also wants to be such an entity (beyond its role for IETF
> modules), I don’t know.
> To demonstrate that we are entirely on the safe side, I’ve also written a PoC
> for a organization-less approach (leveraging IANA PENs):
> https://datatracker.ietf.org/doc/draft-bormann-core-yang-sid-pen/
> I’m not sure we want to pursue this; the advantage is a low-threshold (and
> low-disclosure!) way to get a sizable SID space; the disadvantage is that we
> would lose people who otherwise would have used services such as
> comi.space that make the registrations much more useful to the community.

Okay.  I agree that having these registrations managed, and ideally the publicly available in a machine reachable way will probably end up being important.

But I agree that this doesn't need to solved here and now in this document.


> 
> > ----------------------------------------------------------------------
> > COMMENT:
> > ----------------------------------------------------------------------
> >
> > 1. Regarding the relationship between sids and submodules, I think is best
> > summed up by this comment in the appendix: "Note that ".sid" files can
> only be
> > generated for YANG modules and not for submodules."  I.e., I don't think
> that
> > sids should be allocated for the name of the submodule, and any items
> within a
> > submodule are effectively allocated sids as part of processing the module
> that
> > includes them.  This topic should be addressed early in the document, and
> > probably the existing references to submodule in the introduction and the
> YANG
> > module can be removed.
> 
> See above.
> Do we still need text here, or is the text over in yang-cbor sufficient?

I would think that the text in yang-cbor should be sufficient.

Thanks,
Rob


> 
> Grüße, Carsten
>