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