Re: [Idr] Thoughts on https://www.ietf.org/id/draft-hares-idr-bgp-registries-01.txt

[Robert Raszuk <[e-mail]>]

Sue,

Automated checks on drafts means "*no self documented allocation*".

Folks who are implementing things even will continue to do "s*elf
undocumented allocations" *or are going to be permitted to get next code
point and proceed with implementation without any politics and reviews.

John said that your draft targets only standard action and IETF standards
track final allocations where document goes via WG last call.

But in my opinion the genesis of squatting is not at that point in time
scale. It happens much earlier where an idea in the draft if facing early
implementation. Jeff suggested to send such draft to IANA for early
allocation individually but it will be seen in bad light.

So with all of the above we still have no way to get codepoints for early
implementations without being stuck with reviews. And implementations are
not even used to jusitfy acceptance to become a WG document in IDR ....

Cheers,
r.





On Thu, Mar 23, 2017 at 1:46 PM, Susan Hares <[e-mail]> wrote:

> Eric:
>
>
>
> Thank you for your return comments with helpful suggestions:
>
>
>
> 1)      IETF consensus trumps  DE opinion -   If you are suggesting that
> the WG chair(s) that sponsored a draft should not be the Designated
> Expert.  Good idea.
>
> 2)      Adequate review –  If you wish it to be a single working group
> assigning BGP code points, the WG chair/document shepherd method works.  By
> this comment, we would need to select one WG to approve standardization of
> BGP code points.  My proposal at IETF 97 was that IDR was such a WG since
> BGP base specifications (e.g., RFC4271) were started there.  My alternate
> proposal of shared responsibility among the BGP-focused chairs is the
> bgp-registries.
>
> 3)      On reviewing Shepherd’s work – sounds like you would be a useful
> reviewer for documents.  Please volunteer.
>
> 4)      On code point squatting, operators had real problems with the
> current situation.   Job said “automatic checks on drafts”,  Sue said “IETF
> Standard + DE of BGP chairs where IETF Consensus wins” – Got any alternate
> solutions.  Got any alternate suggestions?
>
>
>
> Sue Hares
>
>
>
> *From:* Eric C Rosen [mailto:[e-mail]]
> *Sent:* Thursday, March 23, 2017 1:29 PM
> *To:* John G. Scudder
> *Cc:* Susan Hares; Adrian Farrel; [e-mail]
> *Subject:* Re: [Idr] Thoughts on https://www.ietf.org/id/draft-
> hares-idr-bgp-registries-01.txt
>
>
>
> On 3/22/2017 2:36 PM, John G. Scudder wrote:
>
> I think Adrian nailed it when he suggested:
>
>
>
> b. Recognition that IETF consensus trumps DE opinion. Hopefully this will never
>
> arise, but it is clear (or should be) that for a Standards Action registry, if
>
> there is IETF consensus for an assignment, then the DEs can warn and advise, but
>
> the will of the IETF takes precedence.
>
>
> According to the proposal under consideration, the DEs are the same people
> who judge whether there is IETF consensus.  The conflict of interest is
> evident.
>
>
> the reason is to try to ensure sufficient review happens before it's too late.
>
>
> I'm not opposed to additional review, but that has nothing to do with the
> codepoint allocation process.  Presumably it is already the job of the WG
> chairs and/or document shepherds to obtain an adequate level of review.
>
>
> the concept of a WG having "standing to request changes" is inoperative
>
>
> I'm looking forward to the day when you can't get a codepoint in any
> registry without the approval of the security and the operations ADs ;-)
>
>
> In parallel, Job Snijders made a useful suggestion that idnits maybe should be on the lookout for code point squatting.
>
>
> That's an interesting suggestion, but has to be used carefully.  If
> someone is squatting on a codepoint, they should be encouraged to tell the
> rest of us that they are doing so.  Encouraging them to keep it a secret
> (to avoid being tagged by idnits) would be a strange way to encourage
> interoperability.
>
> I also think that document shepherds should be on the lookout for cases
> where drafts specify codepoints or flags for new stuff without requesting
> the necessary registries to be set up.
>
>
> This leads me to wonder if we aren't going at this wrong -- if instead of using the hammer of registry policy to ensure the right WGs have been notified, we should try the screwdriver of automated tooling. The idea is registries would still be marked up with parties interested in monitoring them, but there would be no formal changes to the requirements for allocation from the registries. Those monitoring the registries (e.g., the list of people in Sue's draft) would get notifications when an allocation was proposed -- as early as possible, but no later than when the draft was sent for IETF last call. The onus would fall on them to chime in (again, as early as possible) and the regular consensus process would take its course.
>
>
> This proposal makes sense.  It encourages more review without giving
> dictatorial powers to a committee of WG chairs.
>
>
> your morbid fears of red tape
>
>
> I've seen many cases where IETF politicians wield red tape as a weapon;
> some do so quite expertly.  Ultimately all type fields will be two-octets
> long with FCFS registration; that's the ultimate solution to this
> particular red tape problem.
>
> _______________________________________________
> Idr mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/idr
>
>