[Insipid] Mirja Kühlewind's No Objection on draft-ietf-insipid-logme-marking-12: (with COMMENT)
Mirja Kühlewind <ietf@kuehlewind.net> Mon, 13 August 2018 16:24 UTC
Return-Path: <ietf@kuehlewind.net>
X-Original-To: insipid@ietf.org
Delivered-To: insipid@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B776130E06; Mon, 13 Aug 2018 09:24:06 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: Mirja Kühlewind <ietf@kuehlewind.net>
To: The IESG <iesg@ietf.org>
Cc: draft-ietf-insipid-logme-marking@ietf.org, insipid-chairs@ietf.org, gsalguei@cisco.com, insipid@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.83.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <153417744610.24989.8583018232862453031.idtracker@ietfa.amsl.com>
Date: Mon, 13 Aug 2018 09:24:06 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/insipid/uIiAVFUA8QB4JRdT-5dya_dlBRs>
Subject: [Insipid] Mirja Kühlewind's No Objection on draft-ietf-insipid-logme-marking-12: (with COMMENT)
X-BeenThere: insipid@ietf.org
X-Mailman-Version: 2.1.27
List-Id: SIP Session-ID discussion list <insipid.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/insipid>, <mailto:insipid-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/insipid/>
List-Post: <mailto:insipid@ietf.org>
List-Help: <mailto:insipid-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/insipid>, <mailto:insipid-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 13 Aug 2018 16:24:06 -0000
Mirja Kühlewind has entered the following ballot position for draft-ietf-insipid-logme-marking-12: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-insipid-logme-marking/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- A couple of quick comments/questions: 1) How do you know that both endpoints are "log me" enabled? I guess because of the requirement that all messages of a dialog must have the marker, you cannot just add it and see if the other end is able to apply it to its responses...? 2) Sec 3.2: "firstly because it is configured to do so, or secondly because it has detected that a dialog is being "log me" marked, causing it to maintain state to ensure that all requests and responses in the dialog are similarly "log me" marked." I was first quite confused by this sentence because I though the second case meant that intermediates needs to ensure that all messages are marked correctly. However, I guess the second case is when the other ends is configured to do marking, one needs to reply with the marking as well. I think I was mainly confused by the word "detects". Maybe it's worth to further clarify this sentence...? 3) Section 4.6 feels a little misplace but I not sure where it belong otherwise (maybe section 3 or 5?). Or maybe move section 4.5 in an own section later in the doc...? 4) Also Section 4.6: "It MUST NOT forward the "log me" marker" Does it mean an intermediate MUST remove the marker if an error is detected? Is that safe given the proxy scenarios? If at all I would recommend to use MAY here, I guess... 5) Sec 8.1.: "An end user or network administrator MUST give permission for a terminal to perform "log me" marking in the context of regression testing or troubleshooting a problem. " and "The configuration of a SIP intermediary to perform "log me" marking on behalf of a terminal MUST be authorized by the network administrator." I'm actually not sure what these normative sentences mean for an implementation. Is this maybe rather "An implementation MUST provide a configuration to active logging and logging MUST be disabled by default."? 6) Section 8.2: "If SIP requests and responses are exchanged with an external network with which there is no agreement to pass "log me" marking, then the "log me" marking is removed." Should this be normative, maybe: "If SIP requests and responses are exchanged with an external network with which there is no agreement to pass "log me" marking, then the "log me" marking SHOULD be removed at the network border." Or MUST? 7) Also a related question: Should a network perform ingress filtering/removal of "log me" markers? 8) Nit: Sec 2: I guess the following sentence was coped and pasted from RFC8123 and should be removed for this doc: "Rather than describing interoperability requirements, they are used to describe requirements to be satisfied by the "log me" marking solution."
- [Insipid] Mirja Kühlewind's No Objection on draft… Mirja Kühlewind
- Re: [Insipid] Mirja Kühlewind's No Objection on d… Arun Arunachalam (carunach)
- Re: [Insipid] Mirja Kühlewind's No Objection on d… Mirja Kühlewind
- Re: [Insipid] Mirja Kühlewind's No Objection on d… Arun Arunachalam (carunach)
- Re: [Insipid] Mirja Kühlewind's No Objection on d… Ben Campbell
- Re: [Insipid] Mirja Kühlewind's No Objection on d… Mirja Kuehlewind (IETF)
- Re: [Insipid] Mirja Kühlewind's No Objection on d… Dawes, Peter, Vodafone Group
- Re: [Insipid] Mirja Kühlewind's No Objection on d… Arun Arunachalam (carunach)
- Re: [Insipid] Mirja Kühlewind's No Objection on d… Mirja Kuehlewind (IETF)
- Re: [Insipid] Mirja Kühlewind's No Objection on d… Dawes, Peter, Vodafone Group
- Re: [Insipid] Mirja Kühlewind's No Objection on d… Benjamin Kaduk
- Re: [Insipid] Mirja Kühlewind's No Objection on d… Dawes, Peter, Vodafone Group