Subject: Re: [Yot] contents of SID registration authority

From: Michel Veillette <[email-masked]>
Date: Wed, 14 Feb 2018 20:07:18 +0000

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:[email-masked]] 
Sent: Wednesday, February 14, 2018 5:20 AM
To: Michel Veillette <[email-masked]>; Michael Richardson <[email-masked]>
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: [email-masked]
www: www.vanderstok.org
tel NL: +31(0)492474673     F: +33(0)966015248

---

From: peter van der Stok <[email-masked]>
Date: Thu, 15 Feb 2018 09:28:52 +0100

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:
> 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 second bullet in
> https://tools.ietf.org/html/draft-ietf-core-sid-03#section-6.1.1
> address this topic.
> - 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.

---

From: Michel Veillette <[email-masked]>
Date: Thu, 15 Feb 2018 15:03:14 +0000

Hi Peter

Yes, the recommendation is to perform the provisional SID allocation at or just after working group adoption.
Would you please propose a clarification text to clarify this policy.

Regards,
Michel

-----Original Message-----
From: peter van der Stok [mailto:[email-masked]] 
Sent: Thursday, February 15, 2018 3:29 AM
To: Michel Veillette <[email-masked]>
Cc: [email-masked]; [email-masked]; Michael Richardson <[email-masked]>
Subject: Re: contents of SID registration authority

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 allocation from the ietf range which becomes finalized after RFC publication.

two remarks:

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

---

From: peter van der Stok <[email-masked]>
Date: Thu, 15 Feb 2018 16:21:24 +0100

Concerning:

My pleasure beginning next week; will also prepare some voucher examples

cheerio,

peter

Michel Veillette schreef op 2018-02-15 16:03:
> 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 allocation
> from the ietf range which becomes finalized after RFC publication.
> 
> two remarks:
> Many thanks for all your explanations. Going through the SID
> allocation process is really educational.
> 
> Greetings,
> 
> peter
>

---

From: peter van der Stok <[email-masked]>
Date: Mon, 19 Feb 2018 11:27:52 +0100

Hi Michel,

I read the core-sid draft, and saw that indeed there is a IANA registry 
called "SID mega-range" and another called
"YANG module assignment".
That simplifies things. Good.
some text enhancements below:

>>       in RFCs.  The IANA policy for future additions to the "SID 
>> mega-range" sub-
>>       registry is "RFC required" [RFC5226].
All RFC-based YANG modules SHOULD allocate SID values and register them 
in "SID mega-range" registry.
          It is required to register the associated ".yang" and ".sid"
>>       files in the "YANG module assignment" registry.  The allocation 
>> within this

Question:
Suppose after WG adoption SID are allocated in the IETF range. During 
the draft development the number of required SIDS changes radically and 
a new allocation is required.

How is that going to be handled? Will there be holes in the allocated 
SID value range?

Greetings,

Peter

---

From: Michael Richardson <[email-masked]>
Date: Mon, 19 Feb 2018 12:27:22 -0500

> Question:
    > Suppose after WG adoption SID are allocated in the IETF range. During the
    > draft development the number of required SIDS changes radically and a new
    > allocation is required.

    > How is that going to be handled? Will there be holes in the allocated SID
    > value range?

I thought that IANA would allocate mega-ranges only.
One mega-range is to be allocated to comi-space for IETF WG use.
Other mega-ranges would be allocated to other SDOs (IEEE, Wifi alliance,
etc.) for use in their specifications.

Whether there are gaps in the mega-ranges is up to IANA.
Whether there are gaps in the IETF range is up to comi.space code.

I think it's reasonable if a specification outgrows the range before RFC that
it would just get reallocated into a new range and the old range recycled
after a period of time (6 months maybe).

It is my impression that the operation of comi.space would be turned over
either IANA or the IETF secretariat or some other contractor. All of this
under IAOC tools team oversight.

-- 
]               Never tell me the odds!                 | ipv6 mesh networks [ 
]   Michael Richardson, Sandelman Software Works        | network architect  [ 
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [

---

From: Andy Bierman <[email-masked]>
Date: Mon, 19 Feb 2018 09:52:21 -0800

> under IAOC tools team oversight.

There already is a set of registries managed by IANA for YANG module
information.
The SID range and/or official SID file need to be added to the YANG Module
Registry.
This takes care of assignments in RFCs.

For those that want to utilize the churn that is work-in-progress, there is
no stability.
Anything can happen and developers are on their own.  Opensource will have
to
provide a solution.

Andy

> _______________________________________________
> Yot mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/yot
>
>

---

From: Michael Richardson <[email-masked]>
Date: Mon, 19 Feb 2018 14:08:19 -0500

Andy Bierman <[email-masked]> wrote:
    mcr> It is my impression that the operation of comi.space would be
    mcr> turned over
    mcr> either IANA or the IETF secretariat or some other contractor. All
    mcr> of this
    mcr> under IAOC tools team oversight.

    > There already is a set of registries managed by IANA for YANG module

Yes, but this is something additional.

    > The SID range and/or official SID file need to be added to the YANG
    > Module Registry.

Section 6.1.1
says:

   The range of 100,000 to 999,999 is reserved for standardized YANG
   modules.  The IANA policy for future additions to this sub-
   registry is "Specification Required" [RFC5226].  Allocation within
   this range requires publishing of the associated ".yang" and
   ".sid" files in the YANG module registry.

It is my impression that Internet-Drafts authors can come to comi.space
and ask for an allocation based upon a SID/YANG file.  And since publication
of the RFC satisfies "Specification Required", that they can keep that
allocation.  That they don't need to move/wait for RFC to move to the 
<60,000 range.

There was a thread about where/when a document should ask: upon personal -00,
upon WG adoption -00, WGLC, ?    The intention is, I understand, to be as
light weight as possible.

-- 
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Michel Veillette <[email-masked]>
Date: Mon, 19 Feb 2018 21:20:45 +0000

About "During the draft development the number of required SIDS changes radically and a new allocation is required."

During the development, the authors have two options.

1) Stay backward compatible by updating the previous .sid file.
   In this case, previously assigned SIDs are preserved.
   Data nodes can be deprecated but not deleted as mandated by RFC7950 section 11.
   "Obsolete definitions MUST NOT be removed from published modules"

2) Restarting from scratch by generating a brand new .sid file.
    In this case, a completely new set of SIDs is generated.

Regards,
Michel

-----Original Message-----
From: peter van der Stok [mailto:[email-masked]] 
Sent: Monday, February 19, 2018 5:28 AM
To: Michel Veillette <[email-masked]>
Cc: [email-masked]; [email-masked]; Michael Richardson <[email-masked]>
Subject: Re: contents of SID registration authority

Hi Michel,

I read the core-sid draft, and saw that indeed there is a IANA registry called "SID mega-range" and another called "YANG module assignment".
That simplifies things. Good.

>>       registry is "RFC required" [RFC5226].
All RFC-based YANG modules SHOULD allocate SID values and register them in "SID mega-range" registry.
          It is required to register the associated ".yang" and ".sid"
>>       prior to the working group adoption.

Question:
Suppose after WG adoption SID are allocated in the IETF range. During the draft development the number of required SIDS changes radically and a new allocation is required.

How is that going to be handled? Will there be holes in the allocated SID value range?

Greetings,

Peter

---

From: peter van der Stok <[email-masked]>
Date: Tue, 20 Feb 2018 09:12:07 +0100

Hi Michel,

My suggestion is the following:

Assign a pool of provisional ietf SIDs. When working on a WG draft, 
these can be used.
Once transfer to RFC starts; return the provisional SIDs and allocated 
definite ietf SIDs.

Peter

Michel Veillette schreef op 2018-02-19 22:20:
> About "During the draft development the number of required SIDS
> changes radically and a new allocation is required."
> 
> I read the core-sid draft, and saw that indeed there is a IANA
> registry called "SID mega-range" and another called "YANG module
> assignment".
> the draft development the number of required SIDS changes radically
> and a new allocation is required.
>