Kommentarer til KTN-løsningsforslag:

oppg 1.1 a)
SMTP kan også brukes til å hente epost ved hjelp av kommandoen ETRN.
Se rfc2821 for informasjon.

oppg 1.1 b)

"Håndterer ikke" har (minst) to betydninger i norsk:  "Er ikke i stand
til å håndtere", og "Bryr seg ikke om, ignorerer".  Med den siste
betydningen vil utsagnet "Does not handle MIME" være helt
meningsfylt. 

oppg 1.1 c)

Hva som menes med epost i denne betydningen er udefinert, er det
cc:Mail, SMTP/POP/IMAP, UUCP eller noe annet?

For enkelte implementasjoner vil utsagnet om at det bruker DNS være
meningsløst, f.eks for UUCP eller andre ikke-IP-baserte
eposttjenester.

"Does support encrypted transfer" kan tolkes på flere måter: støtter
SSL (eller den ekvivalente funksjonen i det lokale miljøet), støtter
PGP (ende-til-ende-krypto der meldingen sett fra epostsystemets side
overføres i klartekst).

"Uses the UDP transport protocol only": Dette vil antakelig være svært
sjelden, men et epostsystem som fungerer over NFS (Network File
System), dvs lokal levering med NFS-montert mailspool vil bruke UDP.
(Forutsatt at man kjører NFS over UDP og ikke TCP.  Sistnevnte er
sjeldent.)

"Is always using the IP protocol":  Se over, for
 epost-over-NFS-over-UDP/IP vil alltid IP brukes.

"Can provide a blind carbon copy":  De fleste epostsystemer i dag
støtter dette, men det er ingenting i begrepet epost som sådan som
tilsier at det er en nødvendig del.

Felles her er at det er svært vanskelig å forstå hva som egentlig
menes med begrepet epost.

1.2 

"HTTP supports caching": HTTP (rfc2616) beskriver cache-begrepet og
kontrollmekanismer.  Presist hva som menes med "supports" er ikke
definert.

"The header includes an IP address":  mu (unask the question).
Spørsmålet er meningsløst, da en HTTP-header godt kan inkludere en
IP-adresse, men ikke nødvendigvis gjør det.

"The GET method is used to read a Web page":  Read a web page er
semantisk flertydig.  HTTP snakker svært lite om sider, den snakker om
ressurser.  GET brukes for å lese eller hente en ressurs.

1.3:

Tilstandsovergangene er svært dårlig definert i sekvensdiagrammet.  I
følge sekvensdiagrammet vil programmet kun forlate "Passive" når den
får en "OpenURL"-melding, løkken til "Passive" bør derfor ikke være
avhengig av at den får en respons.

"Wait user"-tilstanden finnes ikke i sekvensdiagrammet og det virker
underlig å loope så lenge den får timeouts i "Wait user".  Dersom den
får en timeout ville det vært mer naturlig å gå til Wait2.

Videre kan sekvensdiagrammet tolkes dithen at den etter Wait0 skal
sende ut en setup-melding.

2a:
PGP er ingen protokoll ei heller en protokollfamilie.  OpenPGP er en
protokollfamilie.  PGP _kan bruke_ RSA.  Frem til høsten 2000 var RSA
patentert i USA og frie implementasjoner valgte derfor ofte DSA +
ElGamal fremfor RSA.

2c:
Det viktigste er at en nøkkel har tilfeldig mønster, fast lengde er
ikke nødvendig.

"The security obtained by encryption is dependent on the key length":
Sikkerheten som oppnås er i større grad avhengig av algoritmen enn
nøkkellengden.

"In an asymmetric encryption scheme, the public key may be used for
the creation of a public signature": En offentlig nøkkel kan godt
brukes til å genrere en digital signatur -- det er _ingen_ forskjell
på en privat og en offentlig nøkkel (bortsett fra at den ene holdes
hemmelig, hvilken er vilkårlig).

2e: (merket som 2d i LF):

"A digital signature represents the identity of the message source":
En digital signatur representerer nøkkelen til meldingskilden, ikke
kilden selv.

"An eavesdropper that also get hold of the signature of the message,
can easily decrypt the message and read its content": signaturen vil
ikke ha noen påvirkning på lesbarheten til meldingen.  Det var ikke
satt som forutsetning at meldingen var kryptert overhodet.

"Two messages can not have the same hash (message digest)": To
meldinger kan ha samme hash, men det er _svært_ usannsynlig.  Hvis det
var en fullstendig kollisjonsfri hashfunksjon ville man i ytterste
konsekvens kunne lage modellere vilkårlig kompliserte datamodeller i
f.eks 128 bit (for MD5) eller 160 bit (for SHA-1).  Dette er
selvfølgelig vås.

3.1 1:
"The service access points (SAP) have unique global addresses":  Se
RFC1918 for informasjon om private adresser som ikke er garantert å
være unike.  Disse skal da selvsagt ikke brukes på offentlige nett.

3.1 3,4:
Ordet "based on" er ikke definert.  En tolkning er "X kan implementeres
ved å utvide koden til Y", noe som inverterer svaralternativene.

3.1 15:
DNS service records kan oversette TSAP til en ipadresse.  (Se rfc2054
for mer informasjon.)

4.1 1:
VC over pakkesvitsjet nett er mulig (men ikke vanlig)

4.1 2:
Dersom man har litt mer avanserte HA-løsninger vil failover-kretsen
kjenne tilstanden til noden som gikk ned og dermed kunne ta over og
opprettholde de virtuelle kretsene.

4.1 4:
Nettverksfeil finnes i flere typer, stort sett i to typer:  de som
gjør at nettet mister pakker og de som ikke gjør at nettet mister
pakker.  Datagrammer er robuste mot den siste, men ikke den første.

4.1 8 "In Internet, a router implements the network layer":

Hva betyr _implementerer_ her?  To tolkninger er rimelige:  En ruter
har en implementasjon av nettverkslaget, eller ruterne er de delene av
Internet som er ansvarlig for å implementere nettverkslaget (dvs,
andre deler av nettet/andre noder har ikke et nettverkslag).

4.1 11 "The subnet mask is applied on the network part of the IP
address":

I denne sammenhengen er ikke "applied" definert.  Videre vil det være
knekkende likegyldig om subnettmasken brukes sammen med
nettverksadressen eller hostadressen dersom man er interessert i den
informasjonsbiten som ligger i nettverksdelen.

En mulig tolkning er:  "Apply a mask", bruke en maske for å maskere ut
noe (evt maskere inn noe annet).  Nettverksmasken brukes for å maskere
ut nettverksadressen, subsidiært å maskere ut den interface-spesifikke
biten fra den fulle ip-adressen.

4.1 12: "IPv4 addresses are globally unique"
Interessant at her er IPv4-adresser ikke globalt unike, men kombinert
med et portnummer (se 3.1 1) er de globalt unike.. 

4.1 15: 
En ruter trenger ikke køe noe som helst, men vil vanligvis gjøre det.

4.2: Ruter R9 har ingen direkte rute til 15.2, ei heller en indirekte
rute til 15.2.  I det hele tatt virker det noe besynderlig at to
rutere har et grensesnitt uten ip-adresser (R9 <-> R11)

4.3: Feil i LF:

Linje 3 skal ingen bokser i B-kolonnen være krysset av, da de er en
del av N.