Re: [sidr] WGLC draft-sidr-rpki-rtr

----- Original Message -----
From: "Christopher Morrow" <christopher.morrow@gmail.com>
To: "t.petch" <ietfc@btconnect.com>
Cc: <sidr@ietf.org>; <sidr-chairs@ietf.org>; "Randy Bush" <randy@psg.com>
Sent: Monday, August 22, 2011 3:17 PM
Subject: Re: [sidr] WGLC draft-sidr-rpki-rtr - take 2?

On Mon, Aug 22, 2011 at 7:03 AM, t.petch <ietfc@btconnect.com> wrote:
> Chris
>
> I don't know if your training included
> draft-ietf-tsvwg-iana-ports-10
> currently in AUTH48 but it does say, as some on this list know well,
>

it didn't.

> " 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)"
>

ok, so we had dealt with IANA requests after submission previously (I
thought). We can do that here, or while I make a protos doc an author
could spin a new rev with this data included, eh?

Oddly, 'CONTACT' there is a person? or a WG? a 'person' seems
non-scalable in a number of dimensions. :(
<tp>
Chris

CONTACT can be a WG, the ietf or iesg, or even a person.

My thinking was, be prepared for this to come back to us with a request for
information, rather than spin a new draft; I suspect there will be other
requests as
well.

I have been waiting for a port request to appear since the iana draft was
approved and have not seen one - this may be the first.

The port registry is one of those that IANA has converted to XML rendering it
almost unusable:-(

Tom Petch

</tp>

-chris

> 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" <christopher.morrow@gmail.com>
> To: <sidr@ietf.org>; <sidr-chairs@ietf.org>; "Randy Bush" <randy@psg.com>
> Sent: Friday, August 19, 2011 6:00 AM
> Subject: Re: [sidr] WGLC draft-sidr-rpki-rtr - take 2?
>
>
> Hello,
> Waking a longishly dead thread to call some form of consensus on what
> is now rev16 of this draft:
>
> http://tools.ietf.org/html/draft-ietf-sidr-rpki-rtr-16
>
> 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.
>
> -chris
> (co-chair-in-training)
>
> On Wed, Feb 16, 2011 at 1:39 PM, Christopher Morrow
> <christopher.morrow@gmail.com> wrote:
>> Ok folk,
>> The rpki-rtr document:
>> <http://tools.ietf.org/wg/sidr/draft-ietf-sidr-rpki-rtr>
>>
>> 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
> sidr@ietf.org
> https://www.ietf.org/mailman/listinfo/sidr
>
>