Re: [sidr] WGLC draft-sidr-rpki-rtr - take 2?

"t.petch" <> Mon, 22 August 2011 12:05 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id D873721F8B1D; Mon, 22 Aug 2011 05:05:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.445
X-Spam-Status: No, score=-2.445 tagged_above=-999 required=5 tests=[AWL=0.154, BAYES_00=-2.599]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id dVAXGPahlh8n; Mon, 22 Aug 2011 05:05:56 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 4567E21F8B1C; Mon, 22 Aug 2011 05:05:52 -0700 (PDT)
Received: from (HELO pc6) ([]) by with SMTP id EBP98034; Mon, 22 Aug 2011 13:06:54 +0100 (BST)
Message-ID: <001801cc60bb$19329d00$>
From: "t.petch" <>
To: Christopher Morrow <>,,, Randy Bush <>
References: <> <>
Date: Mon, 22 Aug 2011 13:03:11 +0200
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
X-Mirapoint-IP-Reputation: reputation=Fair-1, source=Queried, refid=tid=0001.0A0B0301.4E52465E.0039, actions=tag
X-Junkmail-Status: score=10/50,
X-Junkmail-Signature-Raw: score=unknown, refid=str=0001.0A0B020A.4E52465F.0151, ss=1, fgs=0, ip=, so=2010-07-22 22:03:31, dmn=2009-09-10 00:05:08, mode=multiengine
X-Junkmail-IWF: false
Subject: Re: [sidr] WGLC draft-sidr-rpki-rtr - take 2?
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Secure Interdomain Routing <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 22 Aug 2011 12:05:58 -0000


I don't know if your training included
currently in AUTH48 but it does say, as some on this list know well,

"   A service name or port number assignment request contains the
   following information.  The service name is the unique identifier of
   a given service:

      Service Name (REQUIRED)
      Transport Protocol(s) (REQUIRED)
      Assignee (REQUIRED)
      Contact (REQUIRED)
      Description (REQUIRED)
      Reference (REQUIRED)
      Port Number (OPTIONAL)
      Service Code (REQUIRED for DCCP only)
      Known Unauthorized Uses (OPTIONAL)
      Assignment Notes (OPTIONAL)"

which suggests a fairly rapid rejection of our I-D.  The section on two ports or
one, which I alluded to earlier, is section 7.2 which starts with
"   o  IANA strives to assign only one assigned port number per service
      or application"

Uh huh; I wish the iana I-D did not say what it says, and argued against it, in
tsvwg and ietf, but it does and is about to become an RFC which will control our
lives; sigh:-(

Tom Petch

----- Original Message -----
From: "Christopher Morrow" <>
To: <>; <>; "Randy Bush" <>
Sent: Friday, August 19, 2011 6:00 AM
Subject: Re: [sidr] WGLC draft-sidr-rpki-rtr - take 2?

Waking a longishly dead thread to call some form of consensus on what
is now rev16 of this draft:

I believe we cycled around most of the heated parts, finding
compromise and reaching steady-state (last real message on this topic
was 5 or so days ago).

At this point I think we're safe to go forward to IESG review. I'll be
packaging up a protos doc and mailing that forward tomorrow.


On Wed, Feb 16, 2011 at 1:39 PM, Christopher Morrow
<> wrote:
> Ok folk,
> The rpki-rtr document:
> <>
> went through WGLC on version ~02, it's since had a slight mod (added a
> Cache-nonce added) which is here in section 4.1:
> "The Cache Nonce reassures the router that the serial numbers are
> comensurate, i.e. the cache session has not been changed."
> and again in 4.2:
> "The Cache Nonce tells the cache what instance the router expects to
> ensure that the serial numbers are comensurate, i.e. the cache
> session has not been changed."
> and again in 4.4:
> "In response to a Reset Query, the Cache Nonce tells the router the
> instance of the cache session for future confirmation. In response
> to a Serial Query, the Cache Nonce reassures the router that the
> serial numbers are comensurate, i.e. the cache session has not been
> changed."
> and again in 4.7:
> "The Cache Nonce MUST be the same as that of the corresponding Cache
> Response which began the, possibly null, sequence of data PDUs."
> There's not much meat to the actual change, and the authors identified
> the problem on their own. So, in the spirit of valentines day, let's
> decide by Friday Feb 18, 2011 23:59 UTC if things are still ok to move
> forward. If there are no further comments/issues I'll push this
> version out over the weekend to the AD's as a publication request.
> -Chris
> <co-chair-messenger-bag==off>
sidr mailing list