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,
" 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" <[email protected]>
To: <[email protected]>; <[email protected]>; "Randy Bush" <[email protected]>
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
<[email protected]> 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
[email protected]
https://www.ietf.org/mailman/listinfo/sidr
_______________________________________________
sidr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/sidr
