Re: [Yot] contents of SID registration authority

[peter van der Stok <[e-mail]>]

Thanks Michel,

Do I understand correctly, that for yang modules which are planned to be 
part of a future RFC,
the authors are encouraged to do a provisional SID allocation from the 
ietf range
which becomes finalized after RFC publication.

two remarks:
If my interpretation is correct, the text needs some clarification.
Secondly, how to make a difference between provisional and final?

Slowly, the feeling creeps on me that we need a IANA validation 
somewhere on the route.

Many thanks for all your explanations. Going through the SID allocation 
process is really educational.

Greetings,

peter

Michel Veillette schreef op 2018-02-14 21:07:
> Hi Peter
> 
> === About "remove ietf-restconf@2016-08-15 because there is already an
> ietf-restconf@2017-01-26 owned by ietf"
> 
> ietf-restconf is imported by other YANG modules.
> To automatically resolve these imports, it is more convenient to keep
> this module in the SID registry.
> Furthermore, the SID assigned to the ietf-restconf module can be used
> in the yang library
> (https://datatracker.ietf.org/doc/draft-veillette-core-yang-library/)
> The new version of ietf-restconf should be added however.
> 
> === About " What is the policy for drafts that become rfcs? will they
> be entered automatically?
> The latter will mean that the originally attributed SIDs are replaced
> with the values from the ietf range?"
> 
> The second bullet in
> https://tools.ietf.org/html/draft-ietf-core-sid-03#section-6.1.1
> address this topic.
> In summary, we allows final SIDs allocation after working group 
> adoption.
> In this case, the transition to RFC have no impacts.
> 
>    o  The range of 1000 to 59,999 is reserved for YANG modules defined
>       in RFCs.  The IANA policy for future additions to this sub-
>       registry is "RFC required" [RFC5226].  Allocation within this
>       range requires publishing of the associated ".yang" and ".sid"
>       files in the YANG module registry.  The allocation within this
>       range is done prior to the RFC publication but should not be done
>       prior to the working group adoption.
> 
> Regards,
> Michel
> 
> -----Original Message-----
> From: peter van der Stok [mailto:[e-mail]]
> Sent: Wednesday, February 14, 2018 5:20 AM
> To: Michel Veillette <[e-mail]>; Michael
> Richardson <[e-mail]>
> Subject: contents of SID registration authority
> 
> Hi Michel and Michael,
> 
> I looked at the contents of SID registration authority.
> 
> I have the following suggestions for mcr314 entries:
> - Replace ietf-voucher@2017-10-25 by ietf-voucher@2018-01-24; better
> would be to have an ietf version which is updated with the latest
> version.
> - remove ietf-restconf@2016-08-15 because there is already an
> ietf-restconf@2017-01-26 owned by ietf
> 
> What is the policy for drafts that become rfcs?; will they be entered
> automatically?
> The latter will mean that the originally attributed SIDs are replaced
> with the values from the ietf range?
> 
> Greetings,
> 
> Peter
> 
> --
> Peter van der Stok
> vanderstok consultancy
> mailto: [e-mail]
> www: www.vanderstok.org
> tel NL: [phone]     F: [phone]