----- Original Message ----- From: "Christopher Morrow" <[email protected]> To: "t.petch" <[email protected]> Cc: <[email protected]>; <[email protected]>; "Randy Bush" <[email protected]> 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 <[email protected]> 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" <[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
