Re: [Gen-art] Gen-ART review of draft-ietf-dime-rfc4005bis-11

"Black, David" <david.black@emc.com> Mon, 08 October 2012 20:11 UTC

Return-Path: <david.black@emc.com>
X-Original-To: gen-art@ietfa.amsl.com
Delivered-To: gen-art@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A918E21F87F9; Mon, 8 Oct 2012 13:11:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level:
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x26clcZ4oPbd; Mon, 8 Oct 2012 13:11:56 -0700 (PDT)
Received: from mexforward.lss.emc.com (hop-nat-141.emc.com [168.159.213.141]) by ietfa.amsl.com (Postfix) with ESMTP id BA61821F8702; Mon, 8 Oct 2012 13:11:55 -0700 (PDT)
Received: from hop04-l1d11-si04.isus.emc.com (HOP04-L1D11-SI04.isus.emc.com [10.254.111.24]) by mexforward.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id q98KBlHj021251 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 8 Oct 2012 16:11:48 -0400
Received: from mailhub.lss.emc.com (mailhub.lss.emc.com [10.254.221.145]) by hop04-l1d11-si04.isus.emc.com (RSA Interceptor); Mon, 8 Oct 2012 16:11:43 -0400
Received: from mxhub24.corp.emc.com (mxhub24.corp.emc.com [128.222.70.136]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id q98KBeoH030012; Mon, 8 Oct 2012 16:11:41 -0400
Received: from mx15a.corp.emc.com ([169.254.1.83]) by mxhub24.corp.emc.com ([128.222.70.136]) with mapi; Mon, 8 Oct 2012 16:11:41 -0400
From: "Black, David" <david.black@emc.com>
To: Barry Leiba <barryleiba@computer.org>, Glen Zorn <glenzorn@gmail.com>, "precis-chairs@tools.ietf.org" <precis-chairs@tools.ietf.org>
Date: Mon, 08 Oct 2012 16:11:39 -0400
Thread-Topic: Gen-ART review of draft-ietf-dime-rfc4005bis-11
Thread-Index: Ac2leMQ+3QDh/2XtR/iDfUkrQqimgwAFfE4Q
Message-ID: <8D3D17ACE214DC429325B2B98F3AE7120DF11C12@MX15A.corp.emc.com>
References: <8D3D17ACE214DC429325B2B98F3AE7120DCD17FD@MX15A.corp.emc.com> <50712F0A.1050309@gmail.com> <CAC4RtVDDBo+kVJMpS+j1sCHy_qtn0FzLkrpzqysPZTaPTHpm1w@mail.gmail.com>
In-Reply-To: <CAC4RtVDDBo+kVJMpS+j1sCHy_qtn0FzLkrpzqysPZTaPTHpm1w@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-EMM-MHVC: 1
Cc: "dime-chairs@tools.ietf.org" <dime-chairs@tools.ietf.org>, "lionel.morand@orange.com" <lionel.morand@orange.com>, "gen-art@ietf.org" <gen-art@ietf.org>, "draft-ietf-dime-rfc4005bis@tools.ietf.org" <draft-ietf-dime-rfc4005bis@tools.ietf.org>, "dime@ietf.org" <dime@ietf.org>, "ietf@ietf.org" <ietf@ietf.org>
Subject: Re: [Gen-art] Gen-ART review of draft-ietf-dime-rfc4005bis-11
X-BeenThere: gen-art@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "GEN-ART: General Area Review Team" <gen-art.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/gen-art>, <mailto:gen-art-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/gen-art>
List-Post: <mailto:gen-art@ietf.org>
List-Help: <mailto:gen-art-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/gen-art>, <mailto:gen-art-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 08 Oct 2012 20:11:56 -0000

Barry,

> >> 5) Statement that the string contains an FQDN, as stated for one case of
> >> the Tunnel-Client-Endpoint AVP in 4.5.4. That specific statement is
> >> incomplete, as it needs to be accompanied by a normative reference to
> >> a document that specifies the format of internationalized domain
> >> names, and probably needs to also state which types of labels (e.g.,
> >> A-label, U-label) are allowed.
> >>
> >> Every use of UTF8String in this draft needs to be checked, and most
> >> of them are likely to need some attention. The ongoing work in the
> >> precis WG may help with some of this, and I would suggest talking to
> >> the APP ADs, especially Pete Resnick (hi Pete) before embarking on
> >> significant work in this area in order to avoid wasted or duplicated
> >> efforts.
> >
> > OK, this last one bothers me a lot: you /seem /to be suggesting that we hold
> > up this draft to wait for the result of a WG which has yet to publish a
> > problem statement.  I'm sure that that is not the case, but it sure sounds
> > like it.
> 
> David can clarify if I'm wrong, but that's not what it sounds like to
> me.  What it sounds like he's suggesting is that you talk with the
> precis people to see if things are OK, or if there's anything you
> should be doing differently.  I'm adding the precis chairs to this
> message, and asking them to respond to this point.

It's somewhere in between, as things are definitely *not* OK at the moment,
but my reason for suggesting a discussion with the précis folks is to take
advantage of their insights and work to date.  If I thought this draft needed
to wait for the output of the précis WG, I would have indicated which précis
draft ought to be a normative reference (and I did not do that).  Whether
that's a good idea will only be clear after every use of UTF8String is checked.

FWIW, the FQDN situation is worked out, start with a normative reference to
RFC 5890, which includes the specification of the various label types.

> A tangential point, while I'm here:
> 
> >> [4] Based on this text in 4.4.9:
> >> The use of this AVP is NOT RECOMMENDED; the AVPs defined by
> >> Korhonen, et al. [RFC5777] SHOULD be used instead.
> >>
> >> I would have expected RFC5777 to be a Normative Reference, not an
> >> Informative Reference.
> >
> > I don't care particularly, but I don't think that it's really necessary to
> > understand RFC 5777 to understand this document.
> 
> It would seem odd, in general, if something that's a "MUST implement"
> or "SHOULD implement" weren't a normative reference.  But I haven't
> (yet) looked at this particular case to see.

My expectation is the same - if [RFCxxxx] is specified as "MUST implement"
or "SHOULD implement", then I usually expect that RFC to be a normative
reference.

Thanks,
--David
----------------------------------------------------
David L. Black, Distinguished Engineer
EMC Corporation, 176 South St., Hopkinton, MA  01748
+1 (508) 293-7953             FAX: +1 (508) 293-7786
david.black@emc.com        Mobile: +1 (978) 394-7754
----------------------------------------------------