From: netmod <[email protected]> on behalf of Esko Dijk
<[email protected]>
Sent: 30 March 2020 12:17
<tp>
Picking up on the early allocation and tweaking the title slightly so the other
points do not get lost
Hello CoRE,
I did a quick review of the -sid-11 draft; it looks ready for publication. Some
minor issues found :
Reference to RFC 7120 early allocation procedure: the allocation policies for
the registries are all "Expert review". And the RFC 7120 early allocation
procedure is defined, to do early allocations. However RFC 7120 mentions that
this procedure only applies in case :
(Section 2)
a. The code points must be from a space designated as "RFC
Required", "IETF Review", or "Standards Action". Additionally,
requests for early assignment of code points from a
"Specification Required" registry are allowed if the
specification will be published as an RFC.
So at first sight it looks like the procedure is not applicable, taken
strictly. However IANA indicates
(https://www.iana.org/help/protocol-registration) that "Expert review" is part
of "Specification Required" so it would apply still. But in RFC 8126 this is
not mentioned in the same manner - so it could confuse some readers about
whether it applies or not. Maybe some text could be added to state why RFC 7120
process does apply to the "Expert review" policy, even though "Expert review"
is not listed under Section 2 point a. of RFC 7120. (Note that early
allocation by RFC 7120 only applies to "Expert review" allocations for draft
documents that aim to become RFC.)
<tp>
I think that early allocation and expert review are not compatible.
I see a lot of early allocation in the Routing Area. An I-D is adopted, code
gets written, interop needs agree values so the authors ask the WG chairs for
early allocation, WG Chairs ask the WG, all being well the request goes to the
AD, who reviews the request and all being well OKs it to IANA, where it is
marked as temporary expiring in a year. The I-D wends its way and may take a
long time to become an RFC, over a year may be (early allocation gets renewed)
but the code does not need changing and goes into production.
With expert review, the expert reviews the request and if the criteria
specified when the registry was set up are met, the request is granted; takes
weeks, may be days, no hanging around, as quick as an early allocation would be
or quicker since no AD, no WG Chairs are involved.
The only hiccup would be now, before the I-D setting up the registry is
approved, since it could be months, a year even, before an RFC emerges and
until then no expert review is possible. But until that RFC is approved, at
least until the IESG have approved it, there is no authority for expert review
and indeed IETF Last Call or IESG Review may say that expert review is too
lightweight and must not be allowed for the registry in question.
So I cannot see a reason to combine early allocation and expert review even if
the relevant IANA RFC do not make it clear that this is not a logical
combination.
Tom Petch
Section 6.3.3: table column 1 is very narrow and it breaks the entry point
integer number, which is confusing. Why not make this column wider by one
character? One of the last 2 columns can be made more narrow if needed.
Section 3: "RESCONF" -> RESTCONF
Section 3: CoRECONF -> CORECONF
Section 3: "For example how this could be achieved, please refer to"
-> For examples on how this could be achieved, please refer to
Section 3: "For diagram of one"
-> For a diagram of one ...
Best regards
Esko
IoTconsultancy.nl | Email/Skype: [email protected]
-----Original Message-----
From: core <[email protected]> On Behalf Of Carsten Bormann
Sent: Monday, March 9, 2020 14:05
To: core <[email protected]>
Cc: [email protected]
Subject: [core] π WG Last Call of CORECONF drafts:
draft-ietf-core-yang-cbor-12, -sid-11, -comi-09, -yang-library-01
It took us a long time to get the four CORECONF drafts in sync,
but now we are ready for WGLC.
This starts a working group last call for
β draft-ietf-core-yang-cbor-12
β draft-ietf-core-sid-11
β draft-ietf-core-comi-09
β draft-ietf-core-yang-library-01
ending on
24:00 UTC on Tuesday, March 31, 2020.
(This includes some extra time for the IETF week and for cross-WG
coordination.)
This WGLC is copied to the netmod WG mailing list; please do have a look
at these drafts as they are slated to become a part of the greater
YANG/NETCONF/RESTCONF family. We intend the discussion to be on the
CoRE mailing list, but if you find a fundamental issue with YANG or
RESTCONF, feel free to discuss that on netmod instead.
Please start a new email thread for each major issue that will need
discussion and make sure the subject line includes the draft name and
some sort of name for the issue. (Minor issues such as typos can also
be sent to the authors.)
If you read the draft and think it looks fine, please send a one line
email to the list or to the chairs letting us know that so we can get
a feel of how broad the review has been.
(To reviewers and authors:) If you are aware of any patent claims that
might apply to systems that implement these drafts, please review BCP 78
and BCP 79 and make any appropriate IPR declaration before the last-call
ends. If you are not sure whether you need to make a declaration or not,
please talk to the chairs and we will help.
GrΓΌΓe, Carsten
_______________________________________________
core mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/core
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
