>> s10.3: The registration procedure seems overly complex. If, as stated, an
>> RFC is required in all cases, then the standard (RFC 7035) IETF Review
>> registration policy would seem to fill the bill and there is no need for a
>> designated expert. Alternatively, Specification Required (with a designated
>> expert as is standard for this case) could be used if other types of
>> specification could be countenanced. I suspect the requirement for a
>> standards track RFC as a way of modifying an existing value is going to come
>> back to bite us if the original specification was not standards track. I am
>> not sure this attempt to provide a higher hurdle for modifications is the
>> best way to go about this - In general, IETF Review would, I think, give
>> enough pushback against inappropriate updates without requiring standards
>> track in all cases. Overall, I recommend that the authors consult your AD
>> and IANA to determine how best to structure the registration procedure.
>
> [PH] The current document is probably following older IANA practices which I
> understand have recently been updated. Leif Johansson has suggested we can
> simplify by updating the document to reflect the new recommendations. I’ll
> let Leif comment more on this issue.
So I think we could/should probably simplify the IANA considerations
section so as not to define new IANA processes.
I believe SCIM should probably be able to rely on processes defined
in RFC 5226 (and we should have caught this ourselves). My gut feeling
is that relying on Designated Expert Review except for the ietf URN
namespace which requires IETF standards track document.
Cheers Leif
_______________________________________________
Gen-art mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/gen-art
