On Dec 6, 2010, at 5:12 PM, Marc Petit-Huguenin <[email protected]> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> More questions, comments and nits:
>
> A.13. Section 5.3.1.1 "...ResourceIds are variable length, up to 255 bytes
> (2048
> bits)..."
>
> Because Destination has a length field defined as an uint8 that effectively
> limits the size of DestinationData to 255 bytes, and because ResourceId is
> prefixed by one byte indicating the length, the ResourceId length is limited
> to
> 254 bytes, or 2032 bits.
2040 bits.
>
> A.14. Section 5.3.2 "uint32 length;"
>
> I can assume that this length covers the Header, MessageContents and
> Signature,
> but I would guess that this was useful when Message was sent without
> FramingHeader over TCP (same than for the relo_token used to disambiguate STUN
> packets). Now that this is useless, can't this length been only Header and
> MessageContents, so it is possible to find the boundary between
> MessageContents
> and Signature without having to parse MessageContents at all?
>
> A.15. Section 5.3.4 "HashAlgorithm hash_alg;"
>
> What are the algorithms that should be supported?
> Is the hash only used to identify the certificate in
> SecurityBlock.certificates?
No, it is used for AOR storage among other things.
> Also the text says that "[t]he certificate_hash contains the hash of the
> certificate object." Are we talking about the hash of the DER encoded
> certificate, as stored in GenericCertificate.certificate?
The binary representation, yes.
>
> A.16. Section 5.5.1.1. "IceCandidate candidates<0..2^16-1>;"
>
> Because there must be at least one candidate, should this be:
>
> IceCandidate candidates<1..2^16-1>;
The storage is still <0 .. 2 ^ 16 - 1> but your also correct.
>
> A.17. "config_data (type==config)"
>
> The definition of this field is "[t]he contents of the configuration
> document",
> but 10.1 says that a file "...can contain multiple 'configuration'
> elements...".
> So should not this field be in fact defined as "One XML configuration
> production. This MUST be encoded with UTF-8 and assume a default namespace of
> ...", like for the kinds value?
It's an XML document with unlimited configuration elements possible.
> And in this case what about the signature
> element in the XML fragment?
>
???
> A.18. Section 5.6.2 "...not all aspects of the header apply to both types of
> transports."
>
> It would be great if this could be explained a little bit more. For example I
> assume that on a reliable link, the receiver still need to send the Ack for
> each
> frame received (to calculate the RTO), but what about the content of the
> ack_sequence and received fields?
>
> A.19. Section 5.6.3.1.1, last paragraph
>
> This paragraph described a lockstep algorithm, but if it is the case then
> there
> is no need for the received field, as we would always know that the previous
> messages have been received.
>
> A.20. Section 5.7, "If the message is not fragmented, then both the first and
> last fragment are set to 1..."
>
> If the first fragment bit is set to 1 when the message is fragmented and is
> also
> set to one when the message is not fragmented, then it is always set to 1, so
> what is the point of having it in the first place?
I think you misread. There are two fragment flags, begin and end.
>
> A.21. Section 10.1. "<kind name='sip-registration'><data-model>..."
>
> Why do we need to repeat the data-model and access-control that were already
> in
> the IANA registry? Or is it a way to override the IANA definitions as the
> example would suggest? (as the registration for SIP-REGISTRATION is using
> DICTIONARY and USER-NODE-MATCH).
>
> A.22. Section 10.1. "sequence: a monotonically increasing sequence number
> between 1 and 2^32"
>
> According to section 5.3.2 and 5.3.2.1, it should be between 0 and 2^16-2
> (65534).
>
> A.23. Section 10.1. "root-cert This element..."
>
> I guess that the encoding to use is base64, but it is said nowhere.
>
> A.24. Section 10.1.1. "| attribute id { xsd:int }),"
>
> Does not match 13.6, that is saying that this is an unsigned integer. Should
> probably use xsd:unsignedInt instead.
>
> Note that there is other places in the RELAX NG document where the type can be
> improved (initial-ttl, etc...)
>
> A.25. Section 10.1.1. 'access-control-type |= "user-match-with-anon-create"'
>
> This control type is never defined in the document.
>
> A.26. Section 10.1.1. 'kind-names |= "sip-registration"'
>
> the sip-registration kind is not defined in this document. OTOH,
> certificate-by-node and certificate-by-name are defined, but not listed here.
>
> A.27. Section 10.1.1. 'self-signed-digest-type |= "sha1"'
>
> Section 10.1. says that '[v]alid values for this parameter are "SHA-1" and
> "SHA-256"'.
>
> A.28. Section 10.1.1 last paragraph "such an XML configuration file sent over
> email."
>
> Because the signatures on the XML document are done on exact byte string and
> because emails servers are known to mess with end of lines, we will see
> configuration documents that cannot be verified after been sent by email (what
> was wrong with using XML-sig anyway?).
>
Why would an email server alter an "attachment"? Don't send them in the body.
> A.29. Section 13.15 "destination: a hex-encoded Destination List object"
>
> A Destination List object is never formally defined in the whole document, so
> is
> it just Destination objects packed together, or is it in fact a "Destination
> destination_list<0..2^16-1>" ? In other words, does it start with a length
> field?
>
>
> Nits:
> - ----
>
> - - Section 5.7 After "Where these values are:"
>
> s/resource/resource_id/
>
> - - Section 6.4.1.2. "...that the storing peer is not require to perform this
> verification."
>
> s/require/required/
>
> - --
> Marc Petit-Huguenin
> Personal email: [email protected]
> Professional email: [email protected]
> Blog: http://blog.marc.petit-huguenin.org
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.10 (GNU/Linux)
>
> iEYEARECAAYFAkz9X8sACgkQ9RoMZyVa61db8wCfY920Y+l8ho7H6crmx+Bwbczi
> VOMAn2jqKBSRaf96sNh1P0L34debXb96
> =/8Wr
> -----END PGP SIGNATURE-----
> _______________________________________________
> P2PSIP mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/p2psip
_______________________________________________
P2PSIP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/p2psip
