Re: [OPSAWG] WG consensus call for the IANA early assignment //RE: Adoption poll for draft-lear-ietf-netmod-mud-04

[joel jaeggli <[e-mail]>]

Thanks,

I'll open up a line of disucssion with iana on this.

regards
joel

On 10/20/16 12:30 PM, Warren Kumari wrote:
> So, we chatted with our AD (CCed).
> He feels that RFC 7120 is clear enough that he can just request early
> allocation using the draft.
> 
> So, the chairs believe that there is sufficient consensus to request these.
> 
> Thanks y'all, and a reminder that we still have OpsAWG agenda time --
> if you have a document **which has been discussed AND would benefit
> from meeting time** please let us know.
> 
> Please include talk title & how much time you *need*.
> 
> 
> 
> If you want to mail the chairs alias directly instead, please include
> "[SCHEDULE]" in the email subject - we get lots of mail before
> meetings, and don't want any agenda requests to slip through the
> cracks.
> 
> If we happen to have some extra time at the end of the meeting we
> *may* allow presentations on new work, but in general we require that
> the draft has been published and has had significant discussion on
> list, so make sure you publish and get feedback early.
> 
> Thanks,
> W
> 
> A few reminders / tips to help your presentation be effective:
> ----------------------------------------------------------------------
> 1: Please rehearse your talk, make sure that it fits within the
> allocated time slot, and that you have left some time for questions.
> It is very impolite to the working group to run over your allocated
> time, and we are likely to simply cut you off if you do.
> 
> 2: We require slides at least *3* days before the meeting; you can
> revise them after this point if needed. Please include the version
> number on the first page of the slide deck. Please send them to the WG
> chairs alias - sending them to just one of us leads to confusion.
> 
> 3: Please send these in PDF format - we’ve had a number of instances
> where the convertor doesn’t handle certain fonts, etc and the
> presenter becomes sad.
> 
> 4: Please include slide numbers on all slides - it’s much easier to
> ask someone to go back to slide number 5 than “the slide that was a
> couple after the second diagram… no, not that one, the next one… erm…
> next?"
> 
> 5: Slides are a summary of what you want to say - please don’t just
> put everything on the slides and read them verbatim (we all know how
> to read!)
> 
> 
> 
> On Sat, Oct 8, 2016 at 1:52 PM, Warren Kumari <[e-mail]> wrote:
>> Hi all,
>>
>> So, reviving this thread...
>>
>> I think that there is sufficient merit to request early allocations
>> according to RFC7120 criteria.
>> Please note that if we request early allocations, it is good for one
>> year, renewable once. Assuming that the document progresses within
>> that two year timeframe to become and RFC, the IANA will convert the
>> early allocations into a permanent one -- if we don't, it will
>> automatically expire and be marked as such in the registry (or, if the
>> WG decided that they want to abandon this work, we can request that
>> they be released early). While the document is still in flux, the
>> parts around the allocations should be stable.
>>
>> The majority of the requests are for allocations from large (or
>> unlimited) code-spaces, and so it does not seem like there is
>> scarcity. The exception is the DHCPv4
>> (http://www.iana.org/assignments/bootp-dhcp-parameters/bootp-dhcp-parameters.xhtml#options);
>> the v4 option space is 8bit, and ~68 (or, around a quarter) are
>> unassigned. The IPv6 option space is 16bit (65535 entries) and so
>> close to unlimited.
>>
>> Because I am not at all familiar with the sensitivity / implications
>> of the registrations in the various registries, I'm planning on asking
>> an expert reviewer from each of the below registries to please take an
>> early (before early allocation!) look at the document / relevant parts
>> of the document to confirm that we are doing the right thing, that
>> there isn't a more appropriate sub-registry, etc.
>>
>> "SMI Security for PKIX Certificate Extension" Registry
>> (http://www.iana.org/assignments/smi-numbers/smi-numbers.xhtml#smi-numbers-1.3.6.1.5.5.7.1)
>> - "id-pe-mud-uri"; Registration Procedure: Specification Required.
>> The IANA considerations for this say: "The expert is expected to
>> ensure that any new values are strongly related to the work that was
>> done by the PKIX Working Group.  That is, additional object
>> identifiers are to be related to X.509 certificates, X.509 attribute
>> certificates, X.509 certificate revocation lists (CRLs), or protocols
>> associated with them. Object identifiers for other purposes should not
>> be assigned in this arc.", so it is unclear if this is the appropriate
>> place for this, but perhaps Russ can suggest a better location /
>> system.
>>
>> Well Known URIs
>> (http://www.iana.org/assignments/well-known-uris/well-known-uris.xhtml)
>> - "mud";  Registration Procedure: Expert Review, mnot.
>>
>> MIME Media-type Registration
>> (http://www.iana.org/assignments/media-types/media-types.xhtml) -
>> "application/mud+json"; For allocations under the "Standards Tree
>> requests made through IETF documents will be reviewed and approved by
>> the IESG..." - this sounds like 'IESG Approval', but I'm planning on
>> asking our AD, Ned and / or Murray.
>>
>> Well Known Universal Resource Name (URNs)
>> (http://www.iana.org/assignments/urn-namespaces/urn-namespaces.xhtml)
>> - "urn:mud" ; Registration Procedure: IETF Consensus.
>>
>> The final issue is the creation of a registry for "IANA Link Layer
>> Discovery Protocol (LLDP) TLV subtype values" - this would create a
>> registry under the IANA OUI, as a "vendor-specific TLV". It appears
>> that there currently is no registry under the IANA vendor specific OUI
>> for LLDP, and this is creates an 8 bit registry. I'm *assuming* that
>> we could have something like 1-253 are useable, and 254 can later be
>> defined to be an "extension", but I'd like to get some additional
>> feedback. https://tools.ietf.org/html/rfc7042 seems to be the closest
>> that I could find.....
>>
>> The "IANA Considerations" section of the document also needs some
>> polishing -- it would be nice if it pointed more definitely at the
>> registry from which it is making requests, if the "{{secon}}" label
>> expanded, and if the formatting of the URN bit were better.
>>
>>
>> So, does anyone object to this plan? If so, please let us know by
>> October 13th If not, the chairs will reach out to our AD / the
>> Designated Experts as described above.
>>
>> On Tue, Aug 30, 2016 at 9:47 PM, Zhoutianran <[e-mail]> wrote:
>>> Hi Kent,
>>>
>>> Here are some words copied from RFC 7120. I think they can address your question.
>>>
>>> Request:
>>> 6. IANA makes an allocation from the appropriate registry, marking
>>> it as "Temporary", valid for a period of one year from the date
>>> of allocation. The date of first allocation and the date of
>>> expiry are also recorded in the registry and made visible to the
>>> public.
>>>
>>> Follow up:
>>> If the document progresses to the point at which IANA normally makes
>>> code point allocations, it is the responsibility of the authors and
>>> the WG chairs to remind IANA that there were early allocations and of
>>> the code point values allocated in the IANA Considerations section of
>>> the RFC-to-be. Allocation is then just a matter of removing the
>>> "Temporary" tag from the allocation description.
>>>
>>> Expiry:
>>> If an early allocation expires before the document progresses to the point where
>>> IANA normally makes allocations, the authors and WG chairs may repeat
>>> the process described in Section 3.1 to request renewal of the code
>>> points. At most, one renewal request may be made; thus, authors
>>> should choose carefully when the original request is to be made.
>>>
>>> If a follow-up request is not made, or the document fails to progress
>>> to an RFC, the assignment will remain visible in the registry, but
>>> the temporary assignment will be shown to have expired as indicated
>>> by the expiry date. The WG chairs are responsible for informing IANA
>>> that the expired assignments are not required and that the code
>>> points are to be marked "deprecated".
>>>
>>> A deprecated code point is not marked as allocated for use as
>>> described in any document (that is, it is not allocated) and is not
>>> available for allocation in a future document. The WG chairs may
>>> inform IANA that a deprecated code point can be completely
>>> de-allocated (i.e., made available for new allocations) at any time
>>> after it has been deprecated.
>>>
>>>
>>> Regards,
>>> Tianran
>>>
>>>> -----Original Message-----
>>>> From: Kent Watsen [mailto:[e-mail]]
>>>> Sent: Tuesday, August 30, 2016 9:56 PM
>>>> To: Warren Kumari; Eliot Lear
>>>> Cc: Zhoutianran; [e-mail]; [e-mail]
>>>> Subject: Re: [OPSAWG] WG consensus call for the IANA early assignment //RE:
>>>> Adoption poll for draft-lear-ietf-netmod-mud-04
>>>>
>>>>
>>>> I didn’t know that, thanks for the clarification.  I retract my comment.
>>>>
>>>> But I wonder then, if they are temporary and reclaimed, will Elliot’s goal
>>>> be achieved?  - or is it the case that the temporary assignments can become
>>>> permanent through the RFC process? - an optimistic long-term allocation?
>>>>
>>>> Thanks,
>>>> Kent
>>>>
>>>>
>>>> On 8/29/16, 4:39 PM, "Warren Kumari" <[e-mail]> wrote:
>>>>
>>>>     ... and just as a reminder to the WG, early allocations are explicitly
>>>>     temporary, and are marked in the registry as such.
>>>>
>>>>     This isn't burning a critical resource forever - the allocations
>>>>     spaces are not very rare, and they can be reclaimed if needed...
>>>>
>>>>     W
>>>>
>>>>     On Thu, Aug 25, 2016 at 4:49 PM, Eliot Lear <[e-mail]> wrote:
>>>>     > Yes, there is.  And Early assignment is not an unusual request.  See
>>>> RFC
>>>>     > 7120.
>>>>     >
>>>>     >
>>>>     > On 8/25/16 10:01 PM, Kent Watsen wrote:
>>>>     >
>>>>     >
>>>>     >
>>>>     > I don’t know.  It seems that every draft could make similar claims,
>>>> and yet
>>>>     > having IANA make early assignments all the time wouldn’t be good.   I
>>>> don’t
>>>>     > see why this draft should get a pass.   Is there any documentation
>>>> detailing
>>>>     > criteria for early assignments?
>>>>     >
>>>>     >
>>>>     >
>>>>     > Kent
>>>>     >
>>>>     >
>>>>     >
>>>>     > From: Eliot Lear <[e-mail]>
>>>>     > Date: Thursday, August 25, 2016 at 2:36 PM
>>>>     > To: Kent Watsen <[e-mail]>, Zhoutianran
>>>> <[e-mail]>,
>>>>     > Warren Kumari <[e-mail]>
>>>>     > Cc: "[e-mail]" <[e-mail]>, "[e-mail]"
>>>>     > <[e-mail]>
>>>>     > Subject: Re: [OPSAWG] WG consensus call for the IANA early assignment
>>>> //RE:
>>>>     > Adoption poll for draft-lear-ietf-netmod-mud-04
>>>>     >
>>>>     >
>>>>     >
>>>>     > Hi Kent,
>>>>     >
>>>>     > We're doing some open source and would like to make it easier for those
>>>> who
>>>>     > are coding to have to do a little less REcoding.  I doubt very much
>>>> we're
>>>>     > going to see much change in the content or format the URL or the option.
>>>>     > That's what most of the requests are for.  Where I expect we will see
>>>> change
>>>>     > is in the content of the YANG file.  There we have the option to bump
>>>> the
>>>>     > version # in the URL if we think there has been any real uptake of
>>>> earlier
>>>>     > versions.
>>>>     >
>>>>     > Fair enough?
>>>>     >
>>>>     > Eliot
>>>>     >
>>>>     >
>>>>     >
>>>>     > On 8/25/16 7:27 PM, Kent Watsen wrote:
>>>>     >
>>>>     >
>>>>     >
>>>>     > Why is an early assignment being requested?   I think it unusual,
>>>> especially
>>>>     > for a draft that was just adopted, and no justification is given for
>>>> why
>>>>     > it’s needed other than “to assist with interoperable development”...
>>>>     >
>>>>     >
>>>>     >
>>>>     > Kent
>>>>     >
>>>>     >
>>>>     >
>>>>     > From: OPSAWG <[e-mail]> on behalf of Zhoutianran
>>>>     > <[e-mail]>
>>>>     > Date: Tuesday, August 23, 2016 at 5:46 AM
>>>>     > To: Eliot Lear <[e-mail]>, Warren Kumari <[e-mail]>
>>>>     > Cc: "[e-mail]" <[e-mail]>, "[e-mail]"
>>>>     > <[e-mail]>
>>>>     > Subject: [OPSAWG] WG consensus call for the IANA early assignment //RE:
>>>>     > Adoption poll for draft-lear-ietf-netmod-mud-04
>>>>     >
>>>>     >
>>>>     >
>>>>     > Hi All,
>>>>     >
>>>>     >
>>>>     >
>>>>     > Since the authors of the draft-ietf-opsawg-mud-00 asked for the early
>>>>     > assignment for various registries from IANA, I would like to ask the
>>>> WG
>>>>     > consensus.
>>>>     >
>>>>     >
>>>>     >
>>>>     > There will be 1 week since today. You can express your support or
>>>> objection.
>>>>     >
>>>>     >
>>>>     >
>>>>     > If there is no objection, I would like to request from the WG.
>>>>     >
>>>>     >
>>>>     >
>>>>     > The following is a list of IANA considerations copied from the draft.
>>>>     >
>>>>     >
>>>>     >
>>>>     >
>>>>     >
>>>>     > Best,
>>>>     >
>>>>     > Tianran
>>>>     >
>>>>     >
>>>>     >
>>>>     > -------------------------------------
>>>>     >
>>>>     >
>>>>     >
>>>>     > 15.  IANA Considerations
>>>>     >
>>>>     >
>>>>     >
>>>>     > 15.1.  DHCPv4 and DHCPv6 Options
>>>>     >
>>>>     >
>>>>     >
>>>>     >    IANA is requested to allocated the DHCPv4 and v6 options as specified
>>>>     >
>>>>     >    in Section 9.
>>>>     >
>>>>     >
>>>>     >
>>>>     > 15.2.  PKIX Extensions
>>>>     >
>>>>     >
>>>>     >
>>>>     >    The IANA is requested to assign a value for id-pe-mud-uri in the
>>>> "SMI
>>>>     >
>>>>     >    Security for PKIX Certificate Extension" Registry.  Its use is
>>>>     >
>>>>     >    specified in Section 10.
>>>>     >
>>>>     >
>>>>     >
>>>>     > 15.3.  Well Known URI Suffix
>>>>     >
>>>>     >
>>>>     >
>>>>     >    The IANA is requested to register the URL suffix of "mud" as follows:
>>>>     >
>>>>     >
>>>>     >
>>>>     >    o URI Suffix: "mud" o Specification documents: this document o
>>>>     >
>>>>     >    Related information: n/a
>>>>     >
>>>>     >
>>>>     >
>>>>     > 15.4.  MIME Media-type Registration for MUD files
>>>>     >
>>>>     >
>>>>     >
>>>>     >    The following media-type is defined for transfer of MUD file:
>>>>     >
>>>>     >
>>>>     >
>>>>     >    o Type name: application
>>>>     >
>>>>     >    o Subtype name: mud+json
>>>>     >
>>>>     >    o Required parameters: n/a
>>>>     >
>>>>     >    o Optional parameters: n/a
>>>>     >
>>>>     >    o Encoding considerations: 8bit; application/mud+json values
>>>>     >
>>>>     >      are represented as a JSON object; UTF-8 encoding SHOULD be
>>>>     >
>>>>     >      employed.
>>>>     >
>>>>     >    o Security considerations: See {{secon}} of this document.
>>>>     >
>>>>     >    o Interoperability considerations: n/a
>>>>     >
>>>>     >    o Published specification: this document
>>>>     >
>>>>     >    o Applications that use this media type: MUD controllers as
>>>>     >
>>>>     >      specified by this document.
>>>>     >
>>>>     >    o Fragment identifier considerations: n/a
>>>>     >
>>>>     >    o Additional information:
>>>>     >
>>>>     >
>>>>     >
>>>>     >        Magic number(s): n/a
>>>>     >
>>>>     >        File extension(s): n/a
>>>>     >
>>>>     >        Macintosh file type code(s): n/a
>>>>     >
>>>>     >
>>>>     >
>>>>     >    o Person & email address to contact for further information:
>>>>     >
>>>>     >      Eliot Lear <[e-mail]>, Ralph Droms <[e-mail]>
>>>>     >
>>>>     >    o Intended usage: COMMON
>>>>     >
>>>>     >    o Restrictions on usage: none
>>>>     >
>>>>     >
>>>>     >
>>>>     >    o Author: Eliot Lear <[e-mail]>, Ralph Droms
>>>> <[e-mail]>
>>>>     >
>>>>     >    o Change controller: IESG
>>>>     >
>>>>     >    o Provisional registration? (standards tree only): No.
>>>>     >
>>>>     >
>>>>     >
>>>>     >
>>>>     >
>>>>     > 15.5.  LLDP IANA TLV Subtype Registry
>>>>     >
>>>>     >
>>>>     >
>>>>     >    IANA is requested to create a new registry for IANA Link Layer
>>>>     >
>>>>     >    Discovery Protocol (LLDP) TLV subtype values.  The recommended
>>>> policy
>>>>     >
>>>>     >    for this registry is Expert Review.  The maximum number of entries
>>>> in
>>>>     >
>>>>     >    the registry is 256.
>>>>     >
>>>>     >
>>>>     >
>>>>     >    IANA is required to populate the initial registry with the value:
>>>>     >
>>>>     >
>>>>     >
>>>>     >    LLDP subtype value = 1
>>>>     >
>>>>     >
>>>>     >
>>>>     >    Description = the Manufacturer Usage Description (MUD) Uniform
>>>>     >
>>>>     >    Resource Locator (URL)
>>>>     >
>>>>     >
>>>>     >
>>>>     >    Reference = < this document >
>>>>     >
>>>>     >
>>>>     >
>>>>     >
>>>>     >
>>>>     >
>>>>     >
>>>>     > From: Eliot Lear [mailto:[e-mail]]
>>>>     > Sent: Monday, August 22, 2016 7:04 PM
>>>>     > To: Warren Kumari
>>>>     > Cc: Zhoutianran; [e-mail]; [e-mail]
>>>>     > Subject: Re: Adoption poll for draft-lear-ietf-netmod-mud-04
>>>>     >
>>>>     >
>>>>     >
>>>>     > Hi Warren, Tianran, and all,
>>>>     >
>>>>     >
>>>>     >
>>>>     > On 8/17/16 4:17 PM, Warren Kumari wrote:
>>>>     >
>>>>     >
>>>>     >
>>>>     >
>>>>     > Second, and hopefully not that more of a controversy, I would like
>>>> to
>>>>     > request early IANA assignments to assist with interoperable
>>>>     > development.  These would be listed in the IANA considerations section
>>>>     > of the current draft.  If we need a WG draft to make this happen, that's
>>>>     > fine with me, but we should do a quick rev after the assignments.
>>>>     >
>>>>     >
>>>>     >
>>>>     > I believe that this *can* be accomplished without it being a WG doc,
>>>> but it
>>>>     > is better / cleaner / easier if we make it a WG doc and then ask for
>>>> early
>>>>     > assistant. We are fine with lots of revisions / it being submitted
>>>> and then
>>>>     > quickly revised.
>>>>     >
>>>>     >
>>>>     > Just following up on this point: we'd like to request early assignment
>>>> from
>>>>     > IANA for the various registries.  Does that go through the chairs or
>>>> the
>>>>     > authors at this point?
>>>>     >
>>>>     > Thanks,
>>>>     >
>>>>     > Eliot
>>>>     >
>>>>     >
>>>>     >
>>>>     >
>>>>
>>>>
>>>>
>>>>     --
>>>>     I don't think the execution is relevant when it was obviously a bad
>>>>     idea in the first place.
>>>>     This is like putting rabid weasels in your pants, and later expressing
>>>>     regret at having chosen those particular rabid weasels and that pair
>>>>     of pants.
>>>>        ---maf
>>>>
>>>
>>
>>
>>
>> --
>> I don't think the execution is relevant when it was obviously a bad
>> idea in the first place.
>> This is like putting rabid weasels in your pants, and later expressing
>> regret at having chosen those particular rabid weasels and that pair
>> of pants.
>>    ---maf
> 
> 
>