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

[Warren Kumari <[e-mail]>]

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



-- 
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