Re: [MMUSIC] Alexey Melnikov's Discuss on draft-ietf-mmusic-ice-sip-sdp-38: (with DISCUSS)

"Alexey Melnikov" <aamelnikov@fastmail.fm> Wed, 14 August 2019 17:32 UTC

Return-Path: <aamelnikov@fastmail.fm>
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 48746120C6F; Wed, 14 Aug 2019 10:32:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.689
X-Spam-Level:
X-Spam-Status: No, score=-1.689 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_FILL_THIS_FORM_SHORT=0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmail.fm header.b=oo+i/M1E; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=sj1djjcC
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0yXUaC1cJc1O; Wed, 14 Aug 2019 10:32:05 -0700 (PDT)
Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1AC29120C6C; Wed, 14 Aug 2019 10:32:05 -0700 (PDT)
Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id 48DB6213BD; Wed, 14 Aug 2019 13:32:04 -0400 (EDT)
Received: from imap1 ([10.202.2.51]) by compute7.internal (MEProxy); Wed, 14 Aug 2019 13:32:04 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastmail.fm; h= mime-version:message-id:in-reply-to:references:date:from:to:cc :subject:content-type; s=fm3; bh=ijogkFu1beVmF6dB0nYnYIsypsgIt80 1IbIO1em0z/0=; b=oo+i/M1EAlWXBYtxkmhYxK3fxetCwrRK4YPssnkk3ICkzzP +HjUt63GcqAB6HDZlZpqYPZSRAA+xaIfBzHfQ9YywfEW+y550kEuN+lGJWkgJ+Ti v4qCvmHAJ/QPGZ/sarTKLIXaw35JFkEDySfYtLiCvKfW/r+aeRvhA098fSpb7XdU Wdf67q2Wa57hiSZBdTiSRE42W8PC60SKEew35iSqHyZ1o4NZ8DiAIONYRhfWXmAw jtWFT2DiIJpxoXYdw+TCrUVWH+9bqIXPTXP98qt26R0l3x+YwpUDLiK3yDsOZsNI PGRNPQp6v1pYPtpAPgaSZ34L8Tfs/X8OMlTG15w==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=ijogkF u1beVmF6dB0nYnYIsypsgIt801IbIO1em0z/0=; b=sj1djjcChoNohbvxCB01wA 3YU6DiWalSbjxJdr3RLyIlTaXG3W9s+T+8rfRr/CimGbo0WQBE7Pztd2m+Be0smq iD7cdeCpDP5JFXlcReOD8YxeS/rsnM4Ec5Z0n9Ivt5BCYnNYdcx0gkC/t05S3l79 /FCVf6pMm4ICxA1AWXDUUcU0OCz28b87nQE56RwliD5ZkUvq9HZGIPsuAZSCdpu6 +68h/Spck97n0S2QqZat6lFMahz1fZVL7dac9iqTjYQ6ZtQo90HrjjhArNQGLjQ1 RyHD5Bpz3+rENx083t5eI8o9qgatk0lqEtTq83/710KxBGEV706C5wISvkI1tMPw ==
X-ME-Sender: <xms:k0VUXfyLkUf9dSBidz6EBZgQk9i7ChujCs8YaSve4ZFr78tdx9C6_w>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduvddruddvledgheduucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepofgfggfkjghffffhvffutgesthdtredtreerjeenucfhrhhomhepfdetlhgv gigvhicuofgvlhhnihhkohhvfdcuoegrrghmvghlnhhikhhovhesfhgrshhtmhgrihhlrd hfmheqnecurfgrrhgrmhepmhgrihhlfhhrohhmpegrrghmvghlnhhikhhovhesfhgrshht mhgrihhlrdhfmhenucevlhhushhtvghrufhiiigvpedt
X-ME-Proxy: <xmx:k0VUXQEQx0_78I8PnZV3QPw0H85QZSESxgbsENDdwQkAA2x7rADUEg> <xmx:k0VUXapn4Azp09gqajPL1EZxt5FMsf7wQPx9BpGtHLIphq-8i9erZA> <xmx:k0VUXezjlbCeUsOvvFgx2LOEYU82qt9_8tS2vicfeHqC73R1uVIB_A> <xmx:lEVUXXyvrVrTAP3s3lanx83Wt22uqP5oxgwmD2CtN7cB3LGdVTuxkg>
Received: by mailuser.nyi.internal (Postfix, from userid 501) id A9B64C200A5; Wed, 14 Aug 2019 13:32:03 -0400 (EDT)
X-Mailer: MessagingEngine.com Webmail Interface
User-Agent: Cyrus-JMAP/3.1.6-869-g2d94aad-fmstable-20190814v1
Mime-Version: 1.0
Message-Id: <c599715d-c0c4-4cc6-bbc2-38c72aef928f@www.fastmail.com>
In-Reply-To: <BDB5931C-7518-45A6-895F-D9BF62A289BF@ericsson.com>
References: <156536166262.15946.384757988181068904.idtracker@ietfa.amsl.com> <HE1PR07MB31616472644ED221A1965B8F93D60@HE1PR07MB3161.eurprd07.prod.outlook.com> <7F70A131-8BE5-425A-B6C7-6BD503D195E2@ericsson.com> <a1c85143-2e4b-4f4e-8ac4-1a0f396634aa@www.fastmail.com> <BDB5931C-7518-45A6-895F-D9BF62A289BF@ericsson.com>
Date: Wed, 14 Aug 2019 18:31:06 +0100
From: Alexey Melnikov <aamelnikov@fastmail.fm>
To: Christer Holmberg <christer.holmberg@ericsson.com>, The IESG <iesg@ietf.org>
Cc: "draft-ietf-mmusic-ice-sip-sdp@ietf.org" <draft-ietf-mmusic-ice-sip-sdp@ietf.org>, "mmusic-chairs@ietf.org" <mmusic-chairs@ietf.org>, Flemming Andreasen <fandreas@cisco.com>, "mmusic@ietf.org" <mmusic@ietf.org>
Content-Type: text/plain
Archived-At: <https://mailarchive.ietf.org/arch/msg/mmusic/WSfsu5gB_uNbqrI9u2OY3ihi2l0>
Subject: Re: [MMUSIC] Alexey Melnikov's Discuss on draft-ietf-mmusic-ice-sip-sdp-38: (with DISCUSS)
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <mmusic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mmusic>, <mailto:mmusic-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/mmusic/>
List-Post: <mailto:mmusic@ietf.org>
List-Help: <mailto:mmusic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mmusic>, <mailto:mmusic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 14 Aug 2019 17:32:07 -0000

On Mon, Aug 12, 2019, at 2:45 PM, Christer Holmberg wrote:
> Hi,
> 
>     2) In 10.2:
>     
>     >>>> You removed the following text:
>     >>>>
>     >>>>   o  Name, Email, and Address of a contact person for the 
>     >>>> registration
>     >>>>
>     >>>>   o  Organization or individuals having the change control
>     >>>>
>     >>>> I think removing (postal) Address is a good thing. However the 
>     >>>> rest of this is still needed, as IANA uses 
>     >>>> this information to decide whether a person/organization is 
>     >>>> allowed to update an existing registry entry. 
>     >>>> may be closed down. The authors of the RFC may have moved on. 
> etc
>     >>>>
>     >>>> So please consider adding it back or explain why this 
>     >>>> information is not needed for a registry where external 
>     >>>> organizations can add value (without publishing an RFC).
>     >>>
>     >>> The text already says that "Specification Required" applies to 
> new entries.
>     >>>
>     >>> I am not aware of another registry where we would define 
> entry-specific rules. 
>     >>     
>     >> Let me know if you still have issues with this. Maybe I 
>     >> misunderstood your issue :)
>     >
>     > Yes, I still have an issue with this change. The document is now 
> lacking information needed for IANA to complete registrations.
>     >
>     > When I originally asked about need for "Address", all I wanted 
> was removal of "Address", not removal of the 2 sentences around it.
> 
>     Yes.
> 
>     But, my comment regarding "Organization or individuals" was that I 
> am not aware of any IANA registry where we indicate who
>     is allowed to update an entry. Why do you think IANA needs that 
> information?

This is less of an issue for "Specification Required", but it is certainly an issue for "Expert Review" registries.

Consider the following scenario (it has happened several times in the past as far as I know):

At some point an item X is registered by userN@organizationY.com.  10 years later the person is no longer working for Organization Y. The person contacts IANA and attempt to change the registration from a new email address userN@gmail.com. If the registry doesn't say whether this was a personal registration (and thus the request should be approved, assuming IANA can prove that this is the same person) or for a company (in which case the change request should be denied and the contact email should be updated to another person representing Organization Y), then making changes/updates becomes difficult.

There were similar problems recently when a specification was originally developed by an organization and later on was taken as a work item in an SDO.

Anyway, if you want to make updates to registration easier, Contant and Change Controller should be included in an IANA registration template.

Best Regards,
Alexey