Re: [dispatch] New Version of draft-vanelburg-dispatch-private-network-ind
Mary Barnes <mary.ietf.barnes@gmail.com> Tue, 29 October 2013 14:11 UTC
Return-Path: <mary.ietf.barnes@gmail.com>
X-Original-To: dispatch@ietfa.amsl.com
Delivered-To: dispatch@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 34C7511E815F for <dispatch@ietfa.amsl.com>; Tue, 29 Oct 2013 07:11:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.614
X-Spam-Level:
X-Spam-Status: No, score=-101.614 tagged_above=-999 required=5 tests=[AWL=-0.681, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, SARE_HTML_USL_OBFU=1.666, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id McBYkRe8NEoA for <dispatch@ietfa.amsl.com>; Tue, 29 Oct 2013 07:11:40 -0700 (PDT)
Received: from mail-wg0-x22d.google.com (mail-wg0-x22d.google.com [IPv6:2a00:1450:400c:c00::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 24CC111E8179 for <dispatch@ietf.org>; Tue, 29 Oct 2013 07:11:34 -0700 (PDT)
Received: by mail-wg0-f45.google.com with SMTP id z12so8423289wgg.24 for <dispatch@ietf.org>; Tue, 29 Oct 2013 07:11:34 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=OMD8JYRI6VR+YPG3OPatlN9ankLL26mNWTWiBfRs4eQ=; b=W0YlIaY13KoiHnRnEXlkQzeGsNIr1asT786enbyvem7EQM4ZbGPjUZgEipxneNKCZS PjDPV7LRI+BJWTa+V9q1wrQK1uQveQG75I7F79g3b+yjp/EmPew55juMibla1nI54sM5 8BfGL+CbXWfaWuCfKbPNtQKSgs3t5VYepUuO766ETCtkOP7ZnQQY2c341f02S2xKiOYA /JrCC4Fmz/KaP2oFvpWrAnFPCMcE48IFCu+iDthCMYaN8qeWxqKyQ8527IKVfoMPyrjs nCMPQ7hOZuc1+OCe7eHG5Tcf0yWIC2oBG5/HwIo7xxIyVf25dfD1VVuo6RngEOWCRK17 EW3g==
MIME-Version: 1.0
X-Received: by 10.194.232.4 with SMTP id tk4mr2243022wjc.79.1383055894088; Tue, 29 Oct 2013 07:11:34 -0700 (PDT)
Received: by 10.216.36.4 with HTTP; Tue, 29 Oct 2013 07:11:33 -0700 (PDT)
In-Reply-To: <523124B0.2000305@ntt-at.co.jp>
References: <20130912005949.3447.42089.idtracker@ietfa.amsl.com> <523124B0.2000305@ntt-at.co.jp>
Date: Tue, 29 Oct 2013 09:11:33 -0500
Message-ID: <CAHBDyN6oH7OYbq2E26Mo_7KOqx6JZ2mz3CWqQRpfoAXsyLb51A@mail.gmail.com>
From: Mary Barnes <mary.ietf.barnes@gmail.com>
To: Mayumi Ohsugi <mayumi.ohsugi@ntt-at.co.jp>
Content-Type: multipart/alternative; boundary="001a11348472459d1404e9e1cbfb"
Cc: DISPATCH <dispatch@ietf.org>
Subject: Re: [dispatch] New Version of draft-vanelburg-dispatch-private-network-ind
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dispatch>, <mailto:dispatch-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dispatch>
List-Post: <mailto:dispatch@ietf.org>
List-Help: <mailto:dispatch-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 29 Oct 2013 14:11:41 -0000
In reviewing the document in preparation for the PROTO write-up, I have a few comments (minor and nits) that should be addressed prior to the document being progressed. Regards, Mary. Comments: --------------- - General: domains used in this document must use a reserved domain such as "example.com" and must not use real domains. Thus, all occurrences of ericsson.com need to be changed to example.com - Section 1.5. Bulleted list, first bullet. I would suggest you just leave out the mention of LI. Emergency services should be a sufficient example. - Section 1.5, last numbered list, item 2. I had a hard time groking this sentence and had to read several times. I would suggest rewording something like (if I've properly interpreted the intent): OLD: Different nodes spanning over different networks may need to be able to act differently on type of traffic, when implicit schemes are used, it would require distribution of such enterprise specific logic over multiple nodes in multiple operators. That is clearly not a manageable architecture and solution. NEW: Nodes spanning multiple networks often need to have different behavior depending upon the type of traffic. When this is done using implicit schemes, enterprise specific logic must be distributed across multiple nodes in multiple operator's networks. That is clearly not a manageable architecture and solution. - Section 1.5, last sentence. I don't think that statement is sufficient for what this document is doing. I would suggest you change that sentence to something like the following: OLD: Given the above background this document will formulate requirements for SIP to support an explicit private network indication. NEW: Based on the background provided, this document formulates requirements for SIP to support an explicit private network indication and defines a P-header, P-Private-Network-Indication, to support those requirements. - Section 3, next to last paragraph. I'm not sure what is meant by "the filling out a Spec(T)". I don't see "filling" used as a concept in RFC 3324. Perhaps, "specifying a Spec(T)" is more consistent with terminology in RFC 3324. - Section 5. In general, the requirements are not specific consistently - i.e., some use 2119 language and others not and there is not consistent capitalization. I would suggest the following changes. R2: "The indication from R1 can be inserted by a SIP proxy" -> "The indication from R1 MAY be inserted by a SIP proxy" R3: "The indication from R1 can be removed by a SIP proxy" -> "The indication from R1 MAY be removed by a SIP proxy" R6: "must" -> "MUST" - Section 6, 2nd paragraph. The "can" in the first sentence should be a "MAY" and the sentence needs to be split into two: OLD: A proxy server which handles a message can insert such a P-Private- Network-Indication header field into the message based on authentication of the source of a message, configuration or local policy, and forward it to other proxies in the same administrative domain or proxies in trusted domain to be handled as private network traffic. NEW: A proxy server which handles a message MAY insert such a P-Private- Network-Indication header field into the message based on authentication of the source of a message, configuration or local policy. A proxy server MAY forward the message to other proxies in the same administrative domain or proxies in a trusted domain to be handled as private network traffic. Section 9. You should be explicit about the header name in this section. The text in the first paragraph needs some work. At a minimum you need to change the "not supposed to" to something more definitive as all security issues arise because someone does something they're not supposed to. I would suggest at least making the following change: OLD: The private network indication defined in this document is to be used in an environment where elements are trusted and where attackers are not supposed to have access to the protocol messages between those elements. Traffic protection between network elements is sometimes achieved by using IPsec and sometimes by physical protection of the network. In any case, the environment where the private network indication will be used ensures the integrity and the confidentiality of the contents of this header field. NEW: The private network indication defined in this document MUST only be used in an environment where elements are trusted and where attackers are do not have access to the protocol messages between those elements. Traffic protection between network elements can be achieved by using IPsec and sometimes by physical protection of the network. In any case, the environment where the private network indication will be used ensures the integrity and the confidentiality of the contents of this header field. Nits: ------ - Section 1.1: "3rd-Generqation" -> 3rd-Generation - The terms "break-in" and "break-out" traffic are used several places in the document, but this term is never defined. These terms should be defined in Section 3. - Figures should have Titles for readability On Wed, Sep 11, 2013 at 9:19 PM, Mayumi Ohsugi <mayumi.ohsugi@ntt-at.co.jp>wrote: > Hi, > > I have submitted the following draft: > > http://www.ietf.org/internet-**drafts/draft-vanelburg-** > dispatch-private-network-ind-**03.txt<http://www.ietf.org/internet-drafts/draft-vanelburg-dispatch-private-network-ind-03.txt> > > The draft reflects all the comments discussed in DISPATCH list. > > The major changes are as follows: > > - corrected the abstract > - corrected the term "common domain" to "pre-arranged domain" > - added 7.1.4 "P-Private-Network-Indication verification" > - editorial changes > > Regards, > Mayumi > ______________________________**_________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/**listinfo/dispatch<https://www.ietf.org/mailman/listinfo/dispatch> >
- [dispatch] New Version of draft-vanelburg-dispatc… Mayumi Ohsugi
- Re: [dispatch] New Version of draft-vanelburg-dis… Mary Barnes
- Re: [dispatch] New Version of draft-vanelburg-dis… Paul Kyzivat
- Re: [dispatch] New Version of draft-vanelburg-dis… Mary Barnes
- Re: [dispatch] New Version of draft-vanelburg-dis… Shida Schubert
- Re: [dispatch] New Version of draft-vanelburg-dis… Shida Schubert
- Re: [dispatch] New Version of draft-vanelburg-dis… Mary Barnes
- Re: [dispatch] New Version of draft-vanelburg-dis… Shida Schubert
- Re: [dispatch] New Version of draft-vanelburg-dis… DRAGE, Keith (Keith)
- Re: [dispatch] New Version of draft-vanelburg-dis… Mary Barnes
- Re: [dispatch] New Version of draft-vanelburg-dis… Shida Schubert
- Re: [dispatch] New Version of draft-vanelburg-dis… Mary Barnes