Re: [dhcwg] Follow up from IETF-95 - draft-ietf-dhc-dhcpv6-prefix-length-hint-issue

"Bernie Volz (volz)" <volz@cisco.com> Thu, 21 April 2016 21:14 UTC

Return-Path: <volz@cisco.com>
X-Original-To: dhcwg@ietfa.amsl.com
Delivered-To: dhcwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A134F12E51D for <dhcwg@ietfa.amsl.com>; Thu, 21 Apr 2016 14:14:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -15.516
X-Spam-Level:
X-Spam-Status: No, score=-15.516 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 eUsUQnraglX0 for <dhcwg@ietfa.amsl.com>; Thu, 21 Apr 2016 14:14:08 -0700 (PDT)
Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6740412DF13 for <dhcwg@ietf.org>; Thu, 21 Apr 2016 14:14:08 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=24696; q=dns/txt; s=iport; t=1461273248; x=1462482848; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=2Yj3fvzUfCuElMM66t+g8cdC10hXbWda3dGmxi3jd6Q=; b=kPoHG6nagRMlwfcP4s00fP3G+9roHhv1slEVFI33CMfsOkSd3YkJnq9J jxZsbFxx/KTcq/ybcEhsIq5poafSu6jS1NpnxBMIOj5qmDyvTPpOy/kQ0 Tgzb7m6hVwIYwsvh7svRUssffkt2DdCAz5UJwCFzveVRdmkPvfd1jex4P A=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0BPAgAyQhlX/5NdJa1UCoJsTFN9BrUFhHIBDYF0FwEMhWoCHIEROBQBAQEBAQEBZSeEQQEBAQMBAQEBIApBCwUHBAIBCA4DBAEBAScDAgICJQsUCQgCBA4FCIgaCA6ubZEfAQEBAQEBAQEBAQEBAQEBAQEBAQEBEQSKbIQVEkUJgkqCVgWYDwGFeogSgW2ETYhdhiOJCgEeAQFCgjSBNWyHeH4BAQE
X-IronPort-AV: E=Sophos; i="5.24,514,1454976000"; d="scan'208,217"; a="96285722"
Received: from rcdn-core-11.cisco.com ([173.37.93.147]) by rcdn-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 21 Apr 2016 21:13:40 +0000
Received: from XCH-RCD-001.cisco.com (xch-rcd-001.cisco.com [173.37.102.11]) by rcdn-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id u3LLDedD025623 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 21 Apr 2016 21:13:40 GMT
Received: from xch-aln-003.cisco.com (173.36.7.13) by XCH-RCD-001.cisco.com (173.37.102.11) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Thu, 21 Apr 2016 16:13:39 -0500
Received: from xch-aln-003.cisco.com ([173.36.7.13]) by XCH-ALN-003.cisco.com ([173.36.7.13]) with mapi id 15.00.1104.009; Thu, 21 Apr 2016 16:13:39 -0500
From: "Bernie Volz (volz)" <volz@cisco.com>
To: Ted Lemon <mellon@fugue.com>
Thread-Topic: [dhcwg] Follow up from IETF-95 - draft-ietf-dhc-dhcpv6-prefix-length-hint-issue
Thread-Index: AdGb7R0TyBAg+bfuQhK82oWwAy+O+AAOFV4AAAAqeIAAAPMKAAAIpAiw///TeYCAAEdW4A==
Date: Thu, 21 Apr 2016 21:13:39 +0000
Message-ID: <48d576be7b85448b99e9b2745837e59a@XCH-ALN-003.cisco.com>
References: <0a8817dba2ea46c88ca67334a11c956d@XCH-ALN-003.cisco.com> <DE53D859-B436-4F5B-A475-BA27B9AF8359@employees.org> <CAPt1N1mODQYscemGNoicjiFa6sKdKeYrpBkVNjbHhDERC-7hNA@mail.gmail.com> <778BB254-D3FF-4FF3-9AC5-CA2B8DF6F04D@employees.org> <dc0fd93699e9464cb5fa6df2c2c10afb@XCH-ALN-003.cisco.com> <CAPt1N1mWKw6TMKALrw2OTbCXiFGWeY3A5WeQMPCQGEvApaJy5w@mail.gmail.com>
In-Reply-To: <CAPt1N1mWKw6TMKALrw2OTbCXiFGWeY3A5WeQMPCQGEvApaJy5w@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.131.77.252]
Content-Type: multipart/alternative; boundary="_000_48d576be7b85448b99e9b2745837e59aXCHALN003ciscocom_"
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/dhcwg/fw4rYhsRdWUWtozvJ0U2yylJqAw>
Cc: "dhcwg@ietf.org" <dhcwg@ietf.org>
Subject: Re: [dhcwg] Follow up from IETF-95 - draft-ietf-dhc-dhcpv6-prefix-length-hint-issue
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: <dhcwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dhcwg/>
List-Post: <mailto:dhcwg@ietf.org>
List-Help: <mailto:dhcwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 21 Apr 2016 21:14:12 -0000

Ted … if we put normative text in, it will be Standards Track.


-          Bernie

From: Ted Lemon [mailto:mellon@fugue.com]
Sent: Thursday, April 21, 2016 4:28 PM
To: Bernie Volz (volz) <volz@cisco.com>
Cc: dhcwg@ietf.org; otroan@employees.org
Subject: RE: [dhcwg] Follow up from IETF-95 - draft-ietf-dhc-dhcpv6-prefix-length-hint-issue


Ole's suggestion is correct except that if we have normative language in the document, the iesg is going to ask why it's informative. There isn't any question to debate here. Either it's normative, iwc PS, or it's not normative, iwc informative. I feel like Ole may just be resisting publishing it at all, iwc we should do that, not confuse the iesg. But I think that would be the wrong move, because we don't know when 3315bis will get consensus.
On Apr 21, 2016 4:02 PM, "Bernie Volz (volz)" <volz@cisco.com<mailto:volz@cisco.com>> wrote:
While https://tools.ietf.org/html/draft-cui-dhc-dhcpv6-prefix-length-hint-issue-01 was standards track and had RFC2119 "requirements language", it was never used. So, the draft-cui-dhc-dhcpv6-prefix-length-hint-issue-02 was changed to informational. However, The RFC2119 requirements language section wasn't removed until draft-ietf-dhc-dhcpv6-prefix-length-hint-issue-00 was published.

So, perhaps Ole's suggestion for the authors to propose what they think should be normative (there was a suggestion that section 2.5 be) is a good one. And, from that we can see if Standards Track is more appropriate.

BTW: The text about assigning a /48 was in an "e.g." (for example) section. And that would not be normative and was never intended to be:

                                E.g.  If the delegating router could only
   provide prefixes of lengths /30, /48, and /56, and the requesting
   router is requesting for a /50 in the prefix-length hint, then the
   delegating router should provide the /48 to the requesting router

- Bernie

-----Original Message-----
From: otroan@employees.org<mailto:otroan@employees.org> [mailto:otroan@employees.org<mailto:otroan@employees.org>]
Sent: Thursday, April 21, 2016 3:00 PM
To: Ted Lemon <mellon@fugue.com<mailto:mellon@fugue.com>>
Cc: Bernie Volz (volz) <volz@cisco.com<mailto:volz@cisco.com>>; dhcwg@ietf.org<mailto:dhcwg@ietf.org>
Subject: Re: [dhcwg] Follow up from IETF-95 - draft-ietf-dhc-dhcpv6-prefix-length-hint-issue

Ted,

> Ole, the point is that if the document makes any normative statements, it's got to be standards-track.   You are quite right that the particular statements you call out should not be made normatively, though!

Agree, one option if we can identify what's normative in the document would be to add that text to the 3315bis and leave this informational.

RFC2119-ifying the text the authors think should be normative would be a good start.

cheers,
Ole

>
> On Thu, Apr 21, 2016 at 2:28 PM, <otroan@employees.org<mailto:otroan@employees.org>> wrote:
> there are some parts that could be made normative, like section 2.5.
> but most of the document appears informational in nature.
> paraphrased example: "the server should delegates a /48 if the client requests it".
> that's clearly policy, and a matter of the possible commercial arrangement, seems strange if the IETF should try to codify that.
>
> I lean towards informational.
>
> the document also does not say anything about _how_ the client is supposed to figure out what sized address block to request.
> if the answer to that is manual configuration, then there are tens of ways that could be done differently out of band.
>
> cheers,
> Ole
>
>
>
> > On 21 Apr 2016, at 18:45, Bernie Volz (volz) <volz@cisco.com<mailto:volz@cisco.com>> wrote:
> >
> > Hi:
> >
> > One item that was raised at the IETF-95 DHC WG session was the recent change (suggested by me before draft-cui-dhc-dhcpv6-prefix-length-hint-issue-02 was published) to switch draft-ietf-dhc-dhcpv6-prefix-length-hint-issue to Informational rather than Standards Track. Marcin Siodelski suggested that the document be Standards Track:
> >
> > The brief (draft) minutes for this discuss are:
> >
> > ---
> > 5. DHCPv6 Prefix Length Hint Issues, Bernie Volz (for Tianxiang Li) - 10 minutes, 14:50
> >     draft-ietf-dhc-dhcpv6-prefix-length-hint-issue
> >
> >     The authors believe work is ready for WGLC.
> >
> >     Ian: Is this now informational? "This is the suggested way to do it"?
> >     Bernie: Correct. There were some discussions and the conclusion was to not
> >        enforce it.
> >     Marcin (on jabber): I'd suggest this is standards track doc with normative language
> >        in. Otherwise implementations will ignore hints.
> > ---
> >
> > Once we resolve this open question (and after a possible update to the document), we intend to start a WGLC on the document.
> >
> > Please respond with your comments as to whether this document should be Informational or Standards Track by May 5th, 2016. Of course, any other comments are welcome as well!
> >
> > Thanks!
> >
> > -          Tomek & Bernie
> > _______________________________________________
> > dhcwg mailing list
> > dhcwg@ietf.org<mailto:dhcwg@ietf.org>
> > https://www.ietf.org/mailman/listinfo/dhcwg
>
>
> _______________________________________________
> dhcwg mailing list
> dhcwg@ietf.org<mailto:dhcwg@ietf.org>
> https://www.ietf.org/mailman/listinfo/dhcwg
>
>