Re: [sidr] WGLC: draft-ietf-sidr-rpsl-sig - End Jul 02 2015

[Geoff Huston <[e-mail]>]

section 3.1, bullet 4 - s/notaion/notation/

Bullet 4 of this list looks confused

* Date and time fields MUST be converted to 64-bit NTP Timestamp Format [RFC5905].

    thats a binary value, 32 bits of seconds since epoch and 32 bitss of fractions - right?
    Does this also mean that the Era is 1 January 1900?

*  AS numbers MUST be converted to ASPLAIN syntax [RFC5396].

    hang on - thats ascii - why is the time field binary and this field ascii?

*  IPv6 addresses must be canonicalized as defined in [RFC5952].

    this is also ascii

*  IPv4 addresses MUST be converted to a 32-bit representation
         (e.g., Unix's inet_aton()).

    inet_aton returns a binary struct - which is NOT ascii.


*  All IP prefixes (IPv4 and IPv6) MUST be represented in CIDR
         notaion [RFC4632].

    so I think you are referring to a range of IP addresses.


    I assume that this means that at times this will be a list of addresses
    (i.e. the range of addresses 10.0.0.1 - 10.0.0.2 is 10.0.0.1/32 and 10.0.0.2/32)

    Are you wanting a cononical CIDR form? (i.e. should the pair of prefixes 10.0.0.0/24 and 10.0.1.0/24
    be represented as 10.0.0.0/23?)


    Other RPKI specs (e.g. RFC6487) referenced the canonical representation of a
    set of addresses as defined in RFC3779. I assume you had a good reason not to
    use the same approach


So why are some items in this list ascii and some binary? Would it make more sense to use either all binary or all ascii here?



regards,

   Geoff

On 18 Jun 2015, at 7:14 pm, Chris Morrow <[e-mail]> wrote:

Howdy WG Folks,

Today is your day! we start a WGLC for:
draft-ietf-sidr-rpsl-sig
<https://tools.ietf.org/html/draft-ietf-sidr-rpsl-sig-07>

Abstract:
"This document describes a method to allow parties to electronically
 sign RPSL-like objects and validate such electronic signatures.  This
 allows relying parties to detect accidental or malicious
 modifications on such objects.  It also allows parties who run
 Internet Routing Registries or similar databases, but do not yet have
 RPSS-like authentication of the maintainers of certain objects, to
 verify that the additions or modifications of such database objects
 are done by the legitimate holder(s) of the Internet resources
 mentioned in those objects."

This document is through 7 revisions, over quite a period of time, the
Authors feel as though they have attended to all commentary so far and
would appreciate a final read-through and thought about pushing this
forward to IETF Last Call.

Thanks!
-chris
co-chair-will-o-the-wisp

_______________________________________________
sidr mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/sidr