Re: [tsvwg] CALL to revoke last call: Re: Request for working group feedback on draft-kuehlewind-system-ports (6th March, 2020)

Mirja Kuehlewind <mirja.kuehlewind@ericsson.com> Tue, 18 February 2020 17:21 UTC

Return-Path: <mirja.kuehlewind@ericsson.com>
X-Original-To: tsvwg@ietfa.amsl.com
Delivered-To: tsvwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A113120077 for <tsvwg@ietfa.amsl.com>; Tue, 18 Feb 2020 09:21:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Level:
X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com
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 JeixW0vnn9i1 for <tsvwg@ietfa.amsl.com>; Tue, 18 Feb 2020 09:21:14 -0800 (PST)
Received: from EUR05-AM6-obe.outbound.protection.outlook.com (mail-am6eur05on2071.outbound.protection.outlook.com [40.107.22.71]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 36BF8120018 for <tsvwg@ietf.org>; Tue, 18 Feb 2020 09:21:14 -0800 (PST)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=TIRax2PnafXW8R6jBqriYehpV98D2dohjBrR2/L4WUCkEvpWphNdxpoNIAU9q509u1xuE937tkf7CTjSh+hn6EY6NL0fuzAlS4UDmNYM2AzMDptd2rqpTD060NQMsIBMpzqPFSjyLXO10NkUOv7cuKF9x2nP/JM37ffHQWrxrrKRYKtOlL92ufXtXNf2/UHrLs05BWYiKfd9KtEA894gYl4/0ua8nlwS9JpYQ2nAWG/22+qqfOLJLKpzZYU+RvN9O1PGbdEwRE12AwcLuMW5egp51CqkUuMOLtMliPwh4NwhvAQH9/+ryFpz6pnNtjhDqK/akEGIHnAh9Id0aHLMRQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=JWM6hWpuf+Izy1NLYJbH93DRt3gdUXIfk/wkSUSlPXk=; b=fRhFBYgCqIUpyke8yheq5W4ykMfqxBqsGvuojqYA+pXHqqCyhzkH9SfxTjfy/69xTbaPSsXBdstA6lnF+e8Ik3YtiDIPpGLLDf4xzxMg1tucnYmHfrVi0pxf+2CPrxI0IlVLnFvrr0iq08I9jXoJFKY9/4flgLSGZwd2j9IIzCkGD5ORkSKceUm4+PGbirNqnuN12V10i5T0aKUZiA5zpxGDW0fZFHEqBk1jRKCc/g+qAmvgDIcYM03RT/l+VpySQVNDWJX/XB8gpd9FZtMtnprkol/KZz9/krqTkMW6IHrLvZAQ7+U4VUcJdjO9+4B1pmjx6kxADQykPZ3CHtJqqQ==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=JWM6hWpuf+Izy1NLYJbH93DRt3gdUXIfk/wkSUSlPXk=; b=SD2r1Osm8JL+817g7tCB3aoG3hw8FYt5rbE+csRKd5JzDKp4TwHqlutytLgR+zgHg9CC32adMvky2chlqvTLT5dcThTUH9C9exC+tkgeYo7dPnAS2KbHDOCCry3BBVdBfRqyww8wuD4Fp+XkCfXJv4e/EBOjiu/Nba3064pM7Y0=
Received: from AM0PR07MB4691.eurprd07.prod.outlook.com (52.135.149.158) by AM0PR07MB4948.eurprd07.prod.outlook.com (20.178.17.33) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2750.6; Tue, 18 Feb 2020 17:21:11 +0000
Received: from AM0PR07MB4691.eurprd07.prod.outlook.com ([fe80::4879:46ae:16e:f5b7]) by AM0PR07MB4691.eurprd07.prod.outlook.com ([fe80::4879:46ae:16e:f5b7%7]) with mapi id 15.20.2750.016; Tue, 18 Feb 2020 17:21:11 +0000
From: Mirja Kuehlewind <mirja.kuehlewind@ericsson.com>
To: Joseph Touch <touch@strayalpha.com>
CC: Gorry Fairhurst <gorry@erg.abdn.ac.uk>, "tsvwg@ietf.org" <tsvwg@ietf.org>
Thread-Topic: [tsvwg] CALL to revoke last call: Re: Request for working group feedback on draft-kuehlewind-system-ports (6th March, 2020)
Thread-Index: AQHV5eb6j3blqa34n0qspL8HjaR+vKgg0uGAgABLgYCAACY0gA==
Date: Tue, 18 Feb 2020 17:21:11 +0000
Message-ID: <7249DFBC-3F87-43A1-9133-68386E91804F@ericsson.com>
References: <3cdde689-7031-a1de-1d4e-16a86e40f35c@erg.abdn.ac.uk> <c432c59b-0df6-9ad1-177f-8de8e1d07119@strayalpha.com> <7669EBE5-E023-4129-ABE0-56D68085159E@ericsson.com> <AF65A1AC-02D8-48A7-A1A7-63586E7E50C3@strayalpha.com>
In-Reply-To: <AF65A1AC-02D8-48A7-A1A7-63586E7E50C3@strayalpha.com>
Accept-Language: en-US
Content-Language: en-GB
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=mirja.kuehlewind@ericsson.com;
x-originating-ip: [129.192.10.3]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 357991da-5bad-4735-3d44-08d7b496f34f
x-ms-traffictypediagnostic: AM0PR07MB4948:
x-microsoft-antispam-prvs: <AM0PR07MB494826EC99C6F81303A3DAE7F4110@AM0PR07MB4948.eurprd07.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:6108;
x-forefront-prvs: 031763BCAF
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(39860400002)(366004)(376002)(136003)(396003)(346002)(199004)(189003)(66946007)(5660300002)(76116006)(186003)(66476007)(8936002)(66446008)(2616005)(316002)(64756008)(54906003)(30864003)(33656002)(66574012)(66556008)(4326008)(26005)(8676002)(6512007)(81156014)(81166006)(2906002)(6486002)(6506007)(53546011)(44832011)(478600001)(6916009)(36756003)(86362001)(71200400001); DIR:OUT; SFP:1101; SCL:1; SRVR:AM0PR07MB4948; H:AM0PR07MB4691.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1;
received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: vqIvShk6tgDSuaxtSn/46D+tTctXceIyjYfdM2viEU1lM3G6p3s4AP/+rh5LUTpZ1va+TaIELdb9ivH/DJ3wRbOsmzJIG3byrRyYX1M1szOPZHnzXzOZNNnsIg1Zar2saCmjy4mFgkCeyx7bFezY2aQlxzlfOKQOXnwPxyZzCwAK1ZsCktBqI2u+mv4dnOqtjZFE5UqJfa48PPsZyOkQng9PD4QcBrELdIbPkPC9fEFtF+ft33BH+krb1urKpVi968YWZwYOtNwyWRL4qJgJyw1udjWUWdurFTZ5qPt43qm5nho5FNt+SofSK7NifkP3ep5h2Hx7mzw3r2Ojp+PpIPrmJn+sBBOfI1mJMW8daMQVKPFM3bPKiLMyMvLzK5BQJ8DTYbK8y/x8LmuRJBOj37OSk5byLWvQ8+wt1OZoCkyzj7yn4zb7KGQeovWH1fdq
x-ms-exchange-antispam-messagedata: MG/Ib+ZiQwagSqmfO5uG2OFLbGvjgZgIe1uARZ7MuskjKJ/uz4OZJpuPW7ZMYbCnfiLYVtSkSOTIkKNOAld4c4oFyVcfzempdKfKii4UIWBZpdhJzP/T2oKQPGGFaZv2LRWuJ9zFkiAPHRlbsLMmuw==
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="utf-8"
Content-ID: <ADD2437D3255614982F380BF28BE2C6B@eurprd07.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: ericsson.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 357991da-5bad-4735-3d44-08d7b496f34f
X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Feb 2020 17:21:11.5585 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: l92FkTva/L14WV3cM1DGbSQHjgwRRCuxUjeg7JXuL7zXdNX5xXBRI2dylEe/H0j8h88nvJF+q1UMEol1HyKZFPrb3jwTWImb3nP2SNkGuTw=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR07MB4948
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/rmFNjtErIMErw7cQtK5wGsZXRdE>
Subject: Re: [tsvwg] CALL to revoke last call: Re: Request for working group feedback on draft-kuehlewind-system-ports (6th March, 2020)
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Transport Area Working Group <tsvwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tsvwg/>
List-Post: <mailto:tsvwg@ietf.org>
List-Help: <mailto:tsvwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 18 Feb 2020 17:21:19 -0000

Hi Joe,

please see inline (prefixed with [MK2] this time).

On 18.02.20, 17:04, "Joseph Touch" <touch@strayalpha.com> wrote:

    First, I still contend that you, as *transport AD* **AND** who injected herself inside the ports review process (unprecedented for a transport AD, FWIW) should know better, ESPECIALLY given the feedback that was provided *two months ago*.
    
    That said...
    
    > On Feb 18, 2020, at 2:34 AM, Mirja Kuehlewind <mirja.kuehlewind=40ericsson.com@dmarc.ietf.org> wrote:
    > 
    > Hi Joe, hi all,
    > 
    > (sorry for sending an empty mail just a few moments ago).
    > 
    > Please see inline (prefixed with [MK]).
    > 
    > On 18.02.20, 00:07, "tsvwg on behalf of Joe Touch" <tsvwg-bounces@ietf.org on behalf of touch@strayalpha.com> wrote:
    > 
    > ...
    > 
    >    3) this doc falls clearly within the purview of TSVWG, as it *should* be 
    >    handled similar to RFCs 6335 and 7605; it should have been submitted for 
    >    WG consideration FIRST - before being posted even for LC.
    > 
    > [MK] I wasn't ware how RFC6335 was handled.
    
    As transport AD *and* deeply following the ports review process, that should have been much more obvious to *YOU*, of all people.

[MK2] This was done before my time as AD. Further I'm neither following deeply the ports review process, nor do I see how following it deeply would have helped me to know anything about the past process that was applied to RFC6335. 
    
    > However, Gorry as tsvwg chair pointed out that it would be good to also forward this last call to tsvwg and that's what we did. Please note that this is a much smaller document that RFC6335 and it does not specify any change to the procedures in RFC6335 (but only working within the defined procedures), as Brian also indicated in his reply.
    
    Please review his reply. It short-circuits the process in 6335 and attempt to claim that the IESG alone makes the final decision. Given the IESG would be filing the request, the appeals process clearly should be handled by the IAB, per Sec 7 of RFC 5226 (again, why an AD who the Nomcom deemed qualified also for the IAB doesn’t know this is disconcerting). And - to be VERY clear - YOU should recuse yourself of involvement in that process whenever it happens, as it relates to this doc.

[MK2] This is not what the draft say at all. It says that IANA should contact the current assignee in order to request a change in change control. If the assignee is not reachable or the assignee is not agreeing to this request, IANA will inform the IESG for further processing (in order to take any addition burden from IANA). That's all what the document intends to do.

[MK2] The document does not specify any action (or new procedures or anything) that the IESG will do after this step. We discussed this in the IESG and left this open as it was hard to estimate what would happen. In the unlikely case that all reply and agree, we as the IESG simply do not need to anything at all (so why specifying it now?). One thing we agreed to do is for those cases where people are not reachable, we will try to find a new contact address (which is described in the draft). In some cases people are still know in the community and only the information in the registry is outdated; in other cases there are at least still people in the community that might have a new contact address. We didn't wanted to put the burden on IANA to do any such deep research that why the draft just says, that IANA should report to the IESG.

[MK2] Then if the IESG is sure that a contact is not reachable anymore, we might decide to instruct IANA to update the contact information accordingly within the procedures defined in RFC6335 and eventually de-assign and re-assign the port based on IESG Approval if considered appropriate.

[MK2] Other cases we discussed in less details, in the hope that there will only be a small number of cases that we can then discuss and handle on a case by case basis. The outcome of this might well be to not do/change anything for that port entry.
    
    >    The fact that this doc is being rushed through as an individual 
    >    submission by the transport AD as sponsored by another AD of the IESG is 
    >    highly suspicious and IMO inappropriate.
    > 
    > [MK] This is also the usual process for process related documents that come out of an issue detected by the IESG. The most recent one that comes to mind is rfc8174. -00 was published in Aug 2016, then one update in Feb 17 just before IETF last call.
    
    That’s not how RFC 6335, despite being led by members of the IESG at the time as well.

[MK2] I don't know what you mean here.
    
    > ...
    >    To repeat: the authors need to DO THEIR HOMEWORK as follows:
    > 
    >    - correct the errors
    > 
    >         - RFC 6335 defines reassignment and the appeals process, in 
    >    contrast to the claims of this doc, including when a party is no longer 
    >    reachable (the IESG or IAB appeal would decide how to proceed)
    > 
    >         - RFC 6335 also explains the process for deassignment, which is 
    >    much more involved than described here
    > 
    >         - if this doc is intended to update RFC 6335, it should say so AND 
    >    BE A TSVWG adopted item, not merely an individual submission
    > 
    > [MK] This document does not update RFC6335 as it does not change any process of RFC6335.
    
    Yes, it does:
    
    In Sec 1 it *incorrectly* claims that nothing can be done if the original assignee can’t be contacted. In specifying a procedure for that case, it de-facto updates RFC 6335 at least for the one-pass scrub of the system ports suggested by your doc.

[MK2] So what the appropriate process regarding RFC6335 to de-assign and re-assign a port when the original assignee is not reachable anymore in your view? My assumption was that both can be done based on IESG Approval and I thought this is  covered by RFC6335. If you have a different view, please point me at the relevant text in RFC6335. I think this is important to get right and understood by the IESG also for future cases not matter what. And if we have different views, we need to clarify that.
    
    In Sec 2, it *incorrectly* claims that the IESG would be requested to make a decision about its own requests (“if these actions…”) and fails to mention any oversight by the IAB. Per RFC 6335 and 5226, the appeal should fall to the IAB because the IESG is the requester of the action. The IESG should not rule on its own request (that is a conflict of interest).

[MK2] As I told you already, of course the appeal process applies here as it does for any action performed by the IESG or any other action performed in the IETF by any entity. I don't see why you think it would not apply here and effectively I don't it's even possible to not have it applied. I don't think there is any value in mentioning explicitly though, but I can copy the respective text from RFC6335 into this document as well to rule out any doubt if you think this is needed.

[MK2] However looking at this specific sentence again, I understand now maybe your concern a bit better. The sentence is:

"If these actions do not show success within 4 weeks, the IESG is
   requested to make a decision about the re-assignment of the port in
   question."

[MK2] The intention of this sentence was to say that after 4 weeks with no reply, this is not IANA business anymore and they don't have to worry about it. However, it was not intended to say that the IESG will automatically re-assign these port. The assumption is that the IESG can de-assignment and assign based on IESG Approval if appropriate. Again, if we have different views on the process here, we need to clarify this. However, maybe we also just need to clarify the wording here...?

    In the following paragraph, it attempts to subvert the appeals in RFC 5226 that are cited in 6335 for changes, claims that if there is a disagreement the IESG is empowered to make a decision - which is at least implied as final. Again, this is not what RFC 6335 specifies - 6335 allows appeal to the IAB.

[MK2] Again the intention is not to subvert the appeal process as I don't think this is even possible. However, same point as above. Let clarify what the process is/should be and state this appropriately in the document!
    
    > It operates within the process as defined by RFC6335. The IESG discussed that it would be good to do this mass clean-up step instead of keep handling it on a case-by-case basis. The decision to write and publish this in an RFC has been taken in order to make this as much as possible transparent to the community and get broader input - which is what we are doing right now in last call.
    
    Again, you keep saying “instead of keep handling it on a case-by-case basis”, but haven’t provided any evidence that this has become an onus to the IESG.
    
    >    - show an empirical need for dealing with standards-track ports in bulk 
    >    rather than on a per-issue basis
    > 
    > [MK] This is also about doing some clean up activity, especially for protocols that are specified in an RFC by now but ports are still assigned to individuals.
    
    As I mentioned off-list (and you keep ignoring), then this doc should focus on the transfer of standards-track assignments, not system ports.

[MK2] I thought I replied to all you mails. I noted this point. However, I believe if we do any action here, we should also go for a clean-up in order to detect outdated contact information and potentially not-used ports, as I already said several times. I'm happy to get more input from others on this point! 
    
    > Of course being in this situation doesn't break the Internet giving it's working right now but it can easily cause problems (and potential delays) in future. 
    
    There are NO urgent problems of this nature. The port assignments are permanent; any claim to urgency is ridiculous and again *unsubstantiated* by this doc.

[MK2] Not it's not urgent at all. This draft is around for 2.5 years already but I think we should do it at some point.
    
    > [MK] All in all a lot of information in that registry is just outdated which does make the registry less valuable. So why not give it a try to clean that up (now)!?
    
    As I have noted, no reason - except to note that WHY RIGHT NOW is also *no reason*. 
    
    >         - especially given at least some of the issues in this doc, such as 
    >    "orphaned" ports (whose contact is no longer reachable), represent an 
    >    ongoing problem that cannot be corrected  by a single pass
    > 
    > [MK] At least for system ports we should not really have that problem for new assignments as they just usually be assigned to the IETF. This also why this document focus on system ports.
    
    That is *again* incorrect; RFC 6335 allows system port assignment by both IETF review and IESG approval, per RFC 5226.
    
    IESG approval is just that.
    
    However, only ports assigned through the IETF doc stream are required to have the IESG as assignee, per RFC 6335 Sec 8.1.1. That stream is defined in RFC 4884 Sec 5.2.2 as IETF WG doc or AD sponsored.
    
    That leaves IESG approved docs, which include IRTF docs and independent stream submissions, as well as (frankly) IAB submissions.
    
    Again, it’s useful to note that the port assignment process in 6335 DOES NOT REQUIRE an RFC at all. Other options include experimental RFCs, informational RFCs, or even an ID that never progresses to RFC.

[MK2] I didn't say that an RFC is require, I was just saying that my expectation is that most new assignmenst in the system range will have the IEFT as assignee and contact (and that is something independent of the assignment procedure).
    
    Again - and again - it is disconcerting that I need to point this out to someone who is charged with overseeing the ports assignment process itself.
    
    >   - provide a COMPLETE list of the impacted standards-track ports not 
    >    already assigned to the IESG, *including* those in the user ports space 
    >    (not merely system, which RFC 7605 already suggests not treating as 
    >    privileged anyway)
    > 
    > [MK] You can look that up on the IANA page. I don't think it's necessary to put this in the draft.
    
    How can I look that up? Where is that list?
    
    You yourself admit the ports database has outdated information - that includes the fact that many ports do not indicate the RFC that triggered three assignment. 

[MK2] Yes, this is also something this draft addresses.
    
    >    - NOT attempt to "reclaim unused" system ports, for several reasons:
    > 
    >         a) see the hazards of deassignment per RFC 6335
    > 
    > [MK] We don't deassignments. We only change the change control, so we can more easily assign them correctly in future if needed, like done for QUIC on UPD/443.\
    
    So again you can give exactly ONE example of the urgent need to relieve the IESG of the burden of doing this case-by-case.
    
    IMO you have failed to make the case of urgent need.

[MK2] Because I never said it is urgent at all. But we should do it sometime, so this sometime can just be now.
    
    >         b) see the recommendation to not treat system ports as privileged 
    >    and thus there would be no utility in focusing on reclaiming entries 
    >    from that range
    > 
    > [MK] However, assignment rules are (still) different for this range.
    
    Yes, but not the way you claim above.
    
    But again, if the issue is IESG burden of managing standards whose ports are not IESG assigned, then FOCUS ON THAT.
    
    >    - limit the scope of this doc to those such ports, rather than implying 
    >    the IESG will be "reclaiming" the entire system ports space (including 
    >    rewriting the title and abstract)
    > 
    > [MK] What do you mean by "such ports”?
    
    Ports assigned to standards-track RFCs.
    
    >    - NOT attempt to subvert the appeals process for port reassignment as 
    >    per RFC6335
    > 
    > [MK] We don’t.
    
    You do, as described in detail above.
    
    >    - NOT attempt to subvert the WG process by submitting this as "individual"
    > 
    > [MK] That was not indented but this is a process document, so it was not seen as in scope for any group.
    
    Given your INDIVIDUAL injection into the ports review process - adding yourself to the port review email list (again, unprecedented for AD oversight of the ports review process) - it remains highly disconcerting to see this explanation.

[MK2] I think this is a completely independent topic. I don't oversee any of the details of the review process but it the AD's responsibility to maintain the expert group. As you know yourself I didn't interfere the review process in anyway, however, I think the list has proven to be useful to more quickly address any AD question when they come up. I notice that you still have a different view here but also other experts I've asked about this provided very positive feedback about the fact that we have this list and the way we use this communication channel. Again, I don't think it is a topic that should be discussed on this list. Just wanted to clarify what's going on for others as you keep bring this up.
    
    And in case there was any doubt, what exactly is RFC 6335 if not a process doc?

[MK2] I didn't say this at all. I just said that the process this document described based on previous IESG discussion was not seen as in scope for any working group. I agree that the tsvwg list is a good list to request feedback (which we did) given the right experts are subscribed to this list, however maintenance of the port registry is not explicitly in scope of the tsvwg charter. I wasn't aware that RFC6335 was a working group document, and as such you are right that we could have done the same for this document maybe. However, again, this is a much smaller document which is not intended to change any procedures in RFC6335 but only support the IESG in something that came up a couple of times. For such document it is not uncommon to have them as AD-sponsored.

Mirja


    
    Joe