This archive is retained to ensure existing URLs remain functional. It will not contain any emails sent to this mailing list after July 1, 2024. For all messages, including those sent before and after this date, please visit the new location of the archive at https://mailman.ripe.net/archives/list/ncc-services-wg@ripe.net/
[ncc-services-wg] 2012-07 New Draft Document and Impact Analysis Published (RIPE NCC Services to Legacy Internet Resource Holders)
- Previous message (by thread): [ncc-services-wg] 2012-07 New Draft Document and Impact Analysis Published (RIPE NCC Services to Legacy Internet Resource Holders)
- Next message (by thread): [ncc-services-wg] 2012-07 New Draft Document and Impact Analysis Published (RIPE NCC Services to Legacy Internet Resource Holders)
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Rob Evans
rhe at nosc.ja.net
Mon Oct 21 14:15:35 CEST 2013
Hi, > We encourage you to read the draft document text and send any comments to ncc-services-wg at ripe.net before 8 November 2013. I (personally, of course) support this proposal. In the interests of discussion, though, I'll note that my interpretation of 'Registry Service Elements' in section 1.1 was any single service provided by the RIR, either current or future. However, in the impact analysis the RIPE NCC has interpreted it as only any one of the specific existing services mentioned in 1.1. Does that match with the authors' intention? (If not, does it matter?) Not knowing how the RIPE NCC performs checks on the holder of legacy resources, the onus appears to be on the holder to submit appropriate documentation. Is it safe to assume that the NCC also has a record of relevant InterNIC records to match who the resources were originally assigned to, and so if the holder hasn't changed then the documentation could be along the lines of just checking the organisations match? I'll also note that we had a brief discussion in last week's routing working group session relevant to the part of section 'D' of the impact analysis relating to adding an attribute to the aut-num object. Most of the comments tended to suggest that as long as the RFC says unknown attributes should be ignored, then there should be little problem. However, sufficient notice will need to be given so that tools that work off local copies of the aut-num will submit it with the relevant fields (or given that it isn't something the holder can change, the update software can add the correct line in if it is missing in an update). Cheers, Rob -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 203 bytes Desc: Message signed with OpenPGP using GPGMail URL: </ripe/mail/archives/ncc-services-wg/attachments/20131021/282c5993/attachment.sig>
- Previous message (by thread): [ncc-services-wg] 2012-07 New Draft Document and Impact Analysis Published (RIPE NCC Services to Legacy Internet Resource Holders)
- Next message (by thread): [ncc-services-wg] 2012-07 New Draft Document and Impact Analysis Published (RIPE NCC Services to Legacy Internet Resource Holders)
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]